Re: pg_rewind, a tool for resynchronizing an old master after failover - Mailing list pgsql-hackers

From Amit kapila
Subject Re: pg_rewind, a tool for resynchronizing an old master after failover
Date
Msg-id 6C0B27F7206C9E4CA54AE035729E9C38421B24F5@szxeml558-mbs.china.huawei.com
Whole thread Raw
In response to pg_rewind, a tool for resynchronizing an old master after failover  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: pg_rewind, a tool for resynchronizing an old master after failover
List pgsql-hackers
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
blocksof same in new cluster, if new cluster also got   the same name relation as old but with different data, it might
geterror 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
inWAL 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.


pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: Move unused buffers to freelist
Next
From: Simon Riggs
Date:
Subject: Re: pg_export_snapshot on standby side