Before configuring a Failover Manager cluster, you must satisfy the prerequisites described below.
Install Java 1.8 (or later)
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.
Provide an SMTP Server
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.notification property, you can leave the user.email field blank; an SMTP server is not required.
If an event occurs, Failover Manager invokes the script (if provided), and sends 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, visit:
Configure Streaming Replication
Failover Manager requires that PostgreSQL streaming replication be configured between the Master node and the Standby node or nodes. Failover Manager does not 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 master during switchover. You should ensure that the paths within the
recovery.conf file on your standby nodes are consistent before performing a switchover. For more information about the
-sourcenode option, please see Promoting a Failover Manager Node.
On database version 12, the
restore_command properties are copied to the stopped master during switchover (unless otherwise specified with the
Modify the pg_hba.conf File
You must modify the
pg_hba.conf file on the Master and Standby nodes,
adding entries that allow communication between the all of the nodes in
the cluster. The following example demonstrates entries that might be
made to the pg_hba.conf file on the Master node:
# access for itself host fmdb efm 127.0.0.1/32 md5 # access for standby host fmdb efm 192.168.27.1/32 md5 # access for witness host fmdb efm 192.168.27.34/32 md5
efmspecifies the name of a valid database user.
fmdbspecifies 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.
Using Autostart for the Database Servers
If a Master node reboots, Failover Manager may detect the database is down on the Master node and promote a Standby node to the role of Master. If this happens, the Failover Manager agent on the (rebooted) Master node will not get a chance to write the
recovery.conf file; the
recovery.conf file prevents the database server from starting. If this happens, the rebooted Master node will return to the cluster as a second Master node.
To prevent this, start the Failover Manager agent before starting the database server. The agent will start in idle mode, and check to see if there is already a master in the cluster. If there is a master node, the agent will verify that a
standby.signal file exists, and the database will not start as a second master.
Ensure Communication Through Firewalls
If a Linux firewall (i.e. iptables) is enabled on the host of a Failover Manager node, you may need to add rules to the firewall configuration that allow tcp communication between the Failover Manager processes in the cluster. For example:
# iptables -I INPUT -p tcp --dport 7800:7810 -j ACCEPT /sbin/service iptables save
The command shown above opens a small range of ports (7800 through 7810). Failover Manager will connect via the port that corresponds to the port specified in the cluster properties file.
Ensure that the Database user has Sufficient Privileges
The database user specified by the
db.user property in the
file must have sufficient privileges to invoke the following functions on behalf of
For detailed information about each of these functions, please 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:
GRANT pg_read_all_settings TO user_name;
For more information about
pg_read_all_settings, please see the
PostgreSQL core documentation