Re: PostgreSQL Failback without rebuild

On Wed, Feb 5, 2014 at 10:30 AM, James Sewell <james(dot)sewell(at)lisasoft(dot)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