Re: pg_rewind copy so much data

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Hung Phan <hungphan227(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_rewind copy so much data
Date: 2017-09-13 03:48:53
Message-ID: CAB7nPqTpumjeS+x-6Z2vEQV-+t54fgQKkWz3H_swFBHdaNp6AQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Sep 13, 2017 at 12:41 PM, Hung Phan <hungphan227(at)gmail(dot)com> wrote:
> I have tested pg_rewind (ver 9.5) with the following scenario:
>
> - one master and one slave (total size of each server is more than 4GB)
> - set wal_log_hint=on and restart both
> - stop master, promote slave
> - start old master again (now two servers have diverged)
> - stop old master, run pg_rewind with progress option

That's a good flow. Don't forget to run a manual checkpoint after
promotion to update the control file of the promoted standby so as
pg_rewind is able to identify the timeline difference between the
source and the target servers.

> The pg_rewind ran successfully but I saw it copied more than 4GB (4265891 kB
> copied). So I wonder there was very minor difference between two servers but
> why did pg_rewind copy almost all data of new master?

Without knowing exactly the list of things that have been registered
as things to copy from the active source to the target, it is hard to
give a conclusion. But my bet here is that you let the target server
online long enough that it had a bunch of block updated, causing more
relation blocks to be copied from the source because more efforts
would be needed to re-sync it. That's only an assumption without data
with clear numbers, numbers that could be found using the --debug
messages of pg_rewind.
--
Michael

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Hung Phan 2017-09-13 05:21:14 Re: pg_rewind copy so much data
Previous Message Hung Phan 2017-09-13 03:41:43 pg_rewind copy so much data