Switchover is a controlled switch from the master to the standby. If performed correctly, there will be no data loss. To be safe, simply shut down the master node cleanly, using either the smart or fast shutdown modes. Do not use the immediate mode shutdown because you will almost certainly lose data that way.
Failover is a forced switch from the master node to a standby because of the loss of the master. So, in that case, there is no action to perform on the master; we presume it is not there anymore.
Next, we need to promote one of the standby nodes to be the new master. A standby node can be triggered into becoming a master node in one of two ways:
- pg_ctl promote
- Suppose you originally specified a trigger_file parameter like this:
trigger_file = '/tmp/postgresql.trigger.5432'
Then, you can create the trigger file by executing this:
touch /tmp/postgresql.trigger.5432
The trigger_file will be deleted when the transition is complete.
Note that the trigger file has nothing to do whatsoever with trigger-based replication. The trigger filename can be anything you like. We use a suffix of 5432 to ensure that we trigger only one server if there are multiple PostgreSQL servers operating on the same system.
The standby will become the master only once it has fully caught up. If you haven't been monitoring replication, this could take some time.
In versions before PostgreSQL 9.3, switching from standby to master may take some time while the database performs an immediate checkpoint, at least with database servers with large caches and high rate of changes being replicated from the master. From PostgreSQL 9.3 onwards, we can switch from the standby to the master very quickly, and then perform a smooth background checkpoint. There may still be significant I/O as writes begin on the new master.
Once the ex-standby becomes a master, it will begin to operate all normal functions, including starting to archive files if configured. Be careful to verify that you have all the correct settings for when this node begins to operate as a master.
It is likely that the settings will be different from those on the original master from which they were copied.
Note that I refer to this new server as a master, not the master. It is up to you to ensure that the previous master doesn't continue to operate a situation known as split-brain. You must be careful to ensure that the previous master stays down.
Management of complex failover situations is not provided with PostgreSQL, nor is automated failover. Situations can be quite complex with multiple nodes, and clusterware is used in many cases to manage this.
The role of the recovery_end_command is to clean up at the end of the switchover or failover process. You do not need to explicitly remove the trigger file, as was recommended in previous releases.