On Wed, Feb 5, 2014 at 10:30 AM, James Sewell <james.sew...@lisasoft.com> wrote: > > Hello All, > > I have been reading through some of the recent discussions about failback when in a streaming replication setup. I define failback as: > > Node A is master, Node B is slave > Node A crashes || Node A is stopped || nothing happens > Promote Node B to Master > Attach Node A as slave > > My understanding is currently to achieve step three you need to take a base backup of Node B and deploy it to Node A before starting streaming replication (or use rsync etc...).
I think in above sentence you mean to say "to achieve step *four* .." > This is very undesirable for many users, especially if they have a very large database. > > From the discussions I can see that the problem is to do with Node A writing changes to disk that Node B are not streamed before Node A crashes. Yes, this is right. > Has there been any consensus on this issue? Are there any solutions which might make it into 9.4 or 9.5? As far as I know, there is still no solution provided in 9.4, can't say anything for 9.5 with any certainity. However in 9.4, there is a new parameter wal_log_hints which can be useful to overcome drawback of pg_rewind. > I've seen some proposals and a tool (pg_rewind), but all seem to have draw backs. As far as I remember, one of the main drawbacks for pg_rewind was related to hint bits which can be avoided by wal_log_hints. pg_rewind is not part of core PostgreSQL code, however if you wish, you can try that tool to see if can it solve your purpose. Note - James, in previous reply, I missed to cc to hackers, so sending it again. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
