Re: pg_rewind, a tool for resynchronizing an old master after failover

On Thursday, May 23, 2013 4:40 PM Heikki Linnakangas wrote:
> Hi,

> I've been hacking on a tool to allow resynchronizing an old master
> server after failover. The need to do a full backup/restore has been a
> common complaint ever since we've had streaming replication. I saw on
> the wiki that this was discussed in the dev meeting; too bad I couldn't
> make it.

> In a nutshell, the idea is to do copy everything that has changed
> between the cluster, like rsync does, but instead of reading through all
> files, use the WAL to determine what has changed. Here's a somewhat more
> detailed explanation, from the README:

This is really a nice idea and an important requirement from many users.

Does this tool handle all kind of operations user would have performaed after
forking of new cluster or it would mandate that user should not have performed certain kind of
operations on old cluster after new cluster forked off?

> Theory of operation
> -------------------

> The basic idea is to copy everything from the new cluster to old, except
> for the blocks that we know to be the same.

> 1. Scan the WAL log of the old cluster, starting from the point where
> the new cluster's timeline history forked off from the old cluster. For
> each WAL record, make a note of the data blocks that are touched. This
> yields a list of all the data blocks that were changed in the old
> cluster, after the new cluster forked off.

a. How about if after forking off new cluster, a new relation gets created in old cluster,
then it might not find the blocks of same in new cluster, if new cluster also got
the same name relation as old but with different data, it might get error when it start
to replay WAL of new master as mentioned in point-4.

b. How about if after forking off new cluster, an update occurs such that it has to put new
row in new heap page, now in WAL it will have mention of old and new row blocks (blk-1 and blk-2).
It might be the case new cluster will not have blk-2, so only blk-1 will be copied from new cluster,
in such scenario, it will have 2 valid versions of same row.

With Regards,
Amit Kapila.