Before configuring a Failover Manager cluster, you must satisfy the prerequisites described below.
Before using Failover Manager, you must first install Java (version 1.8 or later). Failover Manager is tested with OpenJDK, and we strongly recommend installing that version of Java. Installation instructions for Java are platform specific.
You can receive notifications from Failover Manager as specified by a user-defined notification script, by email, or both.
- If you are using email notifications, an SMTP server must be running on each node of the Failover Manager scenario.
- If you provide a value in the
script.notificationproperty, you can leave the
user.emailfield blank; an SMTP server is not required.
If an event occurs, Failover Manager invokes the script (if provided) and can also send a notification email to any email addresses specified in the
user.email parameter of the cluster properties file. For more information about using an SMTP server, see the Red Hat deployment guide.
Failover Manager requires that PostgreSQL streaming replication be configured between the primary node and the standby nodes. Failover Manager doesn't support other types of replication.
On database versions 11 (or prior), unless specified with the
-sourcenode option, a
recovery.conf file is copied from a random standby node to the stopped primary during switchover. Ensure that the paths in the
recovery.conf file on your standby nodes are consistent before performing a switchover. For more information about the
-sourcenode option, see Promoting a Failover Manager node.
On database version 12 or later, the
restore_command properties are copied from a random standby node to the stopped primary during switchover unless otherwise specified with the
You must modify
pg_hba.conf on the primary and standby nodes, adding entries that allow communication between all of the nodes in the cluster. The following example shows entries you might make to the
pg_hba.conf file on the primary node:
efm specifies the name of a valid database user.
fmdb specifies the name of a database to which the efm user may connect.
By default, the
pg_hba.conf file resides in the
data directory, under your Postgres installation. After modifying the
pg_hba.conf file, you must reload the configuration file on each node for the changes to take effect. You can use the following command:
# systemctl reload edb-as-<x>
x specifies the Postgres version.
If a primary node reboots, Failover Manager might detect the database is down on the primary node and promote a standby node to the role of primary. If this happens, the Failover Manager agent on the rebooted primary node doesn't get a chance to write the
recovery.conf file, and the
recovery.conf file prevents the database server from starting. If this happens, the rebooted primary node returns to the cluster as a second primary node.
To prevent this condition, ensure that the Failover Manager agent auto starts before the database server. The agent starts in idle mode and checks to see if there is already a primary in the cluster. If there is a primary node, the agent verifies that a
standby.signal file exists. If neither file exits, the agent creates the
If a Linux firewall (that is, iptables) is enabled on the host of a Failover Manager node, you might need to add rules to the firewall configuration that allow tcp communication between the Failover Manager processes in the cluster. For example:
This command opens the port 7800. Failover Manager connects by way of the port that corresponds to the port specified in the cluster properties file.
The database user specified by the
db.user property in the
efm.properties file must have sufficient privileges to invoke the following functions on behalf of Failover Manager:
reconfigure.sync.primary property is set to
For database version 9.6, the db.user must be a superuser.
For database versions higher than version 9.6, the db.user requires
pg_read_all_statsprivilege and permissions to run
For detailed information about each of these functions, see the PostgreSQL core documentation.
The user must also have permissions to read the values of configuration variables. A database superuser can use the PostgreSQL
GRANT command to provide the permissions needed:
For more information about
pg_read_all_settings, see the PostgreSQL core documentation.