Re: [HACKERS] Failback to old master

2014-11-13 9:05 GMT+01:00 Heikki Linnakangas : > > Right. You have to be careful to make sure the standby really did fully > catch up with the master, though. If it happens that the replication > connection is momentarily down when you shut down the master, for example, > then the master won't wai

Re: [HACKERS] Failback to old master

On 16/11/14 13:13, didier wrote: I think you have to add recovery_target_timeline = '2' in recovery.conf with '2' being the new primary timeline . cf http://www.postgresql.org/docs/9.4/static/recovery-target-settings.html Thank you. Based on the link I have added: recovery_target_timeline = '

Re: [HACKERS] Failback to old master

Hi, On Sat, Nov 15, 2014 at 5:31 PM, Maeldron T. wrote: >> A safely shut down master (-m fast is safe) can be safely restarted as >> a slave to the newly promoted master. Fast shutdown shuts down all >> normal connections, does a shutdown checkpoint and then waits for this >> checkpoint to be re

Re: [HACKERS] Failback to old master

On 12/11/14 14:28, Ants Aasma wrote: On Tue, Nov 11, 2014 at 11:52 PM, Maeldron T. wrote: As far as I remember (I can’t test it right now but I am 99% sure) promoting the slave makes it impossible to connect the old master to the new one without making a base_backup. The reason is the timelin

Re: [HACKERS] Failback to old master

On Thu, Nov 13, 2014 at 10:05 AM, Heikki Linnakangas wrote: >> In this case the >> old master will request recovery from a point after the timeline >> switch and the new master will reply with an error. So it is safe to >> try re-adding a crashed master as a slave, but this might fail. > > > Are

Re: [HACKERS] Failback to old master

On 11/12/2014 03:28 PM, Ants Aasma wrote: On Tue, Nov 11, 2014 at 11:52 PM, Maeldron T. wrote: As far as I remember (I can’t test it right now but I am 99% sure) promoting the slave makes it impossible to connect the old master to the new one without making a base_backup. The reason is the ti

Re: [HACKERS] Failback to old master

On Tue, Nov 11, 2014 at 11:52 PM, Maeldron T. wrote: > As far as I remember (I can’t test it right now but I am 99% sure) promoting > the slave makes it impossible to connect the old master to the new one > without making a base_backup. The reason is the timeline change. It complains. A safely

Re: [HACKERS] Failback to old master

Hi, 2014-10-29 17:46 GMT+01:00 Robert Haas >: Yes, but after the restart, the slave will also rewind to the most recent restart-point to begin replay, and some of the sanity checks that recovery.conf enforces will be lost during that replay. A safe wa

Re: [HACKERS] Failback to old master

On Wed, Oct 29, 2014 at 12:43 PM, Maeldron T. wrote: > Thank you, Robert. > > I thought that removing the recovery.conf file makes the slave master only > after the slave was restarted. (Unlike creating the a trigger_file). Isn't > this true? Yes, but after the restart, the slave will also rewind

Re: [HACKERS] Failback to old master

Thank you, Robert. I thought that removing the recovery.conf file makes the slave master only after the slave was restarted. (Unlike creating the a trigger_file). Isn't this true? I also thought that if there was a crash on the original master and it applied WAL entries on itself that are not pre

Re: [HACKERS] Failback to old master

On Wed, Oct 29, 2014 at 6:21 AM, Maeldron T. wrote: > I swear I have read a couple of old threads. Yet I am not sure if it safe to > failback to the old master in case of async replication without base backup. > > Considering: > I have the latest 9.3 server > A: master > B: slave > B is actively c

[HACKERS] Failback to old master

Hello, I swear I have read a couple of old threads. Yet I am not sure if it safe to failback to the old master in case of async replication without base backup. Considering: I have the latest 9.3 server A: master B: slave B is actively connected to A I shut down A manually with -m fast (it's the