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. Replace <x>
with the appropriate version numbers in the following.
Enabling Eager Failover
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-cluster
command 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 theenable.stop.cluster
property.Ensure that the database server and the local Failover Manager agent are running.
As root, edit the service
edb-as-<x>.service
file 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.
Disabling Eager Failover
- If you want to stop Failover Manager without stopping the database, comment out the following line in
/etc/systemd/system/edb-as-<x>.service
: - Run the following command to reload the configuration files:
Upgrading Failover Manager in Eager Failover mode
To upgrade Failover Manager without stopping EDB Postgres Advanced Server, temporarily disable the Eager Failover mode.
Important notes
Since the
systemd
command 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.
In a setup using client connection failover with jdbc or libpq (target-session-attrs).
When custom scripting triggered by
script.fence
would 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.fence
would use ssh to deactivate the VIP.Note
Setting
check.vip.before.promotion=false
is 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.standbys
property. 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.
!!! Note
As a result of running the
stop-cluster
command, Failover Manager stops on all the nodes. In Eager Failover mode, thestop-cluster
command also stops EDB Postgres Advanced Server without a failover. Setenable.stop.cluster=false
to make sure thestop-cluster
command can't be invoked unintentionally.