The Cluster Properties File¶
Each node in a Failover Manager cluster has a properties file (by default, named
efm.properties) that contains the properties of the individual node
on which it resides. The Failover Manager installer creates a file template
for the properties file named
efm.properties.in in the
After completing the Failover Manager installation, you must make a working copy of the template before modifying the file contents:
# cp /etc/edb/efm-3.9/efm.properties.in /etc/edb/efm-3.9/efm.properties
After copying the template file, change the owner of the file to
# 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.
After creating the cluster properties file, add (or modify) configuration parameter values as required. For detailed information about each property, see Specifying Cluster Properties.
The property files are owned by
root. The Failover Manager service
script expects to find the files in the
/etc/edb/efm-3.9 directory. If
you move the property file to another location, you must create a
symbolic link that specifies the new location.
Please note that all user scripts referenced in the properties file will be invoked as the Failover Manager user.
Specifying Cluster Properties¶
You can use the properties listed in the cluster properties file to specify connection properties and behaviors for your Failover Manager cluster. Modifications to property settings will be applied when Failover Manager starts. If you modify a property value 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 property values. For example, while you might specify an IP address in a Postgres configuration parameter as:
Failover Manager requires that the value not be enclosed in quotes:
Use the properties in the
efm.properties file to specify connection,
administrative, and operational details for Failover Manager.
Use the following properties to specify connection details for the Failover Manager cluster:
# The value for the password property should be the output from # 'efm encrypt' -- do not include a cleartext 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. db.user= db.password.encrypted= db.port= db.database=
db.user specified must have sufficient privileges to invoke selected
PostgreSQL commands on behalf of Failover Manager. For more information,
please see Prerequisites.
For information about encrypting the password for the database user, see Encrypting Your Database Password.
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.
# This property tells EFM which OS user owns the $PGDATA dir for # the 'db.database'. By default, the owner is either 'postgres' # for PostgreSQL or 'enterprisedb' for EDB Postgres Advanced # Server. However, if you have configured your db to run as a # different user, you will need to copy the /etc/sudoers.d/efm-XX # conf file to grant the necessary permissions to your db owner. # # This username must have write permission to the # 'db.data.dir' specified below. db.service.owner=
Specify the name of the database service in the
if you use the service or systemctl command when starting or stopping
# Specify the proper service name in order to use service commands rather # than pg_ctl to start/stop/restart a database. For example, if this property # is set, then 'service <name> restart' or 'systemctl restart <name>' # (depending on OS version) will be used to restart the database rather than pg_ctl. # This property is required if running the database as a service. db.service.name=
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
pg_ctl program to control the service, specify the location of the
pg_ctl program in the
# Specify the directory containing the pg_controldata/pg_ctl commands, for example: # /usr/edb/as11/bin. Unless the db.service.name property is used, the pg_ctl # command is used to start/stop/restart databases as needed after a # failover or switchover. This property is required. db.bin=
db.data.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 required on master and
standby nodes; it is not required on a dedicated witness node.
# For database version 12 and up, this is the directory where a standby.signal # file will exist for a standby node. For previous versions, this is the # location of the db recovery.conf file on the node. On a standby node, # the trigger file location is read from the file in this directory. # After a failover, the recovery.conf files on remaining standbys are changed # to point to the new master db (a copy of the original is made first). On a # master node, a recovery.conf file will be written during failover and # promotion to ensure that the master node can not be restarted as the # master database. # This corresponds to database environment variable PGDATA and should be same # as the output of query 'show data_directory;' on respective database. db.data.dir=
db.config.dir property to specify the location of database configuration files if they are not stored in the same directory as the
standby.signal file. This should be the value specified by the
config_file parameter directory of your Advanced Server or PostgreSQL installation. This value will be used as the location of the Postgres
data directory when stopping, starting, or restarting the database.
# Specify the location of database configuration files if they are not contained # in the same location as the recovery.conf or standby.signal file. This is most # likely the case for Debian installations. The location specified will be used as # the -D value (the location of the data directory for the cluster) # when calling pg_ctl to start or stop the database. If this property is blank, # the db.data.dir location specified by the db.data.dir property will be used. # This corresponds to the output of query 'show config_file;' on respective database. db.config.dir=
For more information about database configuration files, visit the PostgreSQL website
jdbc.sslmode property to instruct Failover Manager to use SSL
connections; by default, SSL is disabled.
# Use the jdbc.sslmode property to enable ssl for EFM # connections. Setting this property to anything but 'disable' # will force the agents to use 'ssl=true' for all JDBC database # connections (to both local and remote databases). # Valid values are: # # disable - Do not use ssl for connections. # verify-ca - EFM will perform CA verification before allowing # the certificate. # require - Verification will not be performed on the server # certificate. jdbc.sslmode=disable
For information about configuring and using SSL, please see:
user.email property to specify an email address (or multiple
email addresses) that will receive any notifications sent by Failover
# Email address(es) for notifications. The value of this # property must be the same across all agents. Multiple email # addresses must be separated by space. If using a notification # script instead, this property can be left blank. user.email=
from.email property specifies the value that will be used as the
sender’s address on any email notifications from Failover Manager. You
from.emailblank to use the default value (
- specify a custom value for the email address.
- specify a custom email address, using the
%hplaceholder to represent the name of the node host (e.g., example@%h). The placeholder will be replaced with the name of the host as returned by the Linux hostname utility.
For more information about notifications, see Notifications .
# Use the from.email property to specify the from email address that # will be used for email notifications. Use the %h placeholder to # represent the name of the node host (e.g. example@%h). The # placeholder will be replaced with the name of the host as returned # by the hostname command. # Leave blank to use the default, efm@localhost. from.email=
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 Notifications.
# Minimum severity level of notifications that will be sent by # the agent. The minimum level also applies to the notification # script (below). Valid values are INFO, WARNING, and SEVERE. # A list of notifications is grouped by severity in the user's # guide. notification.level=INFO
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. script.notification=
bind.address property specifies the IP address and port number of
the agent on the current node of the Failover Manager cluster.
# This property specifies the ip address and port that jgroups # will bind to on this node. The value is of the form # <ip>:<port>. # Note that the port specified here is used for communicating # with other nodes, and is not the same as the admin.port below, # used only to communicate with the local agent to send control # signals. # For example, <provide_your_ip_address_here>:7800 bind.address=
admin.port property to specify a port on which Failover Manager
listens for administrative commands.
# This property controls the port binding of the administration # server which is used for some commands (ie cluster-status). The # default is 7809; you can modify this value if the port is # already in use. admin.port=7809
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.
# Specifies whether or not this is a witness node. Witness nodes # do not have local databases running. is.witness=
pg_is_in_recovery() function is a boolean function that
reports the recovery state of a database. The function returns
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
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.
true, Failover Manager will not check the recovery state.
The following properties specify properties that apply to the local server:
local.periodproperty specifies how many seconds between attempts to contact the database server.
local.timeout propertyspecifies how long an agent will wait for a positive response from the local database server.
local.timeout.finalproperty 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.
For example, given the default values of these properties, a check of the local database happens once every 10 seconds. If an attempt to contact the local database does not come back positive within 60 seconds, Failover Manager makes a final attempt to contact the database. If a response is not received within 10 seconds, Failover Manager declares database failure and notifies the administrator listed in the user.email property. These properties are not required on a dedicated witness node.
# 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
If necessary, you should modify these values to suit your business model.
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).
# Timeout for a call to check if a remote database is responsive. # For example, this is how long a standby would wait for a # DB ping request from itself and the witness to the master DB # before performing failover. remote.timeout=10
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
# The total amount of time in seconds to wait before determining # that a node has failed or been disconnected from this node. # # The value of this property must be the same across all agents. node.timeout=50
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
# Shut down the database after a master agent detects that it has # been isolated from the majority of the efm cluster. If set to # true, efm will stop the database before running the # 'script.master.isolated' script, if a script is specified. stop.isolated.master=true
stop.failed.master property to instruct Failover Manager to
attempt to shut down a master database if it can not reach the database.
true, Failover Manager will run the script specified in the
script.db.failure property after attempting to shut down the database.
# Attempt to shut down a failed master database after EFM can no # longer connect to it. This can be used for added safety in the # case a failover is caused by a failure of the network on the # master node. # If specified, a 'script.db.failure' script is run after this attempt. stop.failed.master=true
master.shutdown.as.failure parameter to indicate that any
shutdown of the Failover Manager agent on the master node should be
treated as a failure. If this parameter is set to
true and the master
agent stops (for any reason), the cluster will attempt to confirm if the
database on the master node is running:
- If the database is reached, a notification will be sent informing you of the agent status.
- If the database is not reached, a failover will occur.
# Treat a master agent shutdown as a failure. This can be set to # true to treat a master agent shutdown as a failure situation, # e.g. during the shutdown of a node, accidental or otherwise. # Caution should be used when using this feature, as it could # cause an unwanted promotion in the case of performing master # database maintenance. # Please see the user's guide for more information. master.shutdown.as.failure=false
master.shutdown.as.failure property is meant to catch user error,
rather than failures such as the accidental shutdown of a master node. The
proper shutdown of a node can appear to the rest of the cluster like a
user has stopped the master Failover Manager agent (for example to
perform maintenance on the master database). If you set the
master.shutdown.as.failure property to
true, care must be taken when
To perform maintenance on the master database when
true, you should stop the master agent and
wait to receive a notification that the master agent has failed but the
database is still running. Then it is safe to stop the master database.
Alternatively, you can use the
efm stop-cluster command to stop all of
the agents without failure checks being performed.
ping.server.ip property to specify the IP address of a server that
Failover Manager can use to confirm that network connectivity is not a
# This is the address of a well-known server that EFM can ping # in an effort to determine network reachability issues. It # might be the IP address of a nameserver within your corporate # firewall or another server that *should* always be reachable # via a 'ping' command from each of the EFM nodes. # # There are many reasons why this node might not be considered # reachable: firewalls might be blocking the request, ICMP might # be filtered out, etc. # # Do not use the IP address of any node in the EFM cluster # (master, standby, or witness) because this ping server is meant # to provide an additional layer of information should the EFM # nodes lose sight of each other. # # The installation default is Google's DNS server. ping.server.ip=126.96.36.199
ping.server.command property to specify the command used to test
# This command will be used to test the reachability of certain # nodes. # # Do not include an IP address or hostname on the end of # this command - it will be added dynamically at runtime with the # values contained in 'virtual.ip' and 'ping.server.ip'. # # Make sure this command returns reasonably quickly - test it # from a shell command line first to make sure it works properly. ping.server.command=/bin/ping -q -c3 -w5
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.
# Have the first node started automatically add the addresses # from its .nodes file to the allowed host list. This will make # it faster to start the cluster when the initial set of hosts # is already known. auto.allow.hosts=false
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.
# When set to true, EFM will not rewrite the .nodes file whenever # new nodes join or leave the cluster. This can help starting a # cluster in the cases where it is expected for member addresses # to be mostly static, and combined with 'auto.allow.hosts' makes # startup easier when learning failover manager. stable.nodes.file=false
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.
# This property controls how many times a database connection is # reused before creating a new one. If set to zero, a new # connection will be created every time an agent pings its local # database. db.reuse.connection.count=0
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. auto.failover=true
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
enable automatic reconfiguration (the default) or
false to disable
automatic reconfiguration. This property is not required on a dedicated
witness node. If you are using Advanced Server or PostgreSQL version 11 or earlier,
recovery.conf file will be backed up during the reconfiguration process.
# After a standby is promoted, Failover Manager will attempt to # update the remaining standbys to use the new master. For database # versions before 12, Failover Manager will back up recovery.conf. # Then it will change the host parameter of the primary_conninfo entry # in recovery.conf or postgresql.auto.conf, and restart the database. The # restart command is contained in either the efm_db_functions or # efm_root_functions file; default when not running db as an os # service is: "pg_ctl restart -m fast -w -t <timeout> -D <directory>" # where the timeout is the local.timeout property value and the # directory is specified by db.data.dir. To turn off # automatic reconfiguration, set this property to false. auto.reconfigure=true
primary_conninfo is a space-delimited list of keyword=value
Please note: If you are using replication slots to manage your WAL
segments, automatic reconfiguration is not supported; you should set
false. In the event of a failover, you must
manually reconfigure the standby servers.
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
Using the efm Utility.
# A standby with this set to false will not be added to the # failover priority list, and so will not be available for # promotion. The property will be used whenever an agent starts # as a standby or resumes as a standby after being idle. After # startup/resume, the node can still be added or removed from the # priority list with the 'efm set-priority' command. This # property is required for all non-witness nodes. promotable=true
If the same amount of data has been written to more than one standby node, and
a failover occurs, the
use.replay.tiebreaker value will determine how Failover Manager
selects a replacement master. Set the
use.replay.tiebreaker property to
to instruct Failover Manager to failover to the node that will come out of recovery
faster, as determined by the log sequence number. To ignore the log sequence number
and promote a node based on user preference, set
# Use replay LSN value for tiebreaker when choosing a standby to promote # before using failover priority. Set this property to true to consider # replay location as more important than failover priority (as seen in # cluster-status command) when choosing the "most ahead" standby to promote. use.replay.tiebreaker=true
You can use the
application.name property to provide the name of an
application that will be copied to the
before restarting an old master node as a standby.
# During a switchover, recovery settings are copied from a standby # to the original master. If the application.name property is set, # Failover Manager will replace the application_name portion of the # primary_conninfo entry with this property value before starting # the original master database as a standby. If this property is # not set, Failover Manager will remove the parameter value # from primary_conninfo. application.name=
Please note: You should set the
application.name property on the master and
any promotable standby; in the event of a failover/switchover, the master node
could potentially become a standby node again.
restore.command property to instruct Failover Manager to update the
restore_command when a new master is promoted.
%h represents the address of the new master; Failover Manager will replace
%h with the address of the new master.
%p are placeholders used by the server. If the property is left blank, Failover Manager will not update the
restore_command values on the standbys after a promotion.
See the PostgreSQL documentation for more information about using a restore_command.
# If the restore_command on a standby restores directly from the master node, use this property # to have Failover Manager change the command when a new master is promoted. # # Use the %h placeholder to represent the address of the new master. During promotion # it will be replaced with the address of the new master. # # If not specified, failover manager will not change the restore_command value, if any, # on standby nodes. # # Example: # restore.command=scp <db service owner>@%h:/var/lib/edb/as12/data/archive/%f %p restore.command=
The synchronous_standby_names parameter on the master node specifies the names and count of the synchronous standby servers that will confirm receipt of data, to ensure that the master nodes can accept write transactions. When set to true, Failover Manager will reduce the number of synchronous standby servers and reload the configuration of the master node to reflect the current value.
# Reduce num_sync when the number of synchronous standbys drops below the # value required by the master database. If set to true, Failover Manager will # reduce the number of standbys needed in the master's # synchronous_standby_names property and reload the master configuration. # Failover Manager will not reduce the number below 1, taking the master # out of synchronous replication, unless the reconfigure.sync.master # property is also set to true. reconfigure.num.sync=false
reconfigure.sync.master property to
true to take the master database
out of synchronous replication mode if the number of standby nodes drops below the
level required. Set
false to send a notification
if the standby count drops, but not interrupt synchronous replication.
# Take the master database out of synchronous replication mode when needed. # If set to true, Failover Manager will clear the synchronous_standby_names # configuration parameter on the master if the number of synchronous # standbys drops below the required level for the master to accept writes. # If set to false, Failover Manager will detect the situation but will only # send a notification if the standby count drops below the required level. # # CAUTION: TAKING THE MASTER DATABASE OUT OF SYNCHRONOUS MODE MEANS THERE # MAY ONLY BE ONE COPY OF DATA. DO NOT MAKE THIS CHANGE UNLESS YOU ARE SURE # THIS IS OK. reconfigure.sync.master=false
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.
# Instead of setting specific standbys as being unavailable for # promotion, this property can be used to set a minimum number # of standbys that will not be promoted. Set to one, for # example, promotion will not happen if it will drop the number # of standbys below this value. This property must be the same on # each node. minimum.standbys=0
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.
# Time in seconds between checks to see if a promoting database # is out of recovery. recovery.check.period=2
restart.connection.timeout property to specify the number of
seconds that Failover Manager will attempt to connect to a newly
reconfigured master or standby node while the database on that node
prepares to accept connections.
# Time in seconds to keep trying to connect to a database after a # start or restart command returns successfully but the database # is not ready to accept connections yet (a rare occurance). This # applies to standby databases that are restarted when being # reconfigured for a new master, and to master databases that # are stopped and started as standbys during a switchover. # This retry mechanism is unrelated to the auto.resume.period parameter. restart.connection.timeout=60
auto.resume.period property to specify the number of seconds
(after a monitored database fails, and an agent has assumed an idle
state, or when starting in IDLE mode) during which an agent will attempt
to resume monitoring that database.
# Period in seconds for IDLE agents to try to resume monitoring # after a database failure or when starting in IDLE mode. Set to # 0 for agents to not try to resume (in which case the # 'efm resume <cluster>' command is used after bringing a # database back up). auto.resume.period=0
Failover Manager provides support for clusters that use a virtual IP. If
your cluster uses a virtual IP, provide the host name or IP address in
virtual.ip property; specify the corresponding prefix in the
virtual.ip.prefix property. If
virtual.ip is left blank, virtual IP
support is disabled.
virtual.ip.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
virtual.ip.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
For information about using a virtual IP address, see Using Failover Manager with Virtual IP Addresses.
# 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 virtual.ip 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. # # If you specify a host name, it will be resolved to an IP address # when acquiring or releasing the VIP. If the host name resolves # to more than one IP address, there is no way to predict which # address Failover Manager will use. # # By default, the virtual.ip and virtual.ip.prefix values must be # the same across all agents. If you set virtual.ip.single to # false, you can specify unique values for virtual.ip and # virtual.ip.prefix on each node. # # If you are using an IPv4 address, the virtual.ip.interface value # should not contain a secondary virtual ip id (do not include # ":1", etc). virtual.ip= virtual.ip.interface= virtual.ip.prefix= virtual.ip.single=true
Please Note: If a master agent is started and the node does not currently have the VIP, the EFM agent will acquire it. Stopping a master agent does not drop the VIP from the node.
check.vip.before.promotion property to false to indicate that
Failover Manager will not check to see if a VIP is in use before
assigning it to a a new master in the event of a failure. Please note
that this could result in multiple nodes broadcasting on the same VIP
address; unless the master node is isolated or can be shut down via
another process, you should set this property to true.
# Whether to check if the VIP (when used) is still in use before # promoting after a master failure. Turning this off may allow # the new master to have the VIP even though another node is also # broadcasting it. This should only be used in environments where # it is known that the failed master node will be isolated or # shut down through other means. check.vip.before.promotion=true
Use the following properties to provide paths to scripts that reconfigure your load balancer in the event of a switchover or master failure scenario. The scripts will also be invoked in the event of a standby failure. If you are using these properties, they should be provided on every node of the cluster (master, standby, and witness) to ensure that if a database node fails, another node will call the detach script with the failed node’s address.
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. Include the
%t placeholder to instruct Failover Manager to
include an m (for a master node) or an s (for a standby node) in the
# 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. Use %t to represent the type of node being # attached or detached: the letter m will be passed in for master nodes #and the letter s for standby nodes. # # Example: # script.load.balancer.attach=/somepath/attachscript %h %t 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. script.fence=
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 script.post.promotion=
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.
# Absolute path to resume script # # This script is run before an IDLE agent resumes # monitoring its local database. script.resumed=
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.
# Absolute path to script run after database failure # This is an optional user-supplied script that will be run after # an agent detects that its local database has failed. script.db.failure=
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).
# Absolute path to script run on isolated master # This is an optional user-supplied script that will be run after # a master agent detects that it has been isolated from the # majority of the efm cluster. script.master.isolated=
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.
# Absolute path to script invoked on non-promoting agent nodes # before a promotion. # # This optional user-supplied script will be invoked on other # agents when a node is about to promote its database. The exit # code from this script has no effect on Failover Manager, but # will be included in a notification sent after the script # executes. # # Pass a parameter (%p) with the script to identify the new # primary node address. # # Example: # script.remote.pre.promotion=/path_name/script_name %p script.remote.pre.promotion=
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
%p placeholder to identify the address of the new primary
# Absolute path to script invoked on non-master agent nodes # after a promotion. # # This optional user-supplied script will be invoked on nodes # (except the new master) after a promotion occurs. The exit code # from this script has no effect on Failover Manager, but will be # included in a notification sent after the script executes. # # Pass a parameter (%p) with the script to identify the new # primary node address. # # Example: # script.remote.post.promotion=/path_name/script_name %p script.remote.post.promotion=
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.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.
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.
# Absolute path to a custom monitoring script. # # Use script.custom.monitor to specify the location and name of # an optional user-supplied script that will be invoked # periodically to perform custom monitoring tasks. A non-zero # exit value means that a check has failed; this will be treated # as a database failure. On a master node, script failure will # cause a promotion. On a standby node script failure will # generate a notification and the agent will become IDLE. # # The custom.monitor.\* properties are required if a custom # monitoring script is specified: # # custom.monitor.interval is the time in seconds between executions of the script. # # custom.monitor.timeout is a timeout value in seconds for how # long the script will be allowed to run. If script execution # exceeds the specified time, the task will be stopped and a # notification sent. Subsequent runs will continue. # # If custom.monitor.safe.mode is 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. This allows testing of the # script without affecting EFM. # script.custom.monitor= custom.monitor.interval= custom.monitor.timeout= custom.monitor.safe.mode=
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.
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.
# Command to use in place of 'sudo' if desired when efm runs # the efm_db_functions or efm_root_functions, or efm_address # scripts. # Sudo is used in the following ways by efm: # # sudo /usr/edb/efm-<version>/bin/efm_address <arguments> # sudo /usr/edb/efm-<version>/bin/efm_root_functions <arguments> # sudo -u <db service owner> /usr/edb/efm-<version>/bin/efm_db_functions <arguments> # # 'sudo' in the first two examples will be replaced by the value # of the sudo.command property. 'sudo -u <db service owner>' will # be replaced by the value of the sudo.user.command property. # The '%u' field will be replaced with the db owner. sudo.command=sudo sudo.user.command=sudo -u %u
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
# Specify the directory of lock file on the node. Failover # Manager creates a file named <cluster>.lock at this location to # avoid starting multiple agents for same cluster. If the path # does not exist, Failover Manager will attempt to create it. If # not specified defaults to '/var/lock/efm-<version>' lock.dir=
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.
# Specify the directory of agent logs on the node. If the path # does not exist, Failover Manager will attempt to create it. If # not specified defaults to '/var/log/efm-<version>'. (To store # Failover Manager startup logs in a custom location, modify the # path in the service script to point to an existing, writable # directory.) # If using a custom log directory, you must configure # logrotate separately. Use 'man logrotate' for more information. log.dir=
After enabling the UDP or TCP protocol on a Failover Manager host, you
can enable logging to syslog. Use the
syslog.protocol parameter to
specify the protocol type (UDP or TCP) and the
syslog.port parameter to
specify the listener port of the syslog host. The
may be used as an identifier for the process that created the entry; the
value must be between LOCAL0 and LOCAL7.
# Syslog information. The syslog service must be listening on # the port for the given protocol, which can be UDP or TCP. # The facilities supported are LOCAL0 through LOCAL7. syslog.host=localhost syslog.port=514 syslog.protocol=UDP syslog.facility=LOCAL1
syslog.enabled properties to specify the
type of logging that you wish to implement. Set
to enable logging to a file; enable the UDP protocol or TCP protocol and
true to enable logging to syslog. You can enable
logging to both a file and syslog.
# Which logging is enabled. file.log.enabled=true syslog.enabled=false
For more information about configuring syslog logging, see Enabling syslog Log File Entries.
efm.loglevel parameters to specify the
level of detail logged by Failover Manager. The default value is
For more information about logging, see Controlling Logging.
# Logging levels for JGroups and EFM. # Valid values are: TRACE, DEBUG, INFO, WARN, ERROR # Default value: INFO # It is not necessary to increase these values unless debugging a # specific issue. If nodes are not discovering each other at # startup, increasing the jgroups level to DEBUG will show # information about the TCP connection attempts that may help # diagnose the connection failures. jgroups.loglevel=INFO efm.loglevel=INFO
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.
# Extra information that will be passed to the JVM when starting # the agent. jvm.options=-Xmx128m