From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Vladimir Borodin <root(at)simply(dot)name> |
Cc: | Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Broken hint bits (freeze) |
Date: | 2017-06-13 11:50:55 |
Message-ID: | CAA4eK1+kVjPKYOyzyEcoxKZChxe2WWSeznuA41-RteDDdLb6Yg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 12, 2017 at 9:01 PM, Vladimir Borodin <root(at)simply(dot)name> wrote:
>
> 12 июня 2017 г., в 13:19, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> написал(а):
>
> On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <root(at)simply(dot)name> wrote:
>
>
> 8 июня 2017 г., в 17:03, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> написал(а):
>
> On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov
> <dsarafannikov(at)yandex(dot)ru> wrote:
>
>
> Why didn't rsync made the copies on master and replica same?
>
>
> Because rsync was running with —size-only flag.
>
>
> IIUC the situation, the new WAL and updated pg_control file has been
> copied, but not updated data files due to which the WAL has not been
> replayed on replicas? If so, why the pg_control file is copied, it's
> size shouldn't have changed?
>
>
> Because on master pg_upgrade moves $prefix/9.5/data/global/pg_control to
> $prefix/9.5/data/global/pg_control.old and creates new
> $prefix/9.6/data/global/pg_control without making hardlink. When running
> rsync from master to replica rsync sees $prefix/9.6/data/global/pg_control
> on master and checks if it is a hardlink. Since it is not a hardlink and
> $prefix/9.6/data/global/pg_control does not exist on replica rsync copies
> it. For data files the logic is different since they are hardlinks,
> corresponding files exist on replica and they are the same size.
>
>
> Okay, in that case, I guess it is better to run Analyze on master
> after the upgrade is complete (including an upgrade for replicas). If
> you are worried about the performance of read-only replicas till the
> time Analyze on the master in completed, you might want to use
> --analyze-in-stages of vaccumdb and or use (-j njobs) along with it to
> parallelize the operation.
>
>
> What about the following sequence?
>
> 1. Run pg_upgrade on master,
> 2. Start it in single-user mode and stop (to get right wal_level in
> pg_control),
> 3. Copy pg_control somewhere,
>
So the above step-3 is to allow extra WAL to be replayed on replicas
after the upgrade?
> 4. Start master, run analyze and stop.
> 5. Put the control file from step 3 to replicas and rsync them according to
> the documentation.
>
I think the above way should work for your use case unless someone
makes mistake while copying pg_control. I am sure you are ensuring to
have a backup during above procedure.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2017-06-13 11:53:32 | Typo in BRIN documentation |
Previous Message | Amit Khandekar | 2017-06-13 10:10:33 | Re: UPDATE of partition key |