Re: recovery_target_time and standby_mode
От | Robert Haas |
---|---|
Тема | Re: recovery_target_time and standby_mode |
Дата | |
Msg-id | CA+TgmoYz+C6FzsaYuxmDpV-2LMXQ04YjwFYHz32FdRfs9z5+XQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: recovery_target_time and standby_mode (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Wed, Nov 12, 2014 at 12:12 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 11/07/2014 02:03 PM, Josh Berkus wrote: >> But, like I said, there's a serviceable workaround. > > Some update on this. We've seen a problem in production with this setup > which I can't reproduce as a test case, but which may jog Heikki's > memory for something to fix. > > 1. Recover master to 2014-11-10 12:10:00 > 2. Recover replica to 2014-11-10 12:10:00, > with pause_at_recovery_target > 3. reconfigure recovery.conf for streaming replication > and restart the replica > 4. get a fatal error for replication, because > the replica is ahead of the master on timeline1 > > What *appears* to be happening is that the pause_at_recovery_target, > followed by the restart, on the replica causes it to advance one commit > on timeline 1. But *not all the time*; this doesn't happen in my > pgbench-based tests. > > There's a workaround for the user (they just restore the replica to 5 > minutes earlier), but I'm thinking this is a minor bug somewhere. I'm not sure what's going on here, but keep in mind that when you restart the replica, it's going to back up to the most recent restartpoint and begin replication from there, not from the point it was at when you shut down. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: