Showing results for 
Search instead for 
Did you mean: 

Easy Upgrade Tips for the New EDB Failover Manager

EDB Team Member


High availability means keeping an enterprise’s critical data infrastructure running well with virtually no downtime, and ensuring the database infrastructure’s ability to keep running in the event of failure. EnterpriseDB Postgres™ Failover Manager is the high availability solution from EnterpriseDB® (EDB™).  EDB Postgres Failover Manager was recently enhanced to provide support for EDB Advanced Server and PostgreSQL version 10, to add the ability to run Failover Manager as non-sudo user, and to give users new options for customized configurations. (Read the release-notes.)


EDB Postgres Failover Manager provides highly available, fault tolerant database clusters built using PostgreSQL streaming replication to reduce downtime and keep data available when a main database fails. EDB Failover Manager provides the cluster monitoring, failure detection, and failover procedures that can be integrated into a variety of high 9s-based high availability solutions.


For EDB customers already using EDB Postgres Failover Manager, taking advantage of new features means upgrading. The upgrade utility in EFM 3.0 upgrades configurations from the current installation of EFM 2.1 or EFM 2.0. The following example uses the default cluster name ‘efm’; the configuration files are named and efm.nodes. For information on how to use a non-default cluster name, see Section 4.3 of the Failover Manager user’s guide.


The upgraded config files will be generated in /etc/edb/efm-3.0.


What follows is a summary of some key steps in the upgrade process and what to expect, such as changes to the two configuration files when upgrading your files to 3.0 version. Following that will be an example of running the new upgrade utility to make the changes automatically.


The efm.nodes File

The format and information in the .nodes file has not changed from Failover Manager version 2.1 to 3.0.


Section 3.3.2 of the Failover Manager user’s guide describes the efm.nodes file, and a subsequent blog will discuss startup in more detail. The upgrade utility will create a 3.0 efm.nodes file for you from the file your deployment currently utilizes. You can also just copy the efm.nodes file as-is to your 3.0 installation, making sure the file is world readable with permissions set as 644  and owner and group set to user ‘efm’.


The File

This section discusses changes to the properties used by Failover Manager at startup. For each property, descriptive text in the user documentation provides more information.


  • The property  virtualIp.interface has been changed slightly for the value it holds. In version 3.0, this property does not include a secondary virtual IP id (do not include ":1", etc).The upgrade utility will remove the secondary ip id part of the value (including the ‘:’ char) and set it to the value of the virtualIp.interfaceproperty.
  • The jdbc.ssl and jdbc.ssl.mode properties are replaced by a new property, jdbc.sslmode. The value of jdbc.sslmode is derived from the jdbc.ssl and jdbc.ssl.mode propertiesFor more details, refer to the  user guide.
  • The property virtualIp.netmask is removed and is replaced with virtualIp.prefix. The upgrade utility converts the value of virtualIp.netmask from current installation to its corresponding prefix value and sets it for property virtualIp.prefix.  For example, a netmask value of would be converted to a prefix value as 24.


The following properties have been added:


  • stop.isolated.master - This should be set to true if you want Failover Manager to shutdown the database on isolated master node.  
  • script.remote.pre.promotion - This optional user-supplied script will be invoked on non-promoting agent nodes.
  • - This optional user-supplied script will be invoked on non-master agent nodes.
  • script.custom.monitor - This optional user-supplied script that will be invoked periodically to perform custom monitoring tasks. Below listed are few properties to control the execution of this script.
    • custom.monitor.interval - Time in seconds between executions of the script.
    • custom.monitor.timeout - Timeout value in seconds for how long the script will be allowed to run.
    • - If set to true, non-zero exit codes from the script will be reported but will not cause a promotion or be treated as a database failure.
  • log.dir - Specifies the location to which agent log files will be written. The default is /var/log/efm-3.0.

The above lists the changes to the individual properties. The template file has the new order, and the upgrade utility (below) will use this template when migrating your older file to the new version.


The Upgrade Utility

The efm script in Failover Manager 3.0 includes an upgrade feature that can be used to quickly migrate your 2.1 or 2.0 configuration files into your new installation. Invoked with a cluster name, it will look for <clustername>.properties and <clustername>.nodes in the /etc/efm-2.1/ and /etc/efm-2.0/directories. The utility will convert their information into 3.0 files in /etc/edb/efm-3.0 (any existing files will be renamed to include a timestamp). The owner and group of generated config files would be set to user efm and would be world readable with permissions value as 644 so that they are readily usable.


The following example shows the tool run with the default ‘efm’ cluster name:


[root@localhost bin]# efm upgrade-conf efm

Checking directory /etc/efm-2.1

Moving existing properties file to efm.properties_2018-27-02T09:41:19.145

Processing file.

Setting new property jdbc.sslmode to 'disable' based on previous ssl property values.

Removing secondary virtual ip id from virtualIp.interface.

Setting new property virtualIp.prefix to '24' based on previous virtualIp.netmask property value.


The following properties were added in addition to those in previous installed version:








Checking directory /etc/efm-2.1

Moving existing nodes file to efm.nodes_2018-27-02T09:41:19.172

Processing efm.nodes file.


Upgrade of files is finished. The owner and group for properties and nodes files have been set as 'efm'.


[root@localhost bin]#


From the output, you can see:

  • The old jdbc.ssl* property values were used to set the new jdbc.sslmode value.
  • The secondary virtual ip id is removed from virtualIp.interface property.
  • The new property value of virtualIp.prefix is set based on the previous virtualIp.netmask value.
  • The owner and group for properties and nodes files have been set as 'efm'.

All other new properties are set to appropriate default values.


Jagdish Kewat is a Senior Software Engineer at EnterpriseDB.