On Sun, Jun 11, 2017 at 11:59 PM, Vladimir Borodin <root@simply.name> wrote:
8 июня 2017 г., в 17:03, Amit Kapila <amit.kapila16@gmail.com> написал(а):
On Thu, Jun 8, 2017 at 6:49 PM, Dmitriy Sarafannikov
<dsarafannikov@yandex.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 masterafter the upgrade is complete (including an upgrade for replicas). Ifyou are worried about the performance of read-only replicas till thetime Analyze on the master in completed, you might want to use--analyze-in-stages of vaccumdb and or use (-j njobs) along with it toparallelize 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,
4. Start master, run analyze and stop.
5. Put the control file from step 3 to replicas and rsync them according to the documentation.
And I think that step 10.f in the documentation [1] should be fixed to mention starting in single-user mode or with disabled autovacuum.
--
May the force be with you…
