Обсуждение: [ADMIN] standby upgrade questions

Поиск
Список
Период
Сортировка

[ADMIN] standby upgrade questions

От
Ray Stell
Дата:

From:   https://www.postgresql.org/docs/9.6/static/pgupgrade.html

Q1 - Is there a procedure to force this "catch up?"   I suppose preventing db activity with a pg_hba hack and running "select pg_switch_xlog()."   Maybe there's a better way?

  1. Prepare for standby server upgrades

    If you are upgrading standby servers (as outlined in section step 10), verify that the old standby servers are caught up by running pg_controldata against the old primary and standby clusters. Verify that the "Latest checkpoint location" values match in all clusters. (There will be a mismatch if old standby servers were shut down before the old primary.)

    Also, if upgrading standby servers, change wal_level to replica in the postgresql.conf file on the new master cluster.


Q2 - I was wondering what the end result is, in general, of this rsync of old and new?  If the old db files and upgraded, new db files are meshed what do you get on the other side of the rsync?  Again, I mean in general what is the goal?

f. Run rsync

From a directory that is above the old and new database cluster directories, run this for each slave:

rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir

where old_pgdata and new_pgdata are relative to the current directory, and remote_dir is above the old and new cluster directories on the standby server. The old and new relative cluster paths must match on the master and standby server.

Re: [ADMIN] standby upgrade questions

От
Bruce Momjian
Дата:
On Tue, Oct 17, 2017 at 11:34:51AM -0400, Ray Stell wrote:
> From:   https://www.postgresql.org/docs/9.6/static/pgupgrade.html

Sorry for the late reply.

> Q1 - Is there a procedure to force this "catch up?"   I suppose preventing db
> activity with a pg_hba hack and running "select pg_switch_xlog()."   Maybe
> there's a better way?

Uh, if there was a better way than pg_hba.conf, we would document it. 
Do you have any ideas?

>  1. Prepare for standby server upgrades
> 
>     If you are upgrading standby servers (as outlined in section step 10),
>     verify that the old standby servers are caught up by running pg_controldata
>      against the old primary and standby clusters. Verify that the "Latest
>     checkpoint location" values match in all clusters. (There will be a
>     mismatch if old standby servers were shut down before the old primary.)
> 
>     Also, if upgrading standby servers, change wal_level to replica in the 
>     postgresql.conf file on the new master cluster.
> 
> 
> Q2 - I was wondering what the end result is, in general, of this rsync of old
> and new?  If the old db files and upgraded, new db files are meshed what do you
> get on the other side of the rsync?  Again, I mean in general what is the goal?

I added more detail on what happens with rsync in this commit:

    commit 2d4a614e1ec34a746aca43d6a02aa3344dcf5fd4
    Author: Bruce Momjian <bruce@momjian.us>
    Date:   Tue Sep 12 13:17:52 2017 -0400
    
        docs:  improve pg_upgrade rsync instructions
    
        This explains how rsync accomplishes updating standby servers and
        clarifies the instructions.
    
        Reported-by: Andreas Joseph Krogh
    
        Discussion: https://postgr.es/m/VisenaEmail.10.2b4049e43870bd16.15d898d696f@tc7-visena
    
        Backpatch-through: 9.5

The new text is:

    https://www.postgresql.org/docs/10/static/pgupgrade.html
    
    What this does is to record the links created by pg_upgrade's link mode
    that connect files in the old and new clusters on the primary server. It
    then finds matching files in the standby's old cluster and creates links
    for them in the standby's new cluster. Files that were not linked on the
    primary are copied from the primary to the standby. (They are usually
    small.) This provides rapid standby upgrades. Unfortunately, rsync
    needlessly copies files associated with temporary and unlogged tables
    because these files don't normally exist on standby servers.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +