Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave
От | Heikki Linnakangas |
---|---|
Тема | Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave |
Дата | |
Msg-id | 50F857A8.7080800@vmware.com обсуждение исходный текст |
Ответ на | Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Re: Slave enters in recovery and promotes when WAL
stream with master is cut + delay master/slave
|
Список | pgsql-hackers |
On 17.01.2013 20:08, Andres Freund wrote: > On 2013-01-18 03:05:47 +0900, Fujii Masao wrote: >> I encountered the problem that the timeline switch is not performed expectedly. >> I set up one master, one standby and one cascade standby. All the servers >> share the archive directory. restore_command is specified in the recovery.conf >> in those two standbys. >> >> I shut down the master, and then promoted the standby. In this case, the >> cascade standby should switch to new timeline and replication should be >> successfully restarted. But the timeline was never changed, and the following >> log messages were kept outputting. >> >> sby2 LOG: restarted WAL streaming at 0/3000000 on timeline 1 >> sby2 LOG: replication terminated by primary server >> sby2 DETAIL: End of WAL reached on timeline 1 >> sby2 LOG: restarted WAL streaming at 0/3000000 on timeline 1 >> sby2 LOG: replication terminated by primary server >> sby2 DETAIL: End of WAL reached on timeline 1 >> sby2 LOG: restarted WAL streaming at 0/3000000 on timeline 1 >> sby2 LOG: replication terminated by primary server >> sby2 DETAIL: End of WAL reached on timeline 1 >> .... > > That's after the commit or before? Because in passing I think I > noticed/fixed a bug that could cause exactly that problem... I think I broke that with the "teach pg_receivexlog to cross timelines" patch. Will take a look... - Heikki
В списке pgsql-hackers по дате отправления: