Re: Help diagnosing replication (copy) error
От | Adrian Klaver |
---|---|
Тема | Re: Help diagnosing replication (copy) error |
Дата | |
Msg-id | f3ceeee3-ce10-49aa-8667-6d957aa9cbc4@aklaver.com обсуждение исходный текст |
Ответ на | Help diagnosing replication (copy) error (Steve Baldwin <steve.baldwin@gmail.com>) |
Ответы |
Re: Help diagnosing replication (copy) error
|
Список | pgsql-general |
On 3/8/24 13:50, Steve Baldwin wrote: > Hi, > > I'm in the process of migrating a cluster from 15.3 to 16.2. We have a > 'zero downtime' requirement so I'm using logical replication to create > the new cluster and then perform the switch in the application. > > I have a situation where all but one table have done their initial copy. > The remaining table is the largest (of course), and the replication slot > that is assigned for the copy > (pg_378075177_sync_60067_7343845372910323059) is showing as > 'active=false' if I select from pg_replication_slots on the publisher. What are the rest of the values in pg_replication_slots? Is there data in the subscriber side table? What are the publisher and subscriber configurations? > > I've checked the recent logs for both the publishing cluster and the > subscribing cluster but I can't see any replication errors. I guess I > could have missed them, but it doesn't seem like anything is being > 'retried' like I've seen in the past with replication errors. > > I've used this mechanism for zero-downtime upgrades multiple times in > the past, and have recently used it to upgrade smaller clusters from > 15.x to 16.2 without issue. > > The clusters are hosted on AWS RDS, so I have no access to the servers, > but if that's the only way to diagnose the issue, I can create a support > case. > > Does anyone have any suggestions as to where I should look for the issue? > > Thanks, > > Steve -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: