Table of Contents Previous Next


3 Installing and Configuring Failover Manager : 3.5 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. By default, the installer places the files in the /etc/edb/efm-3.2 directory.
The Failover Manager installer creates a file template for the cluster properties file named efm.properties.in in the /etc/edb/efm-3.2 directory. After completing the Failover Manager installation, you must make a working copy of the template before modifying the file contents. For example, the following command copies the efm.properties.in file, creating a properties file named efm.properties:
# cp /etc/edb/efm-3.2/efm.properties.in /etc/edb/efm-3.2 /efm.properties
# chown efm:efm 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 or unit file 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/edb/efm-3.2 directory. If you move the property file to another location, you must create a symbolic link that specifies the new location.
Use the properties in the efm.properties file to specify connection, administrative, and operational details for Failover Manager.
The db.user specified must have sufficient privileges to invoke selected PostgreSQL commands on behalf of Failover Manager. For more information, please see Section 2.2.
Use the db.service.owner property 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.
Specify the name of the database service in the db.service.name property if you use the service or systemctl command when starting or stopping the service.
You should use the same service control mechanism (pg_ctl, service, or systemctl) each time you start or stop the database service. If you use the pg_ctl program to control the service, specify the location of the pg_ctl program in the db.bin property.
Use the db.recovery.conf.dir property to specify the location to which a recovery file will be written on the Master node of the cluster, and a trigger file is written on a Standby. This property is not required on a dedicated witness node.
Use the jdbc.sslmode property to instruct Failover Manager to use SSL connections; by default, SSL is disabled.
Use the user.email property to specify an email address (or multiple email addresses) that will receive any notifications sent by Failover Manager.
Use the notification.level property to specify the minimum severity level at which Failover Manager will send user notifications or when a notification script is called. For a complete list of notifications, please see Section 7.
Use the script.notification property to specify the path to a user-supplied script that acts as a notification service; the script will be passed a message subject and a message body. The script will be invoked each time Failover Manager generates a user notification.
# Absolute path to script run for user notifications.
#
# This is an optional user-supplied script that can be used for
# notifications instead of email. This is required if not using
# email notifications. Either/both can be used. The script will
# be passed two parameters: the message subject and the message
# body.
The bind.address property specifies the IP address and port number of the agent on the current node of the Failover Manager cluster.
Use the admin.port property to specify a port on which Failover Manager listens for administrative commands.
Set the is.witness property 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 there is no local database, the agent will assume an idle state.
If is.witness is true, Failover Manager will not check the recovery state.
The local.period property specifies how many seconds between attempts to contact the database server.
The
local.timeout property specifies how long an agent will wait for a positive response from the local database server.
The
local.timeout.final property 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 property, the database is assumed to have failed.
Use the remote.timeout property 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).
Use the node.timeout property to specify the number of seconds that an agent will wait for a response from a node when determining if a node has failed. The node.timeout property value specifies a timeout value for agent-to-agent communication; other timeout properties in the cluster properties file specify values for agent-to-database communication.
Use the stop.isolated.master property to instruct Failover Manager to shut down the database if a master agent detects that it is isolated. When true (the default), Failover Manager will stop the database before invoking the script specified in the script. master.isolated property.
Use the stop.failed.master property to instruct Failover Manager to attempt to shut down a master database if it can not reach the database. If true, Failover Manager will run the script specified in the script.db.failure property after attempting to shut down the database.
Use the pingServer property 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 property to specify the command used to test network connectivity.
Use the auto.allow.hosts property to instruct the server to use the addresses specified in the .nodes file of the first node started to update the allowed host list. Enabling this property (setting auto.allow.hosts to true) can simplify cluster start-up.
Use the stable.nodes.file property to instruct the server to not rewrite the nodes file when a node joins or leaves the cluster. This property is most useful in clusters with unchanging IP addresses.
The db.reuse.connection.count property 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.
The auto.failover property 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 property to instruct Failover Manager to enable or disable automatic reconfiguration of remaining Standby servers after the primary standby is promoted to Master. Set the property 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.
Use the promotable property to indicate that a node should not be promoted. To override the setting, use the efm set-priority command at runtime; for more information about the efm set-priority command, see Section 5.3.
Use the minimum.standbys property to specify the minimum number of standby nodes that will be retained on a cluster; if the standby count drops to the specified minimum, a replica node will not be promoted in the event of a failure of the master node.
Use the recovery.check.period property to specify the number of seconds that Failover Manager will wait before checks to see if a database is out of recovery.
Use the auto.resume.period property to specify the number of seconds (after a monitored database fails, and an agent has assumed an idle state) that an agent will attempt to resume monitoring that database.
Failover Manager provides support for clusters that use a virtual IP. If your cluster uses a virtual IP, provide the IP address and prefix in the virtualIp and virtualIp.prefix properties. If virtualIp is left blank, virtual IP support is disabled.
Use the virtualIp.interface property to provide the network interface used by the VIP.
The specified virtual IP address is assigned only to the master node of the cluster. If you specify virtualIp.single=true, the same VIP address will be used on the new master in the event of a failover. Specify a value of false to provide a unique IP address for each node of the cluster.
# These properties specify the IP and prefix length that will be
# remapped during failover. If you do not use a VIP as part of
# your failover solution, leave the virtualIp property blank to
# disable Failover Manager support for VIP processing (assigning,
# releasing, testing reachability, etc).

