Configuring for Eager Failover v4
In default run mode, if a primary Failover Manager process fails, there's no failover protection until the agent restarts. To avoid this case, you can set up the primary node through
systemd to cause a failover when the primary agent exits, which is called Eager Failover.
You can set up Eager Failover by performing the following steps. The example uses EDB Postgres Advanced Server version 12 and Failover Manager version 4.5.
Since the database server stops as soon as the Failover Manager agent stops or fails, you must set the following property for all the agents before starting Failover Manager:
If you don't set this property before starting Failover Manager, shutting down a Failover Manager agent shuts down the database without failover.
With Eager Failover enabled, using the
efm stop-clustercommand stops all of the Failover Manager agents and shuts down the primary database. Since the agents aren't running, there's no failover. To avoid thihs scenario, you can disable the command using the
Ensure that the database server and the local Failover Manager agent are running.
As root, edit the service
edb-as-12.servicefile using the command:
Add the following lines into the text editor, then save:
With these changes, when the Failover Manager agent is stopped or ended, the rest of the cluster treats this situation as a failure and attempts a failover.
- If you want to stop Failover Manager without stopping the database, comment out the following line in
- Run the following command to reload the configuration files:
To upgrade Failover Manager without stopping EDB Postgres Advanced Server, temporarily disable the Eager Failover mode.
systemdcommand isn't used to manage the database while running Failover Manager with a non-sudo setup, Eager Failover is supported only in sudo mode. It isn't supported in a non-sudo mode.
Eager Failover isn't suitable for situations in which a VIP wouldn't be released by the old primary.
Eager Failover is suitable in the following situations:
With the EDB Postgres Advanced Server high-availability setup.
When custom scripting triggered by
script.fencewould fence the old primary server (STONITH). Some examples are to shut down the VM with VMWare vCenter integration, openstack integration, or lights-out management.
When custom scripting triggered by
script.fencewould use ssh to deactivate the VIP.
check.vip.before.promotion=falseis required to allow the new primary to attach the VIP before the old primary releases it.
Use care when using
primary.shutdown.as.failure=true. See the description of the primary.shutdown.as.failure property for information on how to safely bring down the database if needed.
With every failover, a primary ends up being a failed primary, which doesn't automatically recover as an operational standby. Therefore, make sure the cluster contains multiple promotable standbys, and the total number of standbys is at least two more than the value specified for the
minimum.standbysproperty. This is a general recommendation, but it becomes more pressing when using Eager Failover.
If the database server is stopped, restarting the database also starts Failover Manager.
As a result of running the
stop-clustercommand, Failover Manager stops on all the nodes. In Eager Failover mode, the
stop-clustercommand also stops EDB Postgres Advanced Server without a failover. Set
enable.stop.cluster=falseto make sure the
stop-clustercommand can't be invoked unintentionally.