Re: upgrade using logical replication

Поиск
Список
Период
Сортировка
От Ian Lawrence Barwick
Тема Re: upgrade using logical replication
Дата
Msg-id CAB8KJ=jKpCO-utWjrujJAjj4m2B13nT-O+w0R=f4qtR5YYv1zg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: upgrade using logical replication  (Mohamed Wael Khobalatte <mkhobalatte@grubhub.com>)
Ответы Re: upgrade using logical replication  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-general
2021年1月21日(木) 9:19 Mohamed Wael Khobalatte <mkhobalatte@grubhub.com>:


On Wed, Jan 20, 2021 at 2:37 PM Michael Lewis <mlewis@entrata.com> wrote:
Using pg_upgrade takes minutes for an in place upgrade. If you can allow 1+ hour of downtime, it seems overly complicated to use logical replication.

I suppose the Atul's issue is what to do with the replicas. Once he does pg_upgrade, then he will need to provision new ones, no? I suppose in this case logical would be better, with the new instance itself having replicas. I haven't done it, and it's gonna require some setup time, definitely much longer than pg_upgrade then make do with one server until your new physical replicas are set up. 

The replicas will need to be set up at some point anyway; with logical
replication the new cluster is ready to go once the new primary is fully
"seeded" (and the new replicas have caught up with that). Switchover can then
take place whenever convenient, with minimal downtime, more time for testing,
and the possibility of switching back if issues are encountered.

Potential downsides to this approach are that the database schema may need to be
modified to be suitable for logical replication, and additional resources may be
needed to host the old and new clusters simultaneously during the migration
process.

Regards

Ian Barwick

--

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: See what options a Postgresql binary was compiled with
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: upgrade using logical replication