Re: Upgrade and re-synchronization with logical replication(pglogical and PG 10)
От | Chad Trabant |
---|---|
Тема | Re: Upgrade and re-synchronization with logical replication(pglogical and PG 10) |
Дата | |
Msg-id | E03760D6-22CD-448F-BBD5-747D91971DED@iris.washington.edu обсуждение исходный текст |
Ответ на | Re: Upgrade and re-synchronization with logical replication(pglogical and PG 10) (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: Upgrade and re-synchronization with logical replication(pglogical and PG 10)
|
Список | pgsql-admin |
> On Jan 23, 2018, at 9:36 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 1/22/18 01:53, Chad Trabant wrote: >> 1) In my initial testing it seems that an upgrade via pg_upgrade does >> not migrate logical replication slots or origins >> (pg_replication_slots and pg_replication_origin). > > Correct. Thank you for confirming. I'm sure there is a good reason for this, can someone explain why (even if briefly)? > A better approach might be to use pglogical itself to do the upgrade. > That is, set up a new replica somewhere that is PG10, replicate into > that, and switch over. This requires duplicating the data and host. What I'm trying to do is upgrade an existing publisher and subscriber pairwith limited downtime. I suppose this could be done by replicating the publisher to a new publisher, then to a new subscriber,then swap out the old systems for the new. Unfortunately, I have have some systems with a large volume of dataand specialized hardware (relative to our data center), which makes creating a duplicate not possible. Luckily in my scenario it is acceptable to turn off all inserts/updates/deletes/truncates to the paired systems for shortterm, planned maintenance and only one of each pair needs to be up for select access. I'll be experimenting with howto re-attach a publisher-subscriber pair post-pg_upgrade. Any hints or gotchas that could guide me would be appreciated.
В списке pgsql-admin по дате отправления: