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

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_rewind, a tool for resynchronizing an old master after failover
Date: 2013-05-25 09:22:17
Message-ID: CA+CSw_sGenGLFT35rBn1w+eUavEesJ+ke-iK4EyfDgWr=RWqEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 25, 2013 at 10:05 AM, Amit kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>> 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.

+1

> 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?

Truncate and all kinds of DROP come to mind, also table rewrites from
ALTER. The tool should probably just flag those relation files to be
copied wholesale.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-05-25 09:39:30 Planning incompatibilities for Postgres 10.0
Previous Message Simon Riggs 2013-05-25 09:18:57 Re: pg_export_snapshot on standby side