event notifications Each time &repmgr; or repmgrd perform a significant event, a record of that event is written into the repmgr.events table together with a timestamp, an indication of failure or success, and further details if appropriate. This is useful for gaining an overview of events affecting the replication cluster. However note that this table has advisory character and should be used in combination with the &repmgr; and PostgreSQL logs to obtain details of any events. Example output after a primary was registered and a standby cloned and registered: repmgr=# SELECT * from repmgr.events ; node_id | event | successful | event_timestamp | details ---------+------------------+------------+-------------------------------+------------------------------------------------------------------------------------- 1 | primary_register | t | 2016-01-08 15:04:39.781733+09 | 2 | standby_clone | t | 2016-01-08 15:04:49.530001+09 | Cloned from host 'repmgr_node1', port 5432; backup method: pg_basebackup; --force: N 2 | standby_register | t | 2016-01-08 15:04:50.621292+09 | (3 rows) Alternatively, use to output a formatted list of events. Additionally, event notifications can be passed to a user-defined program or script which can take further action, e.g. send email notifications. This is done by setting the event_notification_command parameter in repmgr.conf. The following format placeholders are provided for all event notifications: %n node ID %e event type %s success (1) or failure (0) %t timestamp %d details The values provided for %t and %d will probably contain spaces, so should be quoted in the provided command configuration, e.g.: event_notification_command='/path/to/some/script %n %e %s "%t" "%d"' The following parameters are provided for a subset of event notifications: %p node ID of the current primary ( and ) node ID of the demoted primary ( only) %c conninfo string of the primary node ( and ) conninfo string of the next available node (bdr_failover and bdr_recovery) %a name of the current primary node ( and ) name of the next available node (bdr_failover and bdr_recovery) The values provided for %c and %a will probably contain spaces, so should always be quoted. By default, all notification types will be passed to the designated script; the notification types can be filtered to explicitly named ones using the event_notifications parameter. Events generated by the &repmgr; command: cluster_created primary_register primary_unregister standby_clone standby_register standby_register_sync standby_unregister standby_promote standby_follow standby_switchover witness_register witness_unregister node_rejoin cluster_cleanup Events generated by repmgrd (streaming replication mode): repmgrd_start repmgrd_shutdown repmgrd_reload repmgrd_failover_promote repmgrd_failover_follow repmgrd_failover_aborted repmgrd_standby_reconnect repmgrd_promote_error repmgrd_local_disconnect repmgrd_local_reconnect repmgrd_upstream_disconnect repmgrd_upstream_reconnect standby_disconnect_manual standby_failure standby_recovery Events generated by repmgrd (BDR mode): bdr_failover bdr_reconnect bdr_recovery bdr_register bdr_unregister Note that under some circumstances (e.g. when no replication cluster primary could be located), it will not be possible to write an entry into the repmgr.events table, in which case executing a script via event_notification_command can serve as a fallback by generating some form of notification.