On Wed, Feb 5, 2014 at 10:30 AM, James Sewell <james.sewell@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.
