public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nikolay Samokhvalov <[email protected]>
To: [email protected]
To: [email protected]
Subject: Using old master as new replica after clean switchover
Date: Thu, 25 Oct 2018 02:57:18 -0400
Message-ID: <CANNMO+KYuH3Gh7BZp=UGXpoos4tBR0AFgoONkqWBrokuJthEug@mail.gmail.com> (raw)
Currently, the documentation explicitly states, that after failover, the
old master must be recreated from scratch, or pg_rewind should be used
(requiring wal_log_hints to be on, which is off by default):
> The former standby is now the primary, but the former primary is down and
might stay down. To return to normal operation, a standby server must be
recreated, either on the former primary system when it comes up, or on a
third, possibly new, system. The pg_rewind utility can be used to speed up
this process on large clusters.
My research shows that some people already rely on the following when
planned failover (aka switchover) procedure, doing it in production:
1) shutdown the current master
2) ensure that the "master candidate" replica has received all WAL data
including shutdown checkpoint from the old master
3) promote the master candidate to make it new master
4) configure recovery.conf on the old master node, while it's inactive
5) start the old master node as a new replica following the new master.
It looks to me now, that if no steps missed in the procedure, this approach
is eligible for Postgres versions 9.3+ (for older versions like 9.3 maybe
not really always – people who know details better will correct me here
maybe). Am I right? Or I'm missing some risks here?
Two changes were made in 9.3 which allowed this approach in general [1]
[2]. Also, I see from the code [3] that during shutdown process, the
walsenders are the last who are stopped, so allow replicas to get the
shutdown checkpoint information.
Is this approach considered as safe now?
if so, let's add it to the documentation, making it official. The patch is
attached.
Links:
[0] 26.3 Failover
https://www.postgresql.org/docs/current/static/warm-standby-failover.html
[1] Support clean switchover
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=985bd7d49726c9f178558491d31a570d47340...
[2] Allow a streaming replication standby to follow a timeline switch
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=abfd192b1b5ba5216ac4b1f31dcd553106304...
[3]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/replication/walsender.c;hb=...
Regards,
Nik
Attachments:
[application/octet-stream] failover_doc.patch (1.1K, 3-failover_doc.patch)
download | inline diff:
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index faf8e71854..088c51c144 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1452,7 +1452,12 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
must be recreated,
either on the former primary system when it comes up, or on a third,
possibly new, system. The <xref linkend="app-pgrewind"/> utility can be
- used to speed up this process on large clusters.
+ used to speed up this process on large clusters. At the same time,
+ if before failover, the old master was cleanly shut down, and
+ all WAL data including so-called shutdown checkpoint was received
+ by the replica before it was promoted, the old master can be started
+ as a new replica attaching to the new master without rebuilding or using
+ pg_rewind. In this case, only configuration of recovery.conf is needed.
Once complete, the primary and standby can be
considered to have switched roles. Some people choose to use a third
server to provide backup for the new primary until the new standby
view thread (5+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Using old master as new replica after clean switchover
In-Reply-To: <CANNMO+KYuH3Gh7BZp=UGXpoos4tBR0AFgoONkqWBrokuJthEug@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox