3.2 Configuring Failover Manager

Table of Contents Previous Next


3 Installing and Configuring Failover Manager : 3.2 Configuring Failover Manager

The efm.properties file contains the properties of the individual node on which it resides, while the efm.nodes file contains a list of the current Failover Manager cluster members.
The Failover Manager installer creates a file template for the cluster properties file named efm.properties.in in the /etc/efm-2.0 directory. After completing the Failover Manager installation, you must make a working copy of the template before modifying the file contents.
The following command copies the efm.properties.in file, creating a properties file named efm.properties:
# cp /etc/efm-2.0/efm.properties.in /etc/efm-2.0/efm.properties
Please note: By default, Failover Manager expects the cluster properties file to be named efm.properties. If you name the properties file something other than efm.properties, you must modify the service script to instruct Failover Manager to use a different name.
The property files are owned by root. The Failover Manager service script expects to find the files in the /etc/efm-2.0 directory. If you move the property file to another location, you must create a symbolic link that specifies the new location.
Note that you must use the efm encrypt command to encrypt the value supplied in the db.password.encrypted parameter. For more information about encrypting a password, see Section 3.2.1.2.
You can use the parameters listed in the cluster properties file to specify connection properties and behaviors for your Failover Manager cluster. Modifications to configuration parameter settings will be applied when Failover Manager starts. If you modify a parameter value (with the exception of the efm.license parameter) you must restart Failover Manager to apply the changes.
Property values are case-sensitive. Note that while Postgres uses quoted strings in parameter values, Failover Manager does not allow quoted strings in the parameter values. For example, while you might specify an IP address in a PostgreSQL configuration parameter as:
Use the efm.license parameter to provide the Failover Manager product key:
The auto.failover parameter enables automatic failover. By default, auto.failover is set to true.
# Whether or not failover will happen automatically when the master
# fails.
Set to false if you want to receive the failover notifications
# but
not have EFM actually perform the failover steps.
# The
value of this property must be the same across all agents.
Use the auto.reconfigure parameter to instruct Failover Manager to enable or disable automatic reconfiguration of remaining Standby servers after the primary standby is promoted to Master. Set the parameter to true to enable automatic reconfiguration (the default) or false to disable automatic reconfiguration. This property is not required on a dedicated witness node.
Please note: primary_conninfo is a space-delimited list of keyword=value pairs.
Please note: If you are using replication slots to manage your WAL segments, automatic reconfiguration is not supported; you should set auto.reconfigure to false. For more information, see Section 2.2.
# The value for the password property should be the output from
# 'efm encrypt' -- do not include clear text password here. To
# prevent accidental sharing of passwords among clusters, the
# cluster name is incorporated into the encrypted password. If
# you change the cluster name (the name of this file), you must
# encrypt the password again with the new name.

# The db.port property must be the same for all nodes.
The db.reuse.connection.count parameter allows the administrator to specify the number of times Failover Manager reuses the same database connection to check the database health. The default value is 0, indicating that Failover Manager will create a fresh connection each time. This property is not required on a dedicated witness node.
Use the admin.port parameter to specify the port on which Failover Manager listens for administrative commands.
The local.period parameter specifies how many seconds between attempts to contact the database server.
The
local.timeout parameter specifies how long an agent will wait for a response from the local database server.
The
local.timeout.final parameter specifies how long an agent will wait after the final attempt to contact the database server on the current node. If a response is not received from the database within the number of seconds specified by the local.timeout.final parameter, the database is assumed to have failed.
# These properties apply to the connection(s) EFM uses to monitor
# the local database. Every 'local.period' seconds, a database
# check is made in a background thread. If the main monitoring
# thread does not see that any checks were successful in
# 'local.timeout' seconds, then the main thread makes a final
# check with a timeout value specified by the
# 'local.timeout.final' value. All values are in seconds.

# Whether EFM uses single or multiple connections for database#
# checks is controlled by the 'db.reuse.connection.count'
# property.
local.period=10
local.timeout=60
local.timeout.final=10
Use the remote.timeout parameter to specify how many seconds an agent waits for a response from a remote database server (i.e., how long a standby agent waits to verify that the master database is actually down before performing failover).
The jgroups.max.tries parameter specifies the number of consecutive times Failover Manager attempts to contact a node before the node is assumed to be down. jgroups.timeout specifies the number of milliseconds before the connection attempts time out.
Use the user.email parameter to specify the email address of a system administrator.
The bind.address parameter specifies the IP address and port number of the agent on the current node of the Failover Manager cluster.
Set the is.witness parameter to true to indicate that the current node is a witness node. If is.witness is true, the local agent will not check to see if a local database is running.
The Postgres pg_is_in_recovery() function is a boolean function that reports the recovery state of a database. The function returns true if the database is in recovery, or false if the database is not in recovery. When an agent starts, it connects to the local database and invokes the pg_is_in_recovery() function. If the server responds true, the agent assumes the role of standby; if the server responds false, the agent assumes the role of master. If is.witness is true, Failover Manager will not check the recovery state.
Use the db.service.owner parameter to specify the name of the operating system user that owns the cluster that is being managed by Failover Manager. This property is not required on a dedicated witness node.
Use the db.recovery.conf.dir parameter to specify the location to which a recovery file will be written on the Master node of the cluster. This property is not required on a dedicated witness node.
Use the db.bin parameter to specify the location of the pg_ctl command for the local database server. This property is not required on a dedicated witness node.
The virtualIp parameter specifies virtual IP address information for the Failover Manager cluster. Use the virtualIp.interface parameter to specify an alias for your network adaptor (for example, eth0:1 specifies an alias for the adaptor, eth0). You might create multiple aliases for each adaptor on a given host; for more information about running multiple agents on a single node, please see Section 4.9. The virtualIp.netmask parameter specifies which bits in the virtual IP address refer to the network address (as opposed to the host address).
Use the pingServer parameter to specify the IP address of a server that Failover Manager can use to confirm that network connectivity is not a problem.
Use the pingServerCommand parameter to specify the command used to test network connectivity.
script.fence specifies an optional path to a user-supplied script that will be invoked during the promotion of a standby node to master node.
Please note that the fencing script runs as the efm user; you must ensure that the efm user has sufficient privileges to invoke any commands included in the fencing script. For more information about Failover Manager permissions, please see Section 3.1.
Use the script.post.promotion parameter to specify an optional path to a user-supplied script that will be invoked after a standby node has been promoted to master.
Use the jgroups.loglevel and efm.loglevel parameters to specify the level of detail logged by Failover Manager. The default value is INFO. For more information about logging, see Section 6, Controlling Logging.
Failover Manager requires you to encrypt your database password before including it in the cluster properties file. Use the efm utility (located in the /usr/efm-2.0/bin directory) to encrypt the password; open a command line, and enter the command:
# efm encrypt cluster_name
Where cluster_name specifies the name of the Failover Manager cluster.
The following example demonstrates using the encrypt utility to encrypt a password for the acctg cluster:

3 Installing and Configuring Failover Manager : 3.2 Configuring Failover Manager

Table of Contents Previous Next