public inbox for [email protected]
help / color / mirror / Atom feedIn-place upgrade with streaming replicas
2+ messages / 1 participants
[nested] [flat]
* In-place upgrade with streaming replicas
@ 2025-01-17 07:36 [email protected]
2025-02-19 12:49 ` In-place upgrade with streaming replicas [email protected]
0 siblings, 1 reply; 2+ messages in thread
From: [email protected] @ 2025-01-17 07:36 UTC (permalink / raw)
To: [email protected]
Dear All,
I am trying to follow instructions regarding in-place upgrade with
streaming replica servers. The documentation here:
https://www.postgresql.org/docs/13/pgupgrade.html#:~:text=Prepare%20for%20standby%20server%20upgrade...
says that I should check 'Latest checkpoint location' in primary and
replica servers. Now, I want to make this process automatic, so I would
like to know a reliable way to make checkpoint locations match surely.
During the automated upgrade procedure, I restart all servers on a
different tcp ports, thus no legitim clients connect to primary, and
thus they dont make any changes. Then, I issue CHECKPOINT on primary,
retrieve pg_current_wal_lsn() on primary, and wait until all replicas
report the same value in pg_last_wal_replay_lsn(), then I issue a
CHECKPOINT on replicas. According to documentation this creates a
RESTOREPOINT on replicas. Then, I repeat until pg_current_wal_lsn() does
not change on primary. Then, if I shut down cluster in a way that first
the primary is shut down, and just after the replicas, then, checkpoint
locations will match. Howewer, if I accidentally shut down a replica
before primary is shut down, the checkpoint locations wont match.
With this, I have the question, that after the shutdown of primary, what
is the guarantee for replicas having the same checkpoint location? Why
does the order of shutting down the servers matter? What would be the
really exact and reliable way to ensure that replicas will have the same
checkpoint location as the primary?
Thanks in advance,
Richard
^ permalink raw reply [nested|flat] 2+ messages in thread
* In-place upgrade with streaming replicas
2025-01-17 07:36 In-place upgrade with streaming replicas [email protected]
@ 2025-02-19 12:49 ` [email protected]
0 siblings, 0 replies; 2+ messages in thread
From: [email protected] @ 2025-02-19 12:49 UTC (permalink / raw)
To: [email protected]
Dear All,
I am trying to follow instructions regarding in-place upgrade with
streaming replica servers. The documentation here:
https://www.postgresql.org/docs/13/pgupgrade.html#:~:text=Prepare%20for%20standby%20server%20upgrade...
says that I should check 'Latest checkpoint location' in primary and
replica servers. Now, I want to make this process automatic, so I would
like to know a reliable way to make checkpoint locations match surely.
During the automated upgrade procedure, I restart all servers on a
different tcp ports, thus no legitim clients connect to primary, and
thus they dont make any changes. Then, I issue CHECKPOINT on primary,
retrieve pg_current_wal_lsn() on primary, and wait until all replicas
report the same value in pg_last_wal_replay_lsn(), then I issue a
CHECKPOINT on replicas. According to documentation this creates a
RESTOREPOINT on replicas. Then, I repeat until pg_current_wal_lsn() does
not change on primary. Then, if I shut down cluster in a way that first
the primary is shut down, and just after the replicas, then, checkpoint
locations will match. Howewer, if I accidentally shut down a replica
before primary is shut down, the checkpoint locations wont match.
With this, I have the question, that after the shutdown of primary, what
is the guarantee for replicas having the same checkpoint location? Why
does the order of shutting down the servers matter? What would be the
really exact and reliable way to ensure that replicas will have the same
checkpoint location as the primary?
Thanks in advance,
Richard
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2025-02-19 12:49 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-01-17 07:36 In-place upgrade with streaming replicas [email protected]
2025-02-19 12:49 ` [email protected]
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox