What is actually happening when postgresql discovers the trigger file and promotes it self from slave to master?

Question

I have a streaming replication setup between two postgres servers (master: server A, slave: server B). I'm wondering what's actually happening under the hood when I touch the trigger file and the slaves takes over as master? One of the things that I wonder, and no one seems to mention anywhere in either tutorials or documentation is, what if I restart the former slave (now master) after this is done? Won't things get messed up, because the .conf file still reflects the old slave setup (e.g. hot_standby = on)? Should I update that .conf, before I can safely restart the server?

Background: The situation I'm in, that made me wonder all of this is that I need to change the HDD's on my master. This is the way I plan to do it:

• Failover to the slave (server B)
• Change the HDD's on the master (server A) and reinstall it
• Start the reinstalled server A as a slave
• After server A has catched up with server B, change server A back into being the master, and then turn server B back into being slave again

(BTW. If you got suggestions to a better workflow please tell me)

Answer 1

A replica server (whether running as hot_standby or not) is running in what PostgreSQL calls "recovery mode". As the name suggests, this was originally developed to perform recovery from an unsafe stop: in this situation, it uses the recovery.conf file which defines how to find transaction logs (pg_xlog files) and keeps applying them until no more are available, and then exits from recovery mode into "normal" mode, and starts generating new transaction logs itself. When exiting recovery mode, the recovery.conf file is renamed to recovery.done, so that a subsequent restart goes directly to normal mode.

The changes from this process for a replication slave are:

• the transaction log data may not be coming from log files, but streamed from the master server: recovery.conf specifies which
• replicas do not exit recovery mode when no more data is available, they wait until the trigger is fired.

So due to the renaming of recovery.conf, restarting your newly-elected master preserves the property of it being a master.

However, one point to note: after recovery has completed and a server transitions from being in recovery to being in normal mode, it changes "timeline". Essentially, at this point you have forked your database: one version is the possible continuation of transaction logs from wherever they were coming from, and one version (the new version) is from the database that has just finished recovery. But you can only apply log files from a master server that is on the same timeline! This is why, after doing a failover, you need to rebuild your old master server from the new master, rather than just starting it to let it "catch up".

(This above paragraph is subject to some doubt as my experience with thee failovers is currently limited, but it's from my understanding of the documentation, and how the system works overall).

Also note that the hot_standby flag means only that a database cluster will accept connections and allow read-only queries even while it is in recovery mode: not a normal situation for a database that is recovering from a crash. Once a server is running in "normal mode", this setting is irrelevant, so it is not a problem to have it set on the old slave/new master.