Re: Loss of replication after simple misconfiguration
От | hubert depesz lubaczewski |
---|---|
Тема | Re: Loss of replication after simple misconfiguration |
Дата | |
Msg-id | 20200410080122.GA23421@depesz.com обсуждение исходный текст |
Ответ на | Re: Loss of replication after simple misconfiguration (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-bugs |
On Fri, Apr 10, 2020 at 04:59:32PM +0900, Michael Paquier wrote: > On Fri, Apr 10, 2020 at 09:26:51AM +0200, hubert depesz lubaczewski wrote: > > In our case it was *at least* this scenario: > > > > 1. master and slave both with max_worker_processes and > > track_commit_timestamp off. > > 2. config files get changed on both to include track_commit_timestamp on > > 3. slave gets restarted > > 4. config files get changed on both to include max_worker_processes = 50 > > 5. master gets stopped by "power outage" > > 6. after master re-starts, replication to slave dies. > > Without the standby restarted here, its configuration remains at the > former value of max_worker_processes, which is lower than the setting > of the primary, so it would logically stop in this case if not > restarted once it replays the XLOG_PARAMETER_CHANGE record generated > from the primary. Yes, I know. And this is *precisely* what has happened in at least one case. But I would assume that after restart, standby should be working. Which didn't happen (in at least one case, we had lots of restarts recently, and only ~ 4 cases of replication dying). Best regards, depesz
В списке pgsql-bugs по дате отправления: