[HACKERS] Questions about upgrade standby with rsync - Mailing list pgsql-hackers

From Sergey Burladyan
Subject [HACKERS] Questions about upgrade standby with rsync
Date
Msg-id 87y3ta49zp.fsf@seb.koffice.internal
Whole thread Raw
Responses Re: [HACKERS] Questions about upgrade standby with rsync
List pgsql-hackers
Hello, all!

I have problem with upgrading standby via rsync.

Documentation say:
> Verify that the "Latest checkpoint location" values match in all clusters.

But it is impossible for "WAL archive only" standby, if I not mistaken.

Standby can make restartpoint only at master checkpoint location, because standby cannot write WALs.
When you use WAL archive only, without streaming replication, last WAL from master with shutdown checkpoint
do not archived. I think may be because WAL archiving process already terminated, when last WAL switched.

For example:
==== standby log ===
2017-06-01 13:09:25 GMT LOG:  recovery restart point at 0/3000790
2017-06-01 13:09:26 GMT LOG:  recovery restart point at 0/603FB10
2017-06-01 13:09:27 GMT LOG:  recovery restart point at 0/903ED28
2017-06-01 13:09:33 GMT LOG:  recovery restart point at 0/C03EFF0
2017-06-01 13:09:38 GMT LOG:  recovery restart point at 0/F040E28

now stop master and then standby:

==== master control data after shutdown ===                      ==== standby control data after shutdown ===
Latest checkpoint location:           0/12000020                 Latest checkpoint location:           0/110402A8
Prior checkpoint location:            0/110402A8                 Prior checkpoint location:            0/D067A00
Latest checkpoint's REDO location:    0/12000020                 Latest checkpoint's REDO location:    0/F040E28
Latest checkpoint's TimeLineID:       1                          Latest checkpoint's TimeLineID:       1
Latest checkpoint's full_page_writes: on                         Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0/1267                     Latest checkpoint's NextXID:          0/1267
Latest checkpoint's NextOID:          16393                      Latest checkpoint's NextOID:          24576
Latest checkpoint's NextMultiXactId:  1                          Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0                          Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        1254                       Latest checkpoint's oldestXID:        1254
Latest checkpoint's oldestXID's DB:   1                          Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0                          Latest checkpoint's oldestActiveXID:  1266
Time of latest checkpoint:            Thu Jun  1 16:09:32 2017   Time of latest checkpoint:            Thu Jun  1
16:09:302017 
Minimum recovery ending location:     0/0                        Minimum recovery ending location:     0/12000000

As you can see, when standby was run — it was consistent with master: "Minimum recovery ending location: 0/12000000"
but it last restartpoint is previous checkpoint (from master), because last WAL (000000010000000000000012) from master
do not archived:
==== xlogdump ====
m/9.2/pg_xlog/000000010000000000000012:

[page:0, xlp_info:6, xlp_tli:1, xlp_pageaddr:0/12000000] XLP_LONG_HEADER XLP_BKP_REMOVABLE
Unexpected page info flags 0006 at offset 0
[cur:0/12000020, xid:0, rmid:0(XLOG), len/tot_len:64/96, info:0, prev:0/11387BB8] checkpoint: redo 0/12000020; tli 1;
nextxid1267;  nextoid 16393; nextmulti 1; nextoffset 0; shutdown at 2017-06-01 16:09:32 MSK 
ReadRecord: record with zero len at 0/12000080

This WAL file is only at master pg_xlog, and not in WAL archive.


And my second question, this algorithm with rsync described only starting from pg 9.5,
is it possible to use it for upgrade from pg 9.2 to pg 9.4?

Thanks!

--
Sergey Burladyan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Hash Functions
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pg_class.relpartbound definition overly brittle