(Originally published on 10/6/2016)
High availability means keeping the 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. Enter EDB Postgres™ Failover Manager, the high availability solution from EnterpriseDB® (EDB™) that was recently enhanced with controlled switchover and switchback and new options for customized configurations. (Read the release.)
EDB 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 9s-based high availability solutions.
For EDB customers already using EDB Failover Manager, taking advantage of new features means upgrading. With the introduction of a new upgrade utility in EFM 2.1, making use of the new features is now more of a turnkey process.. What follows is a summary of some key steps in the upgrade process and what to expect, such as changes that have been made to configuration files and how to upgrade your files to 2.1 versions. We will assume the default cluster name ‘efm’ here, so the files that are used are efm.properties and efm.nodes in the /etc/efm-2.1M/font> directory.
(For information on how to use other cluster names see section 4.3 of the user’s guide.)
We will discuss the changes to the two configuration files below. 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.0 to 2.1. The only difference is an extra line of comment text at the top of the efm.nodes.in template file:
# List of node address:port combinations separated by whitespace.
# The list should include at least the membership coordinator's address.
New in 2.1, a “membership coordinator” makes it easier to add existing nodes to a running cluster. If there are, for example, already five nodes in a cluster, you don’t need to add all five addresses to the file when starting a new agent. Only one address is needed, and that address is available from the efm cluster-status <cluster name> output (generally the first node started).
Section 3.2.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 2.1 efm.nodes file for you from the file your deployment currently utilizes but you can also just copy the file as-is to your 2.1 installation, making sure the permission and ownership match the efm.nodes.in the template file.
The efm.properties File
This section discusses changes to the properties used by Failover Manager at startup. For each property, description text in the file and the user documentation gives more information. There are some properties that didn’t change, but they can now be used in different ways:
The following two properties―jgroups.max.tries and jgroups.timeout―were removed. They were replaced by:
The following properties have been added:
The above lists the changes to the individual properties. They have also been regrouped within the file to help make related properties easier to understand. 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 2.1 includes an upgrade feature that can be used to quickly migrate your 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.0/ directory. It will convert their information into 2.1 files in /etc/efm-2.1 (any existing files will be renamed to include a timestamp).
The following example shows the tool run with the default ‘efm’ cluster name:
[root@FOUR efm-2.1]}> /usr/efm-2.1/bin/efm upgrade-conf efm
Processing efm.properties file.
Setting new property node.timeout to 50 (sec) based on existing timeout 5000 (ms) and max tries 10.
Processing efm.nodes file.
Upgrade of files is finished. Please ensure that the new file permissions match those of the template files before starting EFM.
The db.service.name property should be set before starting a non-witness agent.
From the output, you can see that the old jgroups.* property values were used to set the new node.timeoutvalue. Unless you are running your database servers through pg_ctl, you should edit the file to set the db.service.name property. All other new properties will be set to appropriate default values.
In future blogs with screencasts, we will cover all of the 2.1 cluster properties in more detail, along with improvements to starting up a Failover Manager cluster.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.