Changes for EDB Failover Manager 2.0

EDB Failover Manager 2.0, released in June, included several changes from 1.X. The user's guide contains information on upgrading and a full description of the properties. This blog gives a little more detail about just some of the new features.
 

New 'efm' command

The service interface now contains only the standard commands, such as start, stop,  and status. Ditto for systemctl on RHEL 7. For everything else, there is a new 'efm' script that is installed in /usr/efm-2.0/bin. This script is now used for commands such as cluster-status, stop-cluster, encrypt, etc, in addition to new commands in version 2.0. A full description is here.

Cluster name simplification

Every failover manager cluster running in the same network should have a unique cluster name. In 1.X, there were two separate places that a cluster name was specified: the service script (so that it could find the properties file location) and in the properties file itself (to define the name used by jgroups for clustering).

Version 2.0 simplifies this by using the convention that your cluster name is the same as the .properties and .nodes file names, and the files are expected in the /etc/efm-2.0 directory. Thus, a single parameter in the service script tells it what file information needs to be passed into the agent at startup. Likewise, passing the cluster name into the 'efm' script tells the script where to find the needed files in order to connect to a running agent (for instance, when running the 'cluster-status' command). There is no more cluster.name parameter in the properties file.

This makes it even harder for you to accidentally run two clusters that cause interference with each other, and cuts down on the information needed to run failover manager. Section 4.9 of the user's guide has full information on how to run more than once cluster at a time, using separate cluster names. The change also simplifies the password text encryption, because you don't need to save the cluster name in a properties file first before running the encrypt utility.

Specifying initial cluster addresses

In 1.X, a cluster always had exactly 3 nodes, with the addresses never changing. You specified the addresses for these in each properties file. This accomplished two things:

1. The cluster knew which node addresses were allowed to join.
2. An agent, at startup, knew which addresses to contact to find the other cluster members.

EFM 2.0 supports an arbitrary number of standby (or, for that matter, witness) nodes. You may not know all of the addresses when starting the initial members -- you might, for instance, add another standby months after the cluster was started. So now the properties file doesn't contain agent/witness addresses. Each properties file records only that node's binding address (which was inferred from agents/witness properties in 1.X) and whether or not a node is a witness node.

After starting the first member, the two steps above are more explicit. For step 1, the 'efm' utility is used to add a new node's information to the list of allowed addresses. For step 2, you now start an agent with a list of existing cluster members in a .nodes file, kept in the same directory as the properties file.

After an agent joins the cluster, EFM will keep this file up-to-date for you as other nodes join or leave the cluster. Section 4.2 of the user's guide walks you through these steps.