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 efm.properties 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 efm.properties 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.interface property.
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 properties . For 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 255.255.255.0 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.
script.remote.post.promotion - 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.
custom.monitor.safe.mode - 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 efm.properties.in 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 efm.properties 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'.
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.
... View more