#
# If you specify a VIP, the interface and prefix are required.
#
# By default, the virtualIp and virtualIp.prefix values must be
# the same across all agents. If you set virtualIp.single to
# false, you can specify unique values for virtualIp and
# virtualIp.prefix on each node.

#
# If you are using an IPv4 address, the virtualIp.interface value
# should not contain a secondary virtual ip id (do not include
# ":1", etc).
virtualIp=
virtualIp.interface=
virtualIp.prefix=
virtualIp.single=true
Provide a script name after the script.load.balancer.attach property to identify a script that will be invoked when a node should be attached to the load balancer. Use the script.load.balancer.detach property to specify the name of a script that will be invoked when a node should be detached from the load balancer. Include the %h placeholder to represent the IP address of the node that is being attached or removed from the cluster.
# Absolute path to load balancer scripts
# The attach script is called when a node should be attached to
# the load balancer, for example after a promotion. The detach
# script is called when a node should be removed, for example
# when a database has failed or is about to be stopped. Use %h to
# represent the IP/hostname of the node that is being
# attached/detached.

#
# Example:
# script.load.balancer.attach=/somepath/attachscript %h
script.load.balancer.attach=
script.load.balancer.detach=
script.fence specifies the path to an optional user-supplied script that will be invoked during the promotion of a standby node to master node.
# absolute path to fencing script run during promotion
#

# This is an optional user-supplied script that will be run
# during failover on the standby database node. If left blank,
# no action will be taken. If specified, EFM will execute this
# script before promoting the standby.
#
# Parameters can be passed into this script for the failed master
# and new primary node addresses. Use %p for new primary and %f
# for failed master. On a node that has just been promoted, %p
# should be the same as the node's efm binding address.

#
# Example:
# script.fence=/somepath/myscript %p %f
#
# NOTE: FAILOVER WILL NOT OCCUR IF THIS SCRIPT RETURNS A NON-ZERO EXIT CODE.
Use the script.post.promotion property to specify the path to an optional user-supplied script that will be invoked after a standby node has been promoted to master.
# Absolute path to fencing script run after promotion
#

# This is an optional user-supplied script that will be run after
# failover on the standby node after it has been promoted and
# is no longer in recovery. The exit code from this script has
# no effect on failover manager, but will be included in a
# notification sent after the script executes.

#
# Parameters can be passed into this script for the failed master
# and new primary node addresses. Use %p for new primary and %f
# for failed master. On a node that has just been promoted, %p
# should be the same as the node's efm binding address.

#
# Example:
# script.post.promotion=/somepath/myscript %f %p
Use the script.resumed property to specify an optional path to a user-supplied script that will be invoked when an agent resumes monitoring of a database.
Use the script.db.failure property to specify the complete path to an optional user-supplied script that Failover Manager will invoke if an agent detects that the database that it monitors has failed.
Use the script.master.isolated property to specify the complete path to an optional user-supplied script that Failover Manager will invoke if the agent monitoring the master database detects that the master is isolated from the majority of the Failover Manager cluster. This script is called immediately after the VIP is released (if a VIP is in use).
Use the script.remote.pre.promotion property to specify the path and name of a script that will be invoked on any agent nodes not involved in the promotion when a node is about to promote its database to master.
Include the %p placeholder to identify the address of the new primary node.
Use the script.remote.post.promotion property to specify the path and name of a script that will be invoked on any non-master nodes after a promotion occurs.
Include the %p placeholder to identify the address of the new primary node.
Use the script.custom.monitor property to provide the name and location of an optional script that will be invoked on regular intervals (specified in seconds by the custom.monitor.interval property).
Use custom.monitor.timeout to specify the maximum time that the script will be allowed to run; if script execution does not complete within the time specified, Failover Manager will send a notification.
Set custom.monitor.safe.mode to true to instruct Failover Manager to report non-zero exit codes from the script, but not promote a standby as a result of an exit code.
Use the sudo.command property to specify a command that will be invoked by Failover Manager when performing tasks that require extended permissions. Use this option to include command options that might be specific to your system authentication.
Use the sudo.user.command property to specify a command that will be invoked by Failover Manager when executing commands that will be performed by the database owner.
Use the lock.dir property to specify an alternate location for the Failover Manager lock file; the file prevents Failover Manager from starting multiple (potentially orphaned) agents for a single cluster on the node.
Use the log.dir property to specify the location to which agent log files will be written; Failover Manager will attempt to create the directory if the directory does not exist.
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.
Use the jvm.options property to pass JVM-related configuration information. The default setting specifies the amount of memory that the Failover Manager agent will be allowed to use.

3 Installing and Configuring Failover Manager : 3.5 Configuring Failover Manager

Table of Contents Previous Next