Configuring for Eager Failover

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.2.

Enabling Eager Failover

*   primary.shutdown.as.failure=true

• 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 the `enable.stop.cluster` property.
  

*   enable.stop.cluster=false

• Ensure that the database server and the local Failover Manager agent are running.
  

• As root, create `/etc/systemd/system/edb-as-12.service` file and include:
  

*   .include /lib/systemd/system/edb-as-12.service
*   [Unit]
*   BindsTo=edb-efm-4.2.service

• Run the following command to reload the configuration files:
  

*   systemctl daemon-reload

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

Upgrading Failover Manager in Eager Failover mode

To upgrade Failover Manager without stopping EDB Postgres Advanced Server, temporarily disable the Eager Failover mode.

1. Disable Eager Failover

2. Stop and upgrade Failover Manager

3. Enable Eager Failover

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](01_cluster_properties/#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

  • - If there's a problem starting Failover Manager, such as a bad property value, the database server starts and shuts down again without displaying any warning that it isn't running.        - If the Failover Manager process was previously ended, the lock file still exists, and the agent can't restart automatically.        - If problems occur when starting the database server or the Failover Manager agent, check the Failover Manager startup log for information.
    

• As a result of running the `stop-cluster` command, Failover Manager stops on all the nodes. In Eager Failover mode, the `stop-cluster` command also stops EDB Postgres Advanced Server without a failover. Set `enable.stop.cluster=false` to make sure the `stop-cluster` command can't be invoked unintentionally.