diff --git a/doc/appendix-faq.sgml b/doc/appendix-faq.sgml index d2c3b2d5..d9c04827 100644 --- a/doc/appendix-faq.sgml +++ b/doc/appendix-faq.sgml @@ -15,7 +15,7 @@ &repmgr; 3.x builds on the improved replication facilities added in PostgreSQL 9.3, as well as improved automated failover support - via repmgrd, and is not compatible with PostgreSQL 9.2 + via repmgrd, and is not compatible with PostgreSQL 9.2 and earlier. We recommend upgrading to &repmgr; 4, as the &repmgr; 3.x series will no longer be actively maintained. @@ -126,19 +126,19 @@ Do I need to include <literal>shared_preload_libraries = 'repmgr'</literal> - in <filename>postgresql.conf</filename> if I'm not using <command>repmgrd</command>? + in postgresql.conf if I'm not using repmgrd? - No, the repmgr shared library is only needed when running repmgrd. - If you later decide to run repmgrd, you just need to add + No, the repmgr shared library is only needed when running repmgrd. + If you later decide to run repmgrd, you just need to add shared_preload_libraries = 'repmgr' and restart PostgreSQL. I've provided replication permission for the <literal>repmgr</literal> user in <filename>pg_hba.conf</filename> - but <command>repmgr</command>/<command>repmgrd</command> complains it can't connect to the server... Why? + but repmgr/repmgrd complains it can't connect to the server... Why? - repmgr andrepmgrd need to be able to connect to the repmgr database + repmgr andrepmgrd need to be able to connect to the repmgr database with a normal connection to query metadata. The replication connection permission is for PostgreSQL's streaming replication (and doesn't necessarily need to be the repmgr user). @@ -170,7 +170,7 @@ - <command>repmgrd</command> + <application>repmgrd</application> @@ -186,12 +186,12 @@ - Does <command>repmgrd</command> support delayed standbys? + Does <application>repmgrd</application> support delayed standbys? - repmgrd can monitor delayed standbys - those set up with + repmgrd can monitor delayed standbys - those set up with recovery_min_apply_delay set to a non-zero value in recovery.conf - but as it's not currently possible - to directly examine the value applied to the standby, repmgrd + to directly examine the value applied to the standby, repmgrd may not be able to properly evaluate the node as a promotion candidate. @@ -200,13 +200,13 @@ repmgr.conf. - Note that after registering a delayed standby, repmgrd will only start + Note that after registering a delayed standby, repmgrd will only start once the metadata added in the master node has been replicated. - How can I get <command>repmgrd</command> to rotate its logfile? + How can I get <application>repmgrd</application> to rotate its logfile? Configure your system's logrotate service to do this; see . @@ -214,11 +214,11 @@ - I've recloned a failed master as a standby, but <command>repmgrd</command> refuses to start? + I've recloned a failed master as a standby, but <application>repmgrd</application> refuses to start? Check you registered the standby after recloning. If unregistered, the standby cannot be considered as a promotion candidate even if failover is set to - automatic, which is probably not what you want. repmgrd will start if + automatic, which is probably not what you want. repmgrd will start if failover is set to manual so the node's replication status can still be monitored, if desired. diff --git a/doc/event-notifications.sgml b/doc/event-notifications.sgml index 3ab5cadd..c95c6fe0 100644 --- a/doc/event-notifications.sgml +++ b/doc/event-notifications.sgml @@ -1,7 +1,7 @@ Event Notifications - Each time &repmgr; or repmgrd perform a significant event, a record + 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 diff --git a/doc/install-requirements.sgml b/doc/install-requirements.sgml index 00d02a66..b36942ab 100644 --- a/doc/install-requirements.sgml +++ b/doc/install-requirements.sgml @@ -31,7 +31,7 @@ A dedicated system user for &repmgr; is *not* required; as many &repmgr; and - repmgrd actions require direct access to the PostgreSQL data directory, + repmgrd actions require direct access to the PostgreSQL data directory, these commands should be executed by the postgres user. diff --git a/doc/overview.sgml b/doc/overview.sgml index 47e057e0..a216501b 100644 --- a/doc/overview.sgml +++ b/doc/overview.sgml @@ -57,7 +57,7 @@ This is the action which occurs if a primary server fails and a suitable standby - is promoted as the new primary. The repmgrd daemon supports automatic failover + is promoted as the new primary. The repmgrd daemon supports automatic failover to minimise downtime. @@ -173,7 +173,7 @@ repmgr.monitoring_history: historical standby monitoring information - written by repmgrd + written by repmgrd @@ -189,7 +189,7 @@ name of the server's upstream node - repmgr.replication_status: when repmgrd's monitoring is enabled, shows + repmgr.replication_status: when repmgrd's monitoring is enabled, shows current monitoring status for each standby. diff --git a/doc/quickstart.sgml b/doc/quickstart.sgml index 98df606b..2c7e748d 100644 --- a/doc/quickstart.sgml +++ b/doc/quickstart.sgml @@ -286,7 +286,7 @@ slot_name | config_file | /etc/repmgr.conf - Each server in the replication cluster will have its own record. If repmgrd + Each server in the replication cluster will have its own record. If repmgrd is in use, the fields upstream_node_id, active and type will be updated when the node's status or role changes. diff --git a/doc/repmgr-cluster-cleanup.sgml b/doc/repmgr-cluster-cleanup.sgml index df207d0c..e945ef06 100644 --- a/doc/repmgr-cluster-cleanup.sgml +++ b/doc/repmgr-cluster-cleanup.sgml @@ -15,7 +15,7 @@ - Monitoring history will only be written if repmgrd is active, and + Monitoring history will only be written if repmgrd is active, and monitoring_history is set to true in repmgr.conf. diff --git a/doc/repmgr-standby-promote.sgml b/doc/repmgr-standby-promote.sgml index 1c95d763..f4384e48 100644 --- a/doc/repmgr-standby-promote.sgml +++ b/doc/repmgr-standby-promote.sgml @@ -12,7 +12,7 @@ If the standby promotion succeeds, the server will not need to be restarted. However any other standbys will need to follow the new server, - by using ; if repmgrd + by using ; if repmgrd is active, it will handle this automatically. diff --git a/doc/repmgr-standby-register.sgml b/doc/repmgr-standby-register.sgml index b4c77ce5..6f553bf6 100644 --- a/doc/repmgr-standby-register.sgml +++ b/doc/repmgr-standby-register.sgml @@ -4,7 +4,7 @@ repmgr standby register adds a standby's information to the &repmgr; metadata. This command needs to be executed to enable - promote/follow operations and to allow repmgrd to work with the node. + promote/follow operations and to allow repmgrd to work with the node. An existing standby can be registered using this command. Execute with the --dry-run option to check what would happen without actually registering the standby. @@ -15,7 +15,7 @@ Depending on your environment and workload, it may take some time for the standby's node record to propagate from the primary to the standby. Some - actions (such as starting repmgrd) require that the standby's node record + actions (such as starting repmgrd) require that the standby's node record is present and up-to-date to function correctly. diff --git a/doc/repmgr-standby-switchover.sgml b/doc/repmgr-standby-switchover.sgml index 102d6311..af84a1d5 100644 --- a/doc/repmgr-standby-switchover.sgml +++ b/doc/repmgr-standby-switchover.sgml @@ -18,7 +18,7 @@ possible without actually changing the status of either node. - repmgrd should not be active on any nodes while a switchover is being + repmgrd should not be active on any nodes while a switchover is being executed. This restriction may be lifted in a later version. diff --git a/doc/repmgrd-automatic-failover.sgml b/doc/repmgrd-automatic-failover.sgml index 8c28deca..e3ccfdc2 100644 --- a/doc/repmgrd-automatic-failover.sgml +++ b/doc/repmgrd-automatic-failover.sgml @@ -2,7 +2,7 @@ Automatic failover with repmgrd - repmgrd is a management and monitoring daemon which runs + repmgrd is a management and monitoring daemon which runs on each node in a replication cluster. It can automate actions such as failover and updating standbys to follow the new primary, as well as providing monitoring information about the state of each standby. diff --git a/doc/repmgrd-cascading-replication.sgml b/doc/repmgrd-cascading-replication.sgml index b8e00514..b2c0cdf2 100644 --- a/doc/repmgrd-cascading-replication.sgml +++ b/doc/repmgrd-cascading-replication.sgml @@ -3,7 +3,7 @@ Cascading replication - where a standby can connect to an upstream node and not the primary server itself - was introduced in PostgreSQL 9.2. &repmgr; and - repmgrd support cascading replication by keeping track of the relationship + repmgrd support cascading replication by keeping track of the relationship between standby servers - each node record is stored with the node id of its upstream ("parent") server (except of course the primary server). diff --git a/doc/repmgrd-configuration.sgml b/doc/repmgrd-configuration.sgml index 6ae80a94..b520a3d8 100644 --- a/doc/repmgrd-configuration.sgml +++ b/doc/repmgrd-configuration.sgml @@ -1,7 +1,7 @@ repmgrd configuration - To use repmgrd, its associated function library must be + To use repmgrd, its associated function library must be included in postgresql.conf with: @@ -12,7 +12,7 @@ the PostgreSQL documentation. - Additionally the following repmgrd options *must* be set in + Additionally the following repmgrd options *must* be set in repmgr.conf (adjust configuration file locations as appropriate): failover=automatic @@ -21,13 +21,13 @@ Note that the --log-to-file option will cause - output generated by the &repmgr; command, when executed by repmgrd, - to be logged to the same destination configured to receive log output for repmgrd. - See repmgr.conf.sample for further repmgrd-specific settings. + output generated by the &repmgr; command, when executed by repmgrd, + to be logged to the same destination configured to receive log output for repmgrd. + See repmgr.conf.sample for further repmgrd-specific settings. When failover is set to automatic, upon detecting failure - of the current primary, repmgrd will execute one of + of the current primary, repmgrd will execute one of promote_command or follow_command, depending on whether the current server is to become the new primary, or needs to follow another server which has become the new primary. Note that @@ -41,7 +41,7 @@ The follow_command should provide the --upstream-node-id=%n option to repmgr standby follow; the %n will be replaced by - repmgrd with the ID of the new primary node. If this is not provided, &repmgr; + repmgrd with the ID of the new primary node. If this is not provided, &repmgr; will attempt to determine the new primary by itself, but if the original primary comes back online after the new primary is promoted, there is a risk that repmgr standby follow will result in the node continuing to follow @@ -73,7 +73,7 @@ repmgrd log rotation - To ensure the current repmgrd logfile does not grow + To ensure the current repmgrd logfile does not grow indefinitely, configure your system's logrotate to regularly rotate it. diff --git a/doc/repmgrd-degraded-monitoring.sgml b/doc/repmgrd-degraded-monitoring.sgml index 5a4f5c16..3b9f784f 100644 --- a/doc/repmgrd-degraded-monitoring.sgml +++ b/doc/repmgrd-degraded-monitoring.sgml @@ -1,9 +1,9 @@ "degraded monitoring" mode - In certain circumstances, repmgrd is not able to fulfill its primary mission + In certain circumstances, repmgrd is not able to fulfill its primary mission of monitoring the nodes' upstream server. In these cases it enters "degraded - monitoring" mode, where repmgrd remains active but is waiting for the situation + monitoring" mode, where repmgrd remains active but is waiting for the situation to be resolved. @@ -63,7 +63,7 @@ By default, repmgrd will continue in degraded monitoring mode indefinitely. However a timeout (in seconds) can be set with degraded_monitoring_timeout, - after which repmgrd will terminate. + after which repmgrd will terminate. diff --git a/doc/repmgrd-demonstration.sgml b/doc/repmgrd-demonstration.sgml index 401c2db5..1b1a0606 100644 --- a/doc/repmgrd-demonstration.sgml +++ b/doc/repmgrd-demonstration.sgml @@ -10,19 +10,19 @@ ----+-------+---------+-----------+----------+----------+-------------------------------------- 1 | node1 | primary | * running | | default | host=node1 dbname=repmgr user=repmgr 2 | node2 | standby | running | node1 | default | host=node2 dbname=repmgr user=repmgr - 3 | node3 | standby | running | node1 | default | host=node3 dbname=repmgr user=repmgr + 3 | node3 | standby | running | node1 | default | host=node3 dbname=repmgr user=repmgr - Start repmgrd on each standby and verify that it's running by examining the + Start repmgrd on each standby and verify that it's running by examining the log output, which at log level INFO will look like this: [2017-08-24 17:31:00] [NOTICE] using configuration file "/etc/repmgr.conf" [2017-08-24 17:31:00] [INFO] connecting to database "host=node2 dbname=repmgr user=repmgr" [2017-08-24 17:31:00] [NOTICE] starting monitoring of node node2 (ID: 2) - [2017-08-24 17:31:00] [INFO] monitoring connection to upstream node "node1" (node ID: 1) + [2017-08-24 17:31:00] [INFO] monitoring connection to upstream node "node1" (node ID: 1) - Each repmgrd should also have recorded its successful startup as an event: + Each repmgrd should also have recorded its successful startup as an event: $ repmgr -f /etc/repmgr.conf cluster event --event=repmgrd_start Node ID | Name | Event | OK | Timestamp | Details @@ -38,8 +38,8 @@ This will force the primary to shut down straight away, aborting all processes - and transactions. This will cause a flurry of activity in the repmgrd log - files as each repmgrd detects the failure of the primary and a failover + and transactions. This will cause a flurry of activity in the repmgrd log + files as each repmgrd detects the failure of the primary and a failover decision is made. This is an extract from the log of a standby server (node2) which has promoted to new primary after failure of the original primary (node1). diff --git a/doc/repmgrd-monitoring.sgml b/doc/repmgrd-monitoring.sgml index 7daaac0a..7b3ff6ce 100644 --- a/doc/repmgrd-monitoring.sgml +++ b/doc/repmgrd-monitoring.sgml @@ -39,7 +39,7 @@ specify how many day's worth of data should be retained. - It's possible to use repmgrd to run in monitoring + It's possible to use repmgrd to run in monitoring mode only (without automatic failover capability) for some or all nodes by setting failover=manual in the node's repmgr.conf file. In the event of the node's upstream failing, diff --git a/doc/repmgrd-network-split.sgml b/doc/repmgrd-network-split.sgml index 934bf0b8..923ec598 100644 --- a/doc/repmgrd-network-split.sgml +++ b/doc/repmgrd-network-split.sgml @@ -32,8 +32,8 @@ location='dc1' - In a failover situation, repmgrd will check if any servers in the - same location as the current primary node are visible. If not, repmgrd + In a failover situation, repmgrd will check if any servers in the + same location as the current primary node are visible. If not, repmgrd will assume a network interruption and not promote any node in any other location (it will however enter mode until a primary becomes visible). diff --git a/doc/switchover.sgml b/doc/switchover.sgml index 2239572c..6e0ea959 100644 --- a/doc/switchover.sgml +++ b/doc/switchover.sgml @@ -90,7 +90,7 @@ manually with repmgr node check --archive-ready. - Ensure that repmgrd is *not* running anywhere to prevent it unintentionally + Ensure that repmgrd is *not* running anywhere to prevent it unintentionally promoting a node. @@ -195,9 +195,9 @@ - repmgrd should not be running with setting failover=automatic + repmgrd should not be running with setting failover=automatic in repmgr.conf when a switchover is carried out, otherwise the - repmgrd daemon may try and promote a standby by itself. + repmgrd daemon may try and promote a standby by itself. diff --git a/doc/upgrading-repmgr.sgml b/doc/upgrading-repmgr.sgml index cc3d0500..2cc72e23 100644 --- a/doc/upgrading-repmgr.sgml +++ b/doc/upgrading-repmgr.sgml @@ -18,9 +18,9 @@ ALTER EXTENSION repmgr UPDATE. - If repmgrd is running, it may be necessary to restart + If repmgrd is running, it may be necessary to restart the PostgreSQL server if the upgrade contains changes to the shared object - file used by repmgrd; check the release notes for details. + file used by repmgrd; check the release notes for details. @@ -83,7 +83,7 @@ monitoring_history: this replaces the - repmgrd command line option + repmgrd command line option --monitoring-history @@ -169,7 +169,7 @@ Upgrading the repmgr schema - Ensure repmgrd is not running, or any cron jobs which execute the + Ensure repmgrd is not running, or any cron jobs which execute the repmgr binary. @@ -235,7 +235,7 @@ Check the data is updated as expected by examining the repmgr.nodes - table; restart repmgrd if required. + table; restart repmgrd if required. The original repmgr_$cluster schema can be dropped at any time.