Table of Contents Previous Next


7 Notifications

user.email
script.notification
EFM node: 10.0.1.11
Cluster name: acctg
Database name: postgres
VIP: ip_address (Active|Inactive)

Database health is not being monitored.
The VIP field displays the IP address and state of the virtual IP if implemented for the node.
INFO indicates an informational message about the agent and does not require any manual intervention (for example, Failover Manager has started or stopped).
WARNING indicates that an event has happened that requires the administrator to check on the system (for example, failover has occurred).
SEVERE indicates that a serious event has happened and requires the immediate attention of the administrator (for example, failover was attempted, but was unable to complete).
The severity level designates the urgency of the notification. A notification with a severity level of SEVERE requires user attention immediately, while a notification with a severity level of INFO will call your attention to operational information about your cluster that does not require user action. Notification severity levels are not related to logging levels; all notifications are sent regardless of the log level detail specified in the configuration file.
You can use the notification.level property to specify the minimum severity level that will trigger a notification; for more information, see Section 3.4.1.
Executed fencing script script_name Results: script_results
Executed post-promotion script script_name Results: script_results
Executed remote pre-promotion script script_name Results: script_results
Executed remote post-promotion script script_name Results: script_results
Executed post-database failure script script_name Results: script_results
Executed master isolation script script_name Results: script_results
Witness agent running on node_address for cluster cluster_name
Master agent running on node_address for cluster cluster_name
Standby agent running on node_address for cluster cluster_name
Idle agent running on node node_address for cluster cluster_name
Assigning VIP VIP_address to node node_address Results: script_results
Releasing VIP VIP_address from node node_address Results: script_results
Witness agent exited on node_address for cluster cluster_name
Master agent exited on node_address for cluster cluster_name
Cluster cluster_name notified that master node has left
Standby agent exited on node_address for cluster cluster_name
Agent exited during promotion on node_address for cluster cluster_name
Agent exited on node_address for cluster cluster_name
The agent on this node will check every auto.resume.period seconds to see if it can resume monitoring the failed database. The cluster should be checked during this time and the agent stopped if the database will not be started again. See the agent log for more details.
Executed agent resumed script script_name Results: script_results
The standbys on cluster_name have left the cluster.
A standby agent on cluster_name has left the cluster, but the coordinator has detected that the standby database is still running.
Cluster cluster_name has dropped below three nodes
Subset of cluster cluster_name disconnected from master
This node is no longer connected to the majority of the cluster cluster_name. Because this node is part of a subset of the cluster, failover will not be attempted. Current nodes that are visible are: node_address
Witness running at node_address has left the cluster.
Idle agent running at node_address has left the cluster.
The standby EFM agent tried to promote itself, but detected that the master DB is still running on node_address. This usually indicates that the master EFM agent has exited. Failover has NOT occurred.
The standby EFM agent tried to promote itself, but could not because the virtual IP address (VIP_address) appears to still be assigned to another node. Promoting under these circumstances could cause data corruption. Failover has NOT occurred.
The standby EFM agent tried to promote itself, but could not because the well-known server (server_address) could not be reached. This usually indicates a network issue that has separated the standby agent from the other agents. Failover has NOT occurred.
An agent has detected that the master database is no longer available in cluster cluster_name, but there are no standby nodes available for failover.
A potential failover situation was detected for cluster cluster_name. Automatic failover has been disabled for this cluster, so manual intervention is required.
Lock file for cluster cluster_name has been removed
The lock file for cluster cluster_name has been removed from: path_name on node node_address. This lock prevents multiple agents from monitoring the same cluster on the same node. Please restore this file to prevent accidentally starting another agent for cluster.
recovery.conf file for cluster cluster_name has been found
A recovery.conf file for cluster cluster_name has been found at: path_name on master node node_address. This may be problematic should you attempt to restart the DB on this node.
The path provided for the trigger_file parameter in the recovery.conf file is not writable by the db_service_owner user. Failover Manager will not be able to promote the database if needed.
The auto.reconfigure property has been set to false for this node. The node has not been reconfigured to follow the new master node after a failover.
Could not resume replay for standby being promoted. Manual intervention may be required. Error: error_decription
This error is returned if the server encounters an error when invoking replay during the promotion of a standby.
Your remote.timeout value (value) is higher than your local.timeout value (value). If the local database takes too long to respond, the local agent could assume that the database has failed though other agents can connect. While this will not cause a failover, it could force the local agent to stop monitoring, leaving you without failover protection.
The current number of standby nodes in the cluster has dropped to the minimum number: number. There cannot be a failover unless another standby node(s) is added or made promotable.

The conditions listed in the table below will trigger a SEVERE notification:
The master agent can no longer reach the local database running at node_address. Other nodes are able to access the database remotely, so the master will not release the VIP and/or create a recovery.conf file. The master agent will become idle until the resume command is run to resume monitoring the database.
This node has connected to the cluster, but cannot resolve the IP address for one or more cluster members. Please stop the agent running on node_address and verify that all the existing cluster members' addresses are in the .nodes file.
Fencing script script_name failed to execute successfully.
Exit Value: exit_code
Results: script_results
Failover has NOT occurred.
Post-promotion script script_name failed to execute successfully.
Exit Value:
exit_code
Results: script_results
Remote-post-promotion script script_name failed to execute successfully
Exit Value: exit_code
Results: script_results
Node: node_address
Remote-pre-promotion script script_name failed to execute successfully
Exit Value: exit_code
Results: script_results
Node: node_address
Post-database failure script script_name failed to execute successfully.
Exit Value:
exit_code
Results:
script_results
Agent resumed script script_name failed to execute successfully.
Results:
script_results
Master isolation script script_name failed to execute successfully.
Exit Value:
exit_code
Results:
script_results
The trigger file file_name could not be created on node. Could not promote standby. Error details: message_details
Error creating recovery.conf file on node_address for cluster cluster_name
There was an error creating the recovery.conf file on master node node_address during promotion. Promotion has continued, but requires manual intervention to ensure that the old master node can not be restarted. Error details: message_details
The master database has been isolated from the majority of the cluster. The cluster is telling the master agent at ip_address to fence off the master database to prevent two masters when the rest of the failover manager cluster promotes a standby.
master_or_standby database failure for cluster cluster_name
is no longer available in cluster cluster_name, but there are not enough standby nodes available for failover..
The following custom monitor script has failed on a standby node.
The agent will stop monitoring the local database.
Script location: script_name
Script output: script_results
EFM will attempt to promote a standby.
Script location: script_name
Script output: script_results

7 Notifications

Table of Contents Previous Next