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.

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:

     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, edit the service edb-as-12.service file using the command:

    systemctl edit edb-as-12.service
  • Add the following lines into the text editor, then save:

    [Unit]
    BindsTo=edb-efm-4.5.service

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-12.service:
    BindsTo=edb-efm-4.5.service
  • Run the following command to reload the configuration files:
    systemctl daemon-reload

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