diff --git a/doc/appendix-faq.sgml b/doc/appendix-faq.sgml index 3c0d5329..796349ac 100644 --- a/doc/appendix-faq.sgml +++ b/doc/appendix-faq.sgml @@ -19,7 +19,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 is no longer maintained. @@ -135,7 +135,7 @@ No. - &repmgr; (together with repmgrd) assists with + &repmgr; (together with &repmgrd;) assists with managing replication. It does not actually perform replication, which is part of the core PostgreSQL functionality. @@ -152,8 +152,8 @@ Does it matter if different &repmgr; versions are present in the replication cluster? Yes. If different "major" &repmgr; versions (e.g. 3.3.x and 4.1.x) are present, - &repmgr; (in particular repmgrd) - may not run, or run properly, or in the worst case (if different repmgrd + &repmgr; (in particular &repmgrd;) + may not run, or run properly, or in the worst case (if different &repmgrd; versions are running and there are differences in the failover implementation) break your replication cluster. @@ -282,19 +282,19 @@ Do I need to include <literal>shared_preload_libraries = 'repmgr'</literal> - in <filename>postgresql.conf</filename> if I'm not using <application>repmgrd</application>? + 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>/<application>repmgrd</application> complains it can't connect to the server... Why? + but repmgr/&repmgrd; complains it can't connect to the server... Why? - repmgr and repmgrd need to be able to connect to the repmgr database + repmgr and &repmgrd; 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). @@ -349,7 +349,7 @@ - <application>repmgrd</application> + &repmgrd; @@ -365,12 +365,12 @@ - Does <application>repmgrd</application> support delayed standbys? + Does &repmgrd; 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. @@ -379,13 +379,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 primary node has been replicated. - How can I get <application>repmgrd</application> to rotate its logfile? + How can I get &repmgrd; to rotate its logfile? Configure your system's logrotate service to do this; see . @@ -393,11 +393,11 @@ - I've recloned a failed primary as a standby, but <application>repmgrd</application> refuses to start? + I've recloned a failed primary as a standby, but &repmgrd; 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. @@ -405,7 +405,7 @@ - <application>repmgrd</application> ignores pg_bindir when executing <varname>promote_command</varname> or <varname>follow_command</varname> + &repmgrd; ignores pg_bindir when executing <varname>promote_command</varname> or <varname>follow_command</varname> promote_command or follow_command can be user-defined scripts, @@ -416,13 +416,13 @@ - <application>repmgrd</application> aborts startup with the error "<literal>upstream node must be running before repmgrd can start</literal>" + &repmgrd; aborts startup with the error "<literal>upstream node must be running before repmgrd can start</literal>" - repmgrd does this to avoid starting up on a replication cluster - which is not in a healthy state. If the upstream is unavailable, repmgrd + &repmgrd; does this to avoid starting up on a replication cluster + which is not in a healthy state. If the upstream is unavailable, &repmgrd; may initiate a failover immediately after starting up, which could have unintended side-effects, - particularly if repmgrd is not running on other nodes. + particularly if &repmgrd; is not running on other nodes. In particular, it's possible that the node's local copy of the repmgr.nodes copy @@ -430,7 +430,7 @@ The onus is therefore on the adminstrator to manually set the cluster to a stable, healthy state before - starting repmgrd. + starting &repmgrd;. diff --git a/doc/appendix-packages.sgml b/doc/appendix-packages.sgml index bc358613..c49c6a36 100644 --- a/doc/appendix-packages.sgml +++ b/doc/appendix-packages.sgml @@ -310,7 +310,7 @@ See also for some specifics related - to configuring the repmgrd daemon. + to configuring the &repmgrd; daemon. @@ -552,7 +552,7 @@ repmgr96-4.1.1-0.0git320.g5113ab0.1.el7.x86_64.rpm - PID file location: the default repmgrd PID file + PID file location: the default &repmgrd; PID file location can be hard-coded by patching package_pid_file in repmgrd.c: diff --git a/doc/appendix-release-notes.sgml b/doc/appendix-release-notes.sgml index 1e39eced..aab94da2 100644 --- a/doc/appendix-release-notes.sgml +++ b/doc/appendix-release-notes.sgml @@ -105,7 +105,7 @@ documentation section Upgrading a major version release. - If repmgrd is in use, a PostgreSQL restart is required; + If &repmgrd; is in use, a PostgreSQL restart is required; in that case we suggest combining this &repmgr; upgrade with the next PostgreSQL minor release, which will require a PostgreSQL restart in any case. @@ -113,7 +113,7 @@ - On Debian-based systems, including Ubuntu, if using repmgrd + On Debian-based systems, including Ubuntu, if using &repmgrd; please ensure that in the file /etc/init.d/repmgrd, the parameter REPMGRD_OPTS contains "--daemonize=false", e.g.: @@ -156,7 +156,7 @@ REPMGRD_OPTS="--daemonize=false" New commands repmgr daemon start and repmgr daemon stop: - these provide a standardized way of starting and stopping repmgrd. + these provide a standardized way of starting and stopping &repmgrd;. GitHub #528. @@ -172,7 +172,7 @@ REPMGRD_OPTS="--daemonize=false" repmgr daemon status additionally displays the node priority and the interval (in seconds) since the - repmgrd instance last verified its upstream node was available. + &repmgrd; instance last verified its upstream node was available. @@ -240,20 +240,20 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd will no longer consider nodes where repmgrd + &repmgrd; will no longer consider nodes where &repmgrd; is not running as promotion candidates. - Previously, if repmgrd was not running on a node, but + Previously, if &repmgrd; was not running on a node, but that node qualified as the promotion candidate, it would never be promoted due to - the absence of a running repmgrd. + the absence of a running &repmgrd;. Add option to enable selection of the method - repmgrd uses to determine whether the upstream node is available. + &repmgrd; uses to determine whether the upstream node is available. Possible values are ping (default; uses PQping() to @@ -266,7 +266,7 @@ REPMGRD_OPTS="--daemonize=false" New configuration option - to allow an external mechanism to validate the failover decision made by repmgrd. + to allow an external mechanism to validate the failover decision made by &repmgrd;. @@ -279,7 +279,7 @@ REPMGRD_OPTS="--daemonize=false" - In a failover situation, repmgrd will not attempt to promote a + In a failover situation, &repmgrd; will not attempt to promote a node if another primary has already appeared (e.g. by being promoted manually). GitHub #420. @@ -364,7 +364,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: on a cascaded standby, don't fail over if + &repmgrd;: on a cascaded standby, don't fail over if failover=manual. GitHub #531. @@ -393,7 +393,7 @@ REPMGRD_OPTS="--daemonize=false" - On Debian-based systems, including Ubuntu, if using repmgrd + On Debian-based systems, including Ubuntu, if using &repmgrd; please ensure that the in the file /etc/init.d/repmgrd, the parameter REPMGRD_OPTS contains "--daemonize=false", e.g.: @@ -488,12 +488,12 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd can now be "paused", i.e. instructed + &repmgrd; can now be "paused", i.e. instructed not to take any action such as a failover, even if the prerequisites for such an action are detected. - This removes the need to stop repmgrd on all nodes when + This removes the need to stop &repmgrd; on all nodes when performing a planned operation such as a switchover. @@ -519,7 +519,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: fix parsing of option. + &repmgrd;: fix parsing of option. @@ -537,7 +537,7 @@ REPMGRD_OPTS="--daemonize=false" We recommend upgrading to this version as soon as possible. This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.1.0; - repmgrd (if running) should be restarted. + &repmgrd; (if running) should be restarted. See for more details. @@ -619,8 +619,8 @@ REPMGRD_OPTS="--daemonize=false" Check promote_command and follow_command are defined when reloading configuration. These were checked on startup but - not reload by repmgrd, which made it possible to - make repmgrd with invalid values. It's unlikely + not reload by &repmgrd;, which made it possible to + make &repmgrd; with invalid values. It's unlikely anyone would want to do this, but we should make it impossible anyway. (GitHub #486). @@ -661,7 +661,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: fix startup on witness node when local data is stale. (GitHub #488, #489). + &repmgrd;: fix startup on witness node when local data is stale. (GitHub #488, #489). @@ -687,7 +687,7 @@ REPMGRD_OPTS="--daemonize=false" Release 4.1.0 Tue July 31, 2018 - &repmgr; 4.1.0 introduces some changes to repmgrd + &repmgr; 4.1.0 introduces some changes to &repmgrd; behaviour and some additional configuration parameters. @@ -703,7 +703,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd must be restarted on all nodes where it is running. + &repmgrd; must be restarted on all nodes where it is running. @@ -825,14 +825,14 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: create a PID file by default + &repmgrd;: create a PID file by default (GitHub #457). For details, see . - repmgrd: daemonize process by default. + &repmgrd;: daemonize process by default. In case, for whatever reason, the user does not wish to daemonize the process, provide . (GitHub #458). @@ -901,7 +901,7 @@ REPMGRD_OPTS="--daemonize=false" We recommend upgrading to this version as soon as possible. This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.5; - repmgrd (if running) should be restarted. See + &repmgrd; (if running) should be restarted. See for more details. @@ -988,7 +988,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: ensure local node is counted as quorum member + &repmgrd;: ensure local node is counted as quorum member (GitHub #439) @@ -1005,7 +1005,7 @@ REPMGRD_OPTS="--daemonize=false" &repmgr; 4.0.5 contains a number of usability enhancements related to pg_rewind usage, recovery.conf - generation and (in repmgrd) handling of various + generation and (in &repmgrd;) handling of various corner-case situations, as well as a number of bug fixes. @@ -1070,7 +1070,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: set connect_timeout=2 (if not explicitly set) + &repmgrd;: set connect_timeout=2 (if not explicitly set) when pinging a server. @@ -1126,20 +1126,20 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: handle pg_ctl promote timeout (GitHub #425). + &repmgrd;: handle pg_ctl promote timeout (GitHub #425). - repmgrd: handle failover situation with only two nodes in the primary + &repmgrd;: handle failover situation with only two nodes in the primary location, and at least one node in another location (GitHub #407). - repmgrd: prevent standby connection handle from going stale. + &repmgrd;: prevent standby connection handle from going stale. @@ -1163,7 +1163,7 @@ REPMGRD_OPTS="--daemonize=false" This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.3; - repmgrd (if running) should be restarted. See + &repmgrd; (if running) should be restarted. See for more details. @@ -1242,14 +1242,14 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: improve detection of status change from primary to + &repmgrd;: improve detection of status change from primary to standby - repmgrd: improve reconnection to the local node after a + &repmgrd;: improve reconnection to the local node after a failover (previously a connection error due to the node starting up was being interpreted as the node being unavailable) @@ -1257,14 +1257,14 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd: when running on a witness server, correctly connect + &repmgrd;: when running on a witness server, correctly connect to new primary after a failover - repmgrd: add event notification + &repmgrd;: add event notification repmgrd_shutdown (GitHub #393) @@ -1433,7 +1433,7 @@ REPMGRD_OPTS="--daemonize=false" This release can be installed as a simple package upgrade from &repmgr; 4.0.1 or 4.0; - repmgrd (if running) should be restarted. + &repmgrd; (if running) should be restarted. @@ -1653,10 +1653,10 @@ REPMGRD_OPTS="--daemonize=false" improved logging output: - &repmgr; (and repmgrd) now provide more explicit + &repmgr; (and &repmgrd;) now provide more explicit logging output giving a better picture of what is going on. Where appropriate, DETAIL and HINT log lines provide additional - detail and suggestions for resolving problems. Additionally, repmgrd + detail and suggestions for resolving problems. Additionally, &repmgrd; now emits informational log lines at regular, configurable intervals to confirm that it's running correctly and which node(s) it's monitoring. @@ -1703,11 +1703,11 @@ REPMGRD_OPTS="--daemonize=false" automatic failover: improved detection of node status; promotion decision based on a consensual model, with the promoted primary explicitly informing other standbys to - follow it. The repmgrd daemon will continue + follow it. The &repmgrd; daemon will continue functioning even if the monitored PostgreSQL instance is down, and resume monitoring if it reappears. Additionally, if the instance's role has changed (typically from a primary to a standby, e.g. following reintegration of a - failed primary using ) repmgrd + failed primary using ) &repmgrd; will automatically resume monitoring it as a standby. @@ -1793,7 +1793,7 @@ REPMGRD_OPTS="--daemonize=false" - repmgrd + &repmgrd; @@ -1915,7 +1915,7 @@ REPMGRD_OPTS="--daemonize=false" new parameter log_status_interval, which causes - repmgrd to emit a status log + &repmgrd; to emit a status log line at the specified interval diff --git a/doc/appendix-support.sgml b/doc/appendix-support.sgml index 3f363c89..a4dcd3a7 100644 --- a/doc/appendix-support.sgml +++ b/doc/appendix-support.sgml @@ -80,7 +80,7 @@ the maximum level of logging output. - If issues are encountered with repmgrd, + If issues are encountered with &repmgrd;, please provide relevant extracts from the &repmgr; log files and if possible the PostgreSQL log itself. Please ensure these logs do not contain any confidential data. diff --git a/doc/configuration-file-log-settings.sgml b/doc/configuration-file-log-settings.sgml index f5bbf332..e910b114 100644 --- a/doc/configuration-file-log-settings.sgml +++ b/doc/configuration-file-log-settings.sgml @@ -10,7 +10,7 @@ Log settings - By default, &repmgr; and repmgrd write log output to + By default, &repmgr; and &repmgrd; write log output to STDERR. An alternative log destination can be specified (either a file or syslog). @@ -24,7 +24,7 @@ This behaviour can be overriden with the command line option , which will redirect all logging output to the configured log destination. This is recommended - when &repmgr; is executed by another application, particularly repmgrd, + when &repmgr; is executed by another application, particularly &repmgrd;, to enable log output generated by the &repmgr; application to be stored for later reference. @@ -93,9 +93,9 @@ - This setting causes repmgrd to emit a status log + This setting causes &repmgrd; to emit a status log line at the specified interval (in seconds, default 300) - describing repmgrd's current state, e.g.: + describing &repmgrd;'s current state, e.g.: [2018-07-12 00:47:32] [INFO] monitoring connection to upstream node "node1" (ID: 1) diff --git a/doc/configuration-file-required-settings.sgml b/doc/configuration-file-required-settings.sgml index f0cbe580..62cf51c7 100644 --- a/doc/configuration-file-required-settings.sgml +++ b/doc/configuration-file-required-settings.sgml @@ -99,7 +99,7 @@ repmgr.conf.sample. - For repmgrd-specific settings, see . + For &repmgrd;-specific settings, see . diff --git a/doc/configuration-file-service-commands.sgml b/doc/configuration-file-service-commands.sgml index 69cdfabc..105064df 100644 --- a/doc/configuration-file-service-commands.sgml +++ b/doc/configuration-file-service-commands.sgml @@ -10,7 +10,7 @@ Service command settings - In some circumstances, &repmgr; (and repmgrd) need to + In some circumstances, &repmgr; (and &repmgrd;) need to be able to stop, start or restart PostgreSQL. &repmgr; commands which need to do this include repmgr standby follow, repmgr standby switchover and @@ -68,7 +68,7 @@ Do not confuse this with promote_command, which is used - by repmgrd to execute . + by &repmgrd; to execute . diff --git a/doc/configuration-file.sgml b/doc/configuration-file.sgml index cecf1140..da104fac 100644 --- a/doc/configuration-file.sgml +++ b/doc/configuration-file.sgml @@ -11,7 +11,7 @@ Configuration file - repmgr and repmgrd + repmgr and &repmgrd; use a common configuration file, by default called repmgr.conf (although any name can be used if explicitly specified). repmgr.conf must contain a number of required parameters, including diff --git a/doc/event-notifications.sgml b/doc/event-notifications.sgml index 145b3428..b2be918e 100644 --- a/doc/event-notifications.sgml +++ b/doc/event-notifications.sgml @@ -6,7 +6,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 @@ -207,7 +207,7 @@ - Events generated by repmgrd (streaming replication mode): + Events generated by &repmgrd; (streaming replication mode): @@ -274,7 +274,7 @@ - Events generated by repmgrd (BDR mode): + Events generated by &repmgrd; (BDR mode): bdr_failover diff --git a/doc/install-requirements.sgml b/doc/install-requirements.sgml index f6984e2e..2362a20a 100644 --- a/doc/install-requirements.sgml +++ b/doc/install-requirements.sgml @@ -45,14 +45,14 @@ If different "major" &repmgr; versions (e.g. 3.3.x and 4.1.x) - are installed on different nodes, in the best case &repmgr; (in particular repmgrd) + are installed on different nodes, in the best case &repmgr; (in particular &repmgrd;) will not run. In the worst case, you will end up with a broken cluster. 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 a66a9da6..1a154151 100644 --- a/doc/overview.sgml +++ b/doc/overview.sgml @@ -58,7 +58,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. @@ -107,7 +107,7 @@ promotes a (local) standby. - A witness server only needs to be created if repmgrd + A witness server only needs to be created if &repmgrd; is in use. @@ -198,7 +198,7 @@ repmgr.monitoring_history: historical standby monitoring information - written by repmgrd + written by &repmgrd; @@ -214,7 +214,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 72a871c9..ad4f7894 100644 --- a/doc/quickstart.sgml +++ b/doc/quickstart.sgml @@ -352,7 +352,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 756ed6d3..c2b70967 100644 --- a/doc/repmgr-cluster-cleanup.sgml +++ b/doc/repmgr-cluster-cleanup.sgml @@ -38,7 +38,7 @@ Notes - 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-daemon-pause.sgml b/doc/repmgr-daemon-pause.sgml index c4bd7972..aab59d92 100644 --- a/doc/repmgr-daemon-pause.sgml +++ b/doc/repmgr-daemon-pause.sgml @@ -14,30 +14,30 @@ repmgr daemon pause - Instruct all repmgrd instances in the replication cluster to pause failover operations + Instruct all &repmgrd; instances in the replication cluster to pause failover operations Description This command can be run on any active node in the replication cluster to instruct all - running repmgrd instances to "pause" themselves, i.e. take no + running &repmgrd; instances to "pause" themselves, i.e. take no action (such as promoting themselves or following a new primary) if a failover event is detected. This functionality is useful for performing maintenance operations, such as switchovers - or upgrades, which might otherwise trigger a failover if repmgrd + or upgrades, which might otherwise trigger a failover if &repmgrd; is running normally. It's important to wait a few seconds after restarting PostgreSQL on any node before running - repmgr daemon pause, as the repmgrd instance + repmgr daemon pause, as the &repmgrd; instance on the restarted node will take a second or two before it has updated its status. - will instruct all previously paused repmgrd + will instruct all previously paused &repmgrd; instances to resume normal failover operation. @@ -69,7 +69,7 @@ NOTICE: node 3 (node3) paused - Check if nodes are reachable but don't pause repmgrd. + Check if nodes are reachable but don't pause &repmgrd;. @@ -87,7 +87,7 @@ NOTICE: node 3 (node3) paused - repmgrd could be paused on all nodes. + &repmgrd; could be paused on all nodes. @@ -96,7 +96,7 @@ NOTICE: node 3 (node3) paused - repmgrd could not be paused on one or mode nodes. + &repmgrd; could not be paused on one or mode nodes. diff --git a/doc/repmgr-daemon-start.sgml b/doc/repmgr-daemon-start.sgml index 03013818..7618ee37 100644 --- a/doc/repmgr-daemon-start.sgml +++ b/doc/repmgr-daemon-start.sgml @@ -14,17 +14,17 @@ repmgr daemon start - Start the repmgrd daemon + Start the &repmgrd; daemon Description - This command starts the repmgrd daemon on the + This command starts the &repmgrd; daemon on the local node. - By default, &repmgr; will wait for up to 15 seconds to confirm that repmgrd + By default, &repmgr; will wait for up to 15 seconds to confirm that &repmgrd; started. This behaviour can be overridden by specifying a diffent value using the option, or disabled altogether with the option. @@ -50,7 +50,7 @@ - Check prerequisites but don't actually attempt to start repmgrd. + Check prerequisites but don't actually attempt to start &repmgrd;. This action will output the command which would be executed. @@ -63,7 +63,7 @@ - Wait for the specified number of seconds to confirm that repmgrd + Wait for the specified number of seconds to confirm that &repmgrd; started successfully. @@ -77,7 +77,7 @@ - Don't wait to confirm that repmgrd + Don't wait to confirm that &repmgrd; started successfully. @@ -109,7 +109,7 @@ repmgr daemon start will execute the command defined by the repmgrd_service_start_command parameter in repmgr.conf. - This must be set to a shell command which will start repmgrd; + This must be set to a shell command which will start &repmgrd;; if &repmgr; was installed from a package, this will be the service command defined by the package. For more details see Appendix: &repmgr; package details. @@ -117,7 +117,7 @@ If &repmgr; was installed from a system package, and you do not configure repmgrd_service_start_command to an appropriate service command, this may - result in the system becoming confused about the state of the repmgrd + result in the system becoming confused about the state of the &repmgrd; service; this is particularly the case with systemd. @@ -139,12 +139,12 @@ - The repmgrd start command (defined in + The &repmgrd; start command (defined in repmgrd_service_start_command) was successfully executed. If the option was provided, &repmgr; will confirm that - repmgrd has actually started up. + &repmgrd; has actually started up. @@ -167,10 +167,10 @@ &repmgr; was unable to connect to the local PostgreSQL node. - PostgreSQL must be running before repmgrd + PostgreSQL must be running before &repmgrd; can be started. Additionally, unless the option was provided, &repmgr; needs to be able to connect to the local PostgreSQL node - to determine the state of repmgrd. + to determine the state of &repmgrd;. @@ -180,11 +180,11 @@ - The repmgrd start command (defined in + The &repmgrd; start command (defined in repmgrd_service_start_command) was not successfully executed. - This can also mean that &repmgr; was unable to confirm whether repmgrd + This can also mean that &repmgr; was unable to confirm whether &repmgrd; successfully started (unless the option was provided). diff --git a/doc/repmgr-daemon-status.sgml b/doc/repmgr-daemon-status.sgml index e1a5a61a..9e35c393 100644 --- a/doc/repmgr-daemon-status.sgml +++ b/doc/repmgr-daemon-status.sgml @@ -14,14 +14,14 @@ repmgr daemon status - display information about the status of repmgrd on each node in the cluster + display information about the status of &repmgrd; on each node in the cluster Description This command provides an overview over all active nodes in the cluster and the state - of each node's repmgrd instance. It can be used to check + of each node's &repmgrd; instance. It can be used to check the result of and operations. @@ -35,13 +35,13 @@ If PostgreSQL is not running on a node, &repmgr; will not be able to determine the - status of that node's repmgrd instance. + status of that node's &repmgrd; instance. - After restarting PostgreSQL on any node, the repmgrd instance + After restarting PostgreSQL on any node, the &repmgrd; instance will take a second or two before it is able to update its status. Until then, - repmgrd will be shown as not running. + &repmgrd; will be shown as not running. @@ -50,7 +50,7 @@ Examples - repmgrd running normally on all nodes: + &repmgrd; running normally on all nodes: $ repmgr -f /etc/repmgr.conf daemon status ID | Name | Role | Status | Upstream | repmgrd | PID | Paused? | Upstream last seen ----+-------+---------+-----------+----------+---------+-------+---------+-------------------- @@ -60,7 +60,7 @@ - repmgrd paused on all nodes (using ): + &repmgrd; paused on all nodes (using ): $ repmgr -f /etc/repmgr.conf daemon status ID | Name | Role | Status | Upstream | repmgrd | PID | Paused? | Upstream last seen ----+-------+---------+-----------+----------+---------+-------+---------+-------------------- @@ -70,7 +70,7 @@ - repmgrd not running on one node: + &repmgrd; not running on one node: $ repmgr -f /etc/repmgr.conf daemon status ID | Name | Role | Status | Upstream | repmgrd | PID | Paused? | Upstream last seen ----+-------+---------+-----------+----------+-------------+-------+---------+-------------------- @@ -127,25 +127,25 @@ - repmgrd running (1 = running, 0 = not running, -1 = unknown) + &repmgrd; running (1 = running, 0 = not running, -1 = unknown) - repmgrd PID (-1 if not running or status unknown) + &repmgrd; PID (-1 if not running or status unknown) - repmgrd paused (1 = paused, 0 = not paused, -1 = unknown) + &repmgrd; paused (1 = paused, 0 = not paused, -1 = unknown) - repmgrd node priority + &repmgrd; node priority diff --git a/doc/repmgr-daemon-stop.sgml b/doc/repmgr-daemon-stop.sgml index 12abca20..e282ef89 100644 --- a/doc/repmgr-daemon-stop.sgml +++ b/doc/repmgr-daemon-stop.sgml @@ -14,25 +14,25 @@ repmgr daemon stop - Stop the repmgrd daemon + Stop the &repmgrd; daemon Description - This command stops the repmgrd daemon on the + This command stops the &repmgrd; daemon on the local node. - By default, &repmgr; will wait for up to 15 seconds to confirm that repmgrd + By default, &repmgr; will wait for up to 15 seconds to confirm that &repmgrd; stopped. This behaviour can be overridden by specifying a diffent value using the option, or disabled altogether with the option. If PostgreSQL is not running on the local node, under some circumstances &repmgr; may not - be able to confirm if repmgrd has actually stopped. + be able to confirm if &repmgrd; has actually stopped. @@ -50,7 +50,7 @@ repmgr daemon stop will execute the command defined by the repmgrd_service_stop_command parameter in repmgr.conf. - This must be set to a shell command which will stop repmgrd; + This must be set to a shell command which will stop &repmgrd;; if &repmgr; was installed from a package, this will be the service command defined by the package. For more details see Appendix: &repmgr; package details. @@ -59,7 +59,7 @@ If &repmgr; was installed from a system package, and you do not configure repmgrd_service_stop_command to an appropriate service command, this may - result in the system becoming confused about the state of the repmgrd + result in the system becoming confused about the state of the &repmgrd; service; this is particularly the case with systemd. @@ -76,7 +76,7 @@ - Check prerequisites but don't actually attempt to stop repmgrd. + Check prerequisites but don't actually attempt to stop &repmgrd;. This action will output the command which would be executed. @@ -89,7 +89,7 @@ - Wait for the specified number of seconds to confirm that repmgrd + Wait for the specified number of seconds to confirm that &repmgrd; stopped successfully. @@ -103,7 +103,7 @@ - Don't wait to confirm that repmgrd + Don't wait to confirm that &repmgrd; stopped successfully. @@ -134,7 +134,7 @@ repmgr daemon stop will execute the command defined by the repmgrd_service_stop_command parameter in repmgr.conf. - This must be set to a shell command which will stop repmgrd; + This must be set to a shell command which will stop &repmgrd;; if &repmgr; was installed from a package, this will be the service command defined by the package. For more details see Appendix: &repmgr; package details. @@ -142,7 +142,7 @@ If &repmgr; was installed from a system package, and you do not configure repmgrd_service_stop_command to an appropriate service command, this may - result in the system becoming confused about the state of the repmgrd + result in the system becoming confused about the state of the &repmgrd; service; this is particularly the case with systemd. @@ -163,7 +163,7 @@ - repmgrd could be stopped. + &repmgrd; could be stopped. @@ -182,7 +182,7 @@ - repmgrd could not be stopped. + &repmgrd; could not be stopped. diff --git a/doc/repmgr-daemon-unpause.sgml b/doc/repmgr-daemon-unpause.sgml index 88e8b133..cd507303 100644 --- a/doc/repmgr-daemon-unpause.sgml +++ b/doc/repmgr-daemon-unpause.sgml @@ -15,14 +15,14 @@ repmgr daemon unpause - Instruct all repmgrd instances in the replication cluster to resume failover operations + Instruct all &repmgrd; instances in the replication cluster to resume failover operations Description This command can be run on any active node in the replication cluster to instruct all - running repmgrd instances to "unpause" + running &repmgrd; instances to "unpause" (following a previous execution of ) and resume normal failover/monitoring operation. @@ -30,7 +30,7 @@ It's important to wait a few seconds after restarting PostgreSQL on any node before running - repmgr daemon pause, as the repmgrd instance + repmgr daemon pause, as the &repmgrd; instance on the restarted node will take a second or two before it has updated its status. @@ -64,7 +64,7 @@ NOTICE: node 3 (node3) unpaused - Check if nodes are reachable but don't unpause repmgrd. + Check if nodes are reachable but don't unpause &repmgrd;. @@ -82,7 +82,7 @@ NOTICE: node 3 (node3) unpaused - repmgrd could be unpaused on all nodes. + &repmgrd; could be unpaused on all nodes. @@ -91,7 +91,7 @@ NOTICE: node 3 (node3) unpaused - repmgrd could not be unpaused on one or mode nodes. + &repmgrd; could not be unpaused on one or mode nodes. diff --git a/doc/repmgr-standby-follow.sgml b/doc/repmgr-standby-follow.sgml index 431b6735..9f3815dd 100644 --- a/doc/repmgr-standby-follow.sgml +++ b/doc/repmgr-standby-follow.sgml @@ -122,7 +122,7 @@ If not provided, &repmgr; will attempt to follow the current primary node. - Note that when using repmgrd, + Note that when using &repmgrd;, should always be configured; see Automatic failover configuration for details. diff --git a/doc/repmgr-standby-promote.sgml b/doc/repmgr-standby-promote.sgml index 72be9f48..4b31cc39 100644 --- a/doc/repmgr-standby-promote.sgml +++ b/doc/repmgr-standby-promote.sgml @@ -23,7 +23,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 41963eac..42b647c7 100644 --- a/doc/repmgr-standby-register.sgml +++ b/doc/repmgr-standby-register.sgml @@ -17,7 +17,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. @@ -59,7 +59,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 + &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 93b2c834..1e98913d 100644 --- a/doc/repmgr-standby-switchover.sgml +++ b/doc/repmgr-standby-switchover.sgml @@ -48,12 +48,12 @@ From repmgr 4.2, &repmgr; will instruct any running - repmgrd instances to pause operations while the switchover - is being carried out, to prevent repmgrd from + &repmgrd; instances to pause operations while the switchover + is being carried out, to prevent &repmgrd; from unintentionally promoting a node. For more details, see . - Users of &repmgr; versions prior to 4.2 should ensure that repmgrd + Users of &repmgr; versions prior to 4.2 should ensure that &repmgrd; is not running on any nodes while a switchover is being executed. @@ -134,11 +134,11 @@ - Don't pause repmgrd while executing a switchover. + Don't pause &repmgrd; while executing a switchover. This option should not be used unless you take steps by other means - to ensure repmgrd is paused or not + to ensure &repmgrd; is paused or not running on all nodes. diff --git a/doc/repmgr-witness-register.sgml b/doc/repmgr-witness-register.sgml index de6d1853..3244adf5 100644 --- a/doc/repmgr-witness-register.sgml +++ b/doc/repmgr-witness-register.sgml @@ -20,7 +20,7 @@ record to the &repmgr; metadata, and if necessary initialises the witness node by installing the &repmgr; extension and copying the &repmgr; metadata to the witness server. This command needs to be executed to enable - use of the witness server with repmgrd. + use of the witness server with &repmgrd;. When executing repmgr witness register, database connection diff --git a/doc/repmgr.sgml b/doc/repmgr.sgml index 301bc924..7238c574 100644 --- a/doc/repmgr.sgml +++ b/doc/repmgr.sgml @@ -1,4 +1,4 @@ - + repmgr"> + repmgrd"> PostgreSQL"> ]> diff --git a/doc/repmgrd-automatic-failover.sgml b/doc/repmgrd-automatic-failover.sgml index b576de8e..f79389eb 100644 --- a/doc/repmgrd-automatic-failover.sgml +++ b/doc/repmgrd-automatic-failover.sgml @@ -7,7 +7,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. @@ -60,7 +60,7 @@ - A witness server will only be useful if repmgrd + A witness server will only be useful if &repmgrd; is in use. @@ -96,11 +96,11 @@ As the witness server is not part of the replication cluster, further changes to the &repmgr; metadata will be synchronised by - repmgrd. + &repmgrd;. - Once the witness server has been configured, repmgrd + Once the witness server has been configured, &repmgrd; should be started. @@ -156,8 +156,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 degraded monitoring mode until a primary becomes visible). @@ -184,7 +184,7 @@ - When running on the primary node, repmgrd can + When running on the primary node, &repmgrd; can monitor connections and in particular disconnections by its attached child nodes (standbys), and optionally execute a custom command if certain criteria are met (such as the number of attached nodes falling to @@ -195,7 +195,7 @@ - Currently repmgrd can only detect disconnections + Currently &repmgrd; can only detect disconnections of streaming replication standbys and cannot determine whether a standby has disconnected and fallen back to archive recovery. @@ -207,7 +207,7 @@ Standby disconnections monitoring process and criteria - repmgrd monitors attach child nodes and decides + &repmgrd; monitors attach child nodes and decides whether to invoke the user-defined command based on the following process and criteria: @@ -215,7 +215,7 @@ Every few seconds (defined by the configuration parameter child_nodes_check_interval; - default: 5 seconds, a value of 0 disables this altogether), repmgrd queries + default: 5 seconds, a value of 0 disables this altogether), &repmgrd; queries the pg_stat_replication system view and compares the nodes present there against the list of nodes registered with &repmgr; which should be attached to the primary. @@ -225,7 +225,7 @@ If a child node (standby) is no longer present in pg_stat_replication, - repmgrd notes the time it detected the node's absence, and additionally generates a + &repmgrd; notes the time it detected the node's absence, and additionally generates a child_node_disconnect event. @@ -233,14 +233,14 @@ If a chile node (standby) which was absent from pg_stat_replication reappears, - repmgrd clears the time it detected the node's absence, and additionally generates a + &repmgrd; clears the time it detected the node's absence, and additionally generates a child_node_reconnect event. - If an entirely new child node (standby) is detected, repmgrd adds it to its internal list + If an entirely new child node (standby) is detected, &repmgrd; adds it to its internal list and additionally generates a child_node_new_connect event. @@ -248,10 +248,10 @@ If the child_nodes_disconnect_command parameter is set in - repmgr.conf, repmgrd will then loop through all child nodes. + repmgr.conf, &repmgrd; will then loop through all child nodes. If it determines that insufficient child nodes are connected, and a minimum of child_nodes_disconnect_timeout seconds (default: 30) - has elapsed since the last node became disconnected, repmgrd will then execute the + has elapsed since the last node became disconnected, &repmgrd; will then execute the child_nodes_disconnect_command script. @@ -267,8 +267,8 @@ - Note that child nodes which are not attached when repmgrd - starts will not be considered as missing, as repmgrd + Note that child nodes which are not attached when &repmgrd; + starts will not be considered as missing, as &repmgrd; cannot know why they are not attached. @@ -280,12 +280,12 @@ Standby disconnections monitoring process example - This example shows typical repmgrd log output from a three-node cluster + This example shows typical &repmgrd; log output from a three-node cluster (primary and two child nodes), with child_nodes_connected_min_count set to 2. - repmgrd on the primary has started up, while two child + &repmgrd; on the primary has started up, while two child nodes are being provisioned: [2019-04-24 15:25:33] [INFO] monitoring primary node "node1" (ID: 1) in normal state @@ -298,7 +298,7 @@ (...) - One of the child nodes has disconnected; repmgrd + One of the child nodes has disconnected; &repmgrd; is now waiting child_nodes_disconnect_timeout seconds before executing child_nodes_disconnect_command: @@ -333,7 +333,7 @@ If a child node is configured to use archive recovery, it's possible that the child node will disconnect from the primary node and fall back to - archive recovery. In this case repmgrd + archive recovery. In this case &repmgrd; will nevertheless register a node disconnection. @@ -374,7 +374,7 @@ child_nodes_check_interval - Interval (in seconds) after which repmgrd queries the + Interval (in seconds) after which &repmgrd; queries the pg_stat_replication system view and compares the nodes present there against the list of nodes registered with repmgr which should be attached to the primary. @@ -393,7 +393,7 @@ child_nodes_disconnect_command - User-definable script to be executed when repmgrd + User-definable script to be executed when &repmgrd; determines that an insufficient number of child nodes are connected. By default the script is executed when no child nodes are executed, but the execution threshold can be modified by setting one of child_nodes_connected_min_count @@ -435,7 +435,7 @@ The child_nodes_disconnect_command script will not be executed if - repmgrd is paused. + &repmgrd; is paused. @@ -449,7 +449,7 @@ child_nodes_disconnect_timeout - If repmgrd determines that an insufficient number of + If &repmgrd; determines that an insufficient number of child nodes are connected, it will wait for the specified number of seconds to execute the child_nodes_disconnect_command. @@ -543,7 +543,7 @@ child_node_disconnect - This event is generated after repmgrd + This event is generated after &repmgrd; detects that a child node is no longer streaming from the primary node. @@ -565,7 +565,7 @@ $ repmgr cluster event --event=child_node_disconnect child_node_reconnect - This event is generated after repmgrd + This event is generated after &repmgrd; detects that a child node has resumed streaming from the primary node. @@ -587,7 +587,7 @@ $ repmgr cluster event --event=child_node_reconnect child_node_new_connect - This event is generated after repmgrd + This event is generated after &repmgrd; detects that a new child node has been registered with &repmgr; and has connected to the primary. @@ -610,7 +610,7 @@ $ repmgr cluster event --event=child_node_new_connect child_nodes_disconnect_command - This event is generated after repmgrd detects + This event is generated after &repmgrd; detects that sufficient child nodes have been disconnected for a sufficient amount of time to trigger execution of the child_nodes_disconnect_command. @@ -645,7 +645,7 @@ $ repmgr cluster event --event=child_nodes_disconnect_command Standby disconnection on failover If is set to true in - repmgr.conf, in a failover situation repmgrd will forcibly disconnect + repmgr.conf, in a failover situation &repmgrd; will forcibly disconnect the local node's WAL receiver before making a failover decision. @@ -667,7 +667,7 @@ $ repmgr cluster event --event=child_nodes_disconnect_command Note that when using there will be a delay of 5 seconds plus however many seconds it takes to confirm the WAL receiver is disconnected before - repmgrd proceeds with the failover decision. + &repmgrd; proceeds with the failover decision. Following the failover operation, no matter what the outcome, each node will reconnect its WAL receiver. @@ -692,7 +692,7 @@ $ repmgr cluster event --event=child_nodes_disconnect_command Failover validation From repmgr 4.3, &repmgr; makes it possible to provide a script - to repmgrd which, in a failover situation, + to &repmgrd; which, in a failover situation, will be executed by the promotion candidate (the node which has been selected to be the new primary) to confirm whether the node should actually be promoted. @@ -712,7 +712,7 @@ $ repmgr cluster event --event=child_nodes_disconnect_command There is a pause of seconds before the election is rerun. - Sample repmgrd log file output during which the failover validation + Sample &repmgrd; log file output during which the failover validation script rejects the proposed promotion candidate: [2019-03-13 21:01:30] [INFO] visible nodes: 2; total nodes: 2; no nodes have seen the primary within the last 4 seconds @@ -748,7 +748,7 @@ INFO: node 3 received notification to rerun promotion candidate election 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-bdr.sgml b/doc/repmgrd-bdr.sgml index 71375cd0..a3bff566 100644 --- a/doc/repmgrd-bdr.sgml +++ b/doc/repmgrd-bdr.sgml @@ -24,10 +24,10 @@ In contrast to streaming replication, there's no concept of "promoting" a new primary node with BDR. Instead, "failover" involves monitoring both nodes - with repmgrd and redirecting queries from the failed node to the remaining + with &repmgrd; and redirecting queries from the failed node to the remaining active node. This can be done by using an event notification script - which is called by repmgrd to dynamically + which is called by &repmgrd; to dynamically reconfigure a proxy server/connection pooler such as PgBouncer. @@ -60,7 +60,7 @@ Application database connections *must* be passed through a proxy server/ connection pooler such as PgBouncer, and it must be possible to dynamically - reconfigure that from repmgrd. The example demonstrated in this document + reconfigure that from &repmgrd;. The example demonstrated in this document will use PgBouncer @@ -296,7 +296,7 @@ recreates the PgBouncer configuration file on each - node using the information provided by repmgrd + node using the information provided by &repmgrd; (primarily the conninfo string) to configure PgBouncer @@ -318,21 +318,21 @@ Node monitoring and failover At the intervals specified by monitor_interval_secs - in repmgr.conf, repmgrd + in repmgr.conf, &repmgrd; will ping each node to check if it's available. If a node isn't available, - repmgrd will enter failover mode and check reconnect_attempts + &repmgrd; will enter failover mode and check reconnect_attempts times at intervals of reconnect_interval to confirm the node is definitely unreachable. This buffer period is necessary to avoid false positives caused by transient network outages. - If the node is still unavailable, repmgrd will enter failover mode and execute + If the node is still unavailable, &repmgrd; will enter failover mode and execute the script defined in event_notification_command; an entry will be logged - in the repmgr.events table and repmgrd will + in the repmgr.events table and &repmgrd; will (unless otherwise configured) resume monitoring of the node in "degraded" mode until it reappears. - repmgrd logfile output during a failover event will look something like this + &repmgrd; logfile output during a failover event will look something like this on one node (usually the node which has failed, here node2): ... @@ -388,8 +388,8 @@ This assumes only the PostgreSQL instance on node2 has failed. In this case the - repmgrd instance running on node2 has performed the failover. However if - the entire server becomes unavailable, repmgrd on node1 will perform + &repmgrd; instance running on node2 has performed the failover. However if + the entire server becomes unavailable, &repmgrd; on node1 will perform the failover. @@ -404,7 +404,7 @@ If the failed node comes back up and connects correctly, output similar to this - will be visible in the repmgrd log: + will be visible in the &repmgrd; log: [2017-07-27 21:25:30] [DETAIL] monitoring node "node2" (ID: 2) in degraded mode [2017-07-27 21:25:46] [INFO] monitoring BDR replication status on node "node2" (ID: 2) @@ -417,10 +417,10 @@ Shutdown of both nodes - If both PostgreSQL instances are shut down, repmgrd will try and handle the + If both PostgreSQL instances are shut down, &repmgrd; will try and handle the situation as gracefully as possible, though with no failover candidates available there's not much it can do. Should this case ever occur, we recommend shutting - down repmgrd on both nodes and restarting it once the PostgreSQL instances + down &repmgrd; on both nodes and restarting it once the PostgreSQL instances are running properly. diff --git a/doc/repmgrd-configuration.sgml b/doc/repmgrd-configuration.sgml index 1afba33a..8d8fe64c 100644 --- a/doc/repmgrd-configuration.sgml +++ b/doc/repmgrd-configuration.sgml @@ -8,13 +8,13 @@ repmgrd setup and configuration - repmgrd is a daemon which runs on each PostgreSQL node, + &repmgrd; is a daemon which runs on each PostgreSQL node, monitoring the local node, and (unless it's the primary node) the upstream server (the primary server or with cascading replication, another standby) which it's connected to. - repmgrd can be configured to provide failover + &repmgrd; can be configured to provide failover capability in case the primary upstream node becomes unreachable, and/or provide monitoring data to the &repmgr; metadatabase. @@ -23,7 +23,7 @@ repmgrd configuration - To use repmgrd, its associated function library must be + To use &repmgrd;, its associated function library must be included via postgresql.conf with: @@ -35,7 +35,7 @@ - The following configuraton options apply to repmgrd in all circumstances: + The following configuraton options apply to &repmgrd; in all circumstances: @@ -62,7 +62,7 @@ The option is used to select the method - repmgrd uses to determine whether the upstream node is available. + &repmgrd; uses to determine whether the upstream node is available. Possible values are: @@ -132,7 +132,7 @@ - Interval (in seconds) after which repmgrd will terminate if + Interval (in seconds) after which &repmgrd; will terminate if either of the servers (local node and or upstream node) being monitored is no longer available (degraded monitoring mode). @@ -152,7 +152,7 @@ Required configuration for automatic failover - The following repmgrd options must be set in + The following &repmgrd; options must be set in repmgr.conf: @@ -192,7 +192,7 @@ - If is set to manual, repmgrd + If is set to manual, &repmgrd; will not take any action if a failover situation is detected, and the node may need to be modified manually (e.g. by executing repmgr standby follow). @@ -209,7 +209,7 @@ The program or script defined in will be executed - in a failover situation when repmgrd determines that + in a failover situation when &repmgrd; determines that the current node is to become the new primary node. @@ -231,8 +231,8 @@ 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. + output generated by the &repmgr; command, when executed by &repmgrd;, + to be logged to the same destination configured to receive log output for &repmgrd;. @@ -252,7 +252,7 @@ The program or script defined in will be executed - in a failover situation when repmgrd determines that + in a failover situation when &repmgrd; determines that the current node is to follow the new primary node. @@ -263,7 +263,7 @@ The parameter 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, + &repmgrd; with the ID of the new primary node. If this is not provided, repmgr standby follow 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 @@ -284,8 +284,8 @@ 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. + output generated by the &repmgr; command, when executed by &repmgrd;, + to be logged to the same destination configured to receive log output for &repmgrd;. @@ -337,7 +337,7 @@ User-defined script to execute for an external mechanism to validate the failover - decision made by repmgrd. + decision made by &repmgrd;. @@ -408,7 +408,7 @@ for this option. - repmgrd will refuse to start if this option is set + &repmgrd; will refuse to start if this option is set but either of these prerequisites is not met. @@ -469,14 +469,14 @@ PostgreSQL service configuration - If using automatic failover, currently repmgrd will need to execute + If using automatic failover, currently &repmgrd; will need to execute repmgr standby follow to restart PostgreSQL on standbys to have them follow a new primary. To ensure this happens smoothly, it's essential to provide the appropriate system/service restart command appropriate to your operating system via service_restart_command - in repmgr.conf. If you don't do this, repmgrd + in repmgr.conf. If you don't do this, &repmgrd; will default to using pg_ctl, which can result in unexpected problems, particularly on systemd-based systems. @@ -549,21 +549,21 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' Applying configuration changes to repmgrd - To apply configuration file changes to a running repmgrd - daemon, execute the operating system's repmgrd service reload command + To apply configuration file changes to a running &repmgrd; + daemon, execute the operating system's &repmgrd; service reload command (see for examples), or for instances which were manually started, execute kill -HUP, e.g. kill -HUP `cat /tmp/repmgrd.pid`. - Check the repmgrd log to see what changes were + Check the &repmgrd; log to see what changes were applied, or if any issues were encountered when reloading the configuration. Note that only the following subset of configuration file parameters can be changed on a - running repmgrd daemon: + running &repmgrd; daemon: @@ -770,7 +770,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' After executing repmgr standby register --force, - repmgrd must be restarted for the changes to take effect. + &repmgrd; must be restarted for the changes to take effect. @@ -785,7 +785,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' repmgrd daemon - If installed from a package, the repmgrd can be started + If installed from a package, the &repmgrd; can be started via the operating system's service command, e.g. in systemd using systemctl. @@ -796,7 +796,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' The commands repmgr daemon start and repmgr daemon stop can be used - as convenience wrappers to start and stop repmgrd. + as convenience wrappers to start and stop &repmgrd;. @@ -808,7 +808,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' - repmgrd can be started manually like this: + &repmgrd; can be started manually like this: repmgrd -f /etc/repmgr.conf --pid-file /tmp/repmgrd.pid and stopped with kill `cat /tmp/repmgrd.pid`. Adjust paths as appropriate. @@ -825,7 +825,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' repmgrd's PID file - repmgrd will generate a PID file by default. + &repmgrd; will generate a PID file by default. @@ -845,12 +845,12 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' may be deprecated in future releases. - If a PID file location was specified by the package maintainer, repmgrd + If a PID file location was specified by the package maintainer, &repmgrd; will use that. This only applies if &repmgr; was installed from a package and the package maintainer has specified the PID file location. - If none of the above apply, repmgrd will create a PID file + If none of the above apply, &repmgrd; will create a PID file in the operating system's temporary directory (as setermined by the environment variable TMPDIR, or if that is not set, will use /tmp). @@ -859,10 +859,10 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' . - To see which PID file repmgrd would use, execute repmgrd - with the option . repmgrd + To see which PID file &repmgrd; would use, execute &repmgrd; + with the option . &repmgrd; will not start if this option is provided. Note that the value shown is the - file repmgrd would use next time it starts, and is + file &repmgrd; would use next time it starts, and is not necessarily the PID file currently in use. @@ -881,7 +881,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr11 stop' If &repmgr; was installed from Debian/Ubuntu packages, additional configuration - is required before repmgrd is started as a daemon. + is required before &repmgrd; is started as a daemon. This is done via the file /etc/default/repmgrd, which by default @@ -920,12 +920,12 @@ REPMGRD_OPTS="--daemonize=false" - From repmgrd 4.1, ensure REPMGRD_OPTS includes + From &repmgrd; 4.1, ensure REPMGRD_OPTS includes , as daemonization is handled by the service command. If using systemd, you may need to execute systemctl daemon-reload. - Also, if you attempted to start repmgrd using systemctl start repmgrd, + Also, if you attempted to start &repmgrd; using systemctl start repmgrd, you'll need to execute systemctl stop repmgrd. Because that's how systemd rolls. @@ -972,7 +972,7 @@ REPMGRD_OPTS="--daemonize=false" repmgrd log rotation - To ensure the current repmgrd logfile + To ensure the current &repmgrd; logfile (specified in repmgr.conf with the parameter ) does not grow indefinitely, configure your system's logrotate to regularly rotate it. diff --git a/doc/repmgrd-operation.sgml b/doc/repmgrd-operation.sgml index e5c5fed9..37e331b7 100644 --- a/doc/repmgrd-operation.sgml +++ b/doc/repmgrd-operation.sgml @@ -21,42 +21,42 @@ Pausing repmgrd - In normal operation, repmgrd monitors the state of the + In normal operation, &repmgrd; monitors the state of the PostgreSQL node it is running on, and will take appropriate action if problems are detected, e.g. (if so configured) promote the node to primary, if the existing primary has been determined as failed. - However, repmgrd is unable to distinguish between + However, &repmgrd; is unable to distinguish between planned outages (such as performing a switchover or installing PostgreSQL maintenance released), and an actual server outage. In versions prior to - &repmgr; 4.2 it was necessary to stop repmgrd on all nodes (or at least - on all nodes where repmgrd is + &repmgr; 4.2 it was necessary to stop &repmgrd; on all nodes (or at least + on all nodes where &repmgrd; is configured for automatic failover) - to prevent repmgrd from making unintentional changes to the + to prevent &repmgrd; from making unintentional changes to the replication cluster. - From &repmgr; 4.2, repmgrd + From &repmgr; 4.2, &repmgrd; can now be "paused", i.e. instructed not to take any action such as performing a failover. This can be done from any node in the cluster, removing the need to stop/restart - each repmgrd individually. + each &repmgrd; individually. For major PostgreSQL upgrades, e.g. from PostgreSQL 10 to PostgreSQL 11, - repmgrd should be shut down completely and only started up + &repmgrd; should be shut down completely and only started up once the &repmgr; packages for the new PostgreSQL major version have been installed. - Prerequisites for pausing <application>repmgrd</application> + Prerequisites for pausing &repmgrd; - In order to be able to pause/unpause repmgrd, following + In order to be able to pause/unpause &repmgrd;, following prerequisites must be met: @@ -86,9 +86,9 @@ - Pausing/unpausing <application>repmgrd</application> + Pausing/unpausing &repmgrd; - To pause repmgrd, execute repmgr daemon pause, e.g.: + To pause &repmgrd;, execute repmgr daemon pause, e.g.: $ repmgr -f /etc/repmgr.conf daemon pause NOTICE: node 1 (node1) paused @@ -96,7 +96,7 @@ NOTICE: node 2 (node2) paused NOTICE: node 3 (node3) paused - The state of repmgrd on each node can be checked with + The state of &repmgrd; on each node can be checked with repmgr daemon status, e.g.: $ repmgr -f /etc/repmgr.conf daemon status ID | Name | Role | Status | repmgrd | PID | Paused? @@ -109,12 +109,12 @@ NOTICE: node 3 (node3) paused If executing a switchover with repmgr standby switchover, - &repmgr; will automatically pause/unpause repmgrd as part of the switchover process. + &repmgr; will automatically pause/unpause &repmgrd; as part of the switchover process. - If the primary (in this example, node1) is stopped, repmgrd + If the primary (in this example, node1) is stopped, &repmgrd; running on one of the standbys (here: node2) will react like this: [2018-09-20 12:22:21] [WARNING] unable to connect to upstream node "node1" (ID: 1) @@ -130,14 +130,14 @@ NOTICE: node 3 (node3) paused [2018-09-20 12:22:33] [HINT] execute "repmgr daemon unpause" to resume normal failover mode - If the primary becomes available again (e.g. following a software upgrade), repmgrd + If the primary becomes available again (e.g. following a software upgrade), &repmgrd; will automatically reconnect, e.g.: [2018-09-20 13:12:41] [NOTICE] reconnected to upstream node 1 after 8 seconds, resuming monitoring - To unpause repmgrd, execute repmgr daemon unpause, e.g.: + To unpause &repmgrd;, execute repmgr daemon unpause, e.g.: $ repmgr -f /etc/repmgr.conf daemon unpause NOTICE: node 1 (node1) unpaused @@ -147,7 +147,7 @@ NOTICE: node 3 (node3) unpaused - If the previous primary is no longer accessible when repmgrd + If the previous primary is no longer accessible when &repmgrd; is unpaused, no failover action will be taken. Instead, a new primary must be manually promoted using repmgr standby promote, and any standbys attached to the new primary with @@ -156,13 +156,13 @@ NOTICE: node 3 (node3) unpaused This is to prevent repmgr daemon unpause resulting in the automatic promotion of a new primary, which may be a problem particularly - in larger clusters, where repmgrd could select a different promotion + in larger clusters, where &repmgrd; could select a different promotion candidate to the one intended by the administrator. - Details on the <application>repmgrd</application> pausing mechanism + Details on the &repmgrd; pausing mechanism The pause state of each node will be stored over a PostgreSQL restart. @@ -171,14 +171,14 @@ NOTICE: node 3 (node3) unpaused repmgr daemon pause and repmgr daemon unpause can be - executed even if repmgrd is not running; in this case, - repmgrd will start up in whichever pause state has been set. + executed even if &repmgrd; is not running; in this case, + &repmgrd; will start up in whichever pause state has been set. repmgr daemon pause and repmgr daemon unpause - do not stop/start repmgrd. + do not stop/start &repmgrd;. @@ -194,7 +194,7 @@ NOTICE: node 3 (node3) unpaused If WAL replay has been paused (using pg_wal_replay_pause(), on PostgreSQL 9.6 and earlier pg_xlog_replay_pause()), - in a failover situation repmgrd will + in a failover situation &repmgrd; will automatically resume WAL replay. @@ -225,9 +225,9 @@ NOTICE: node 3 (node3) unpaused "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 node's upstream server. In these cases it enters "degraded monitoring" - mode, where repmgrd remains active but is waiting for the situation + mode, where &repmgrd; remains active but is waiting for the situation to be resolved. @@ -287,12 +287,12 @@ NOTICE: node 3 (node3) unpaused 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. - If repmgrd is monitoring a primary mode which has been stopped + If &repmgrd; is monitoring a primary mode which has been stopped and manually restarted as a standby attached to a new primary, it will automatically detect the status change and update the node record to reflect the node's new status as an active standby. It will then resume monitoring the node as a standby. @@ -313,7 +313,7 @@ NOTICE: node 3 (node3) unpaused Storing monitoring data - When repmgrd is running with the option monitoring_history=true, + When &repmgrd; is running with the option monitoring_history=true, it will constantly write standby node status information to the monitoring_history table, providing a near-real time overview of replication status on all nodes @@ -351,7 +351,7 @@ NOTICE: node 3 (node3) unpaused 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-overview.sgml b/doc/repmgrd-overview.sgml index 889b51ef..edc139af 100644 --- a/doc/repmgrd-overview.sgml +++ b/doc/repmgrd-overview.sgml @@ -7,18 +7,18 @@ repmgrd overview - repmgrd ("replication manager daemon") + &repmgrd; ("replication manager daemon") 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. - repmgrd is designed to be straightforward to set up + &repmgrd; is designed to be straightforward to set up and does not require additional external infrastructure. - Functionality provided by repmgrd includes: + Functionality provided by &repmgrd; includes: @@ -93,11 +93,11 @@ See section Required configuration for automatic failover - for an example of minimal repmgr.conf file settings suitable for use with repmgrd. + for an example of minimal repmgr.conf file settings suitable for use with &repmgrd;. - 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: [2019-03-15 06:32:05] [NOTICE] repmgrd (repmgrd 4.3) starting up @@ -107,7 +107,7 @@ [2019-03-15 06:32:05] [INFO] monitoring connection to upstream node "node1" (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 @@ -123,8 +123,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/switchover.sgml b/doc/switchover.sgml index 4c0e71cb..235c746b 100644 --- a/doc/switchover.sgml +++ b/doc/switchover.sgml @@ -159,12 +159,12 @@ From repmgr 4.2, &repmgr; will instruct any running - repmgrd instances to pause operations while the switchover - is being carried out, to prevent repmgrd from + &repmgrd; instances to pause operations while the switchover + is being carried out, to prevent &repmgrd; from unintentionally promoting a node. For more details, see . - Users of &repmgr; versions prior to 4.2 should ensure that repmgrd + Users of &repmgr; versions prior to 4.2 should ensure that &repmgrd; is not running on any nodes while a switchover is being executed. @@ -313,13 +313,13 @@ - If repmgrd is in use, it's worth double-checking that + If &repmgrd; is in use, it's worth double-checking that all nodes are unpaused by executing repmgr-daemon-status. - Users of &repmgr; versions prior to 4.2 will need to manually restart repmgrd + Users of &repmgr; versions prior to 4.2 will need to manually restart &repmgrd; on all nodes after the switchover is completed. diff --git a/doc/upgrading-repmgr.sgml b/doc/upgrading-repmgr.sgml index d9086e77..8a738369 100644 --- a/doc/upgrading-repmgr.sgml +++ b/doc/upgrading-repmgr.sgml @@ -24,7 +24,7 @@ - the repmgr and repmgrd executables + the repmgr and &repmgrd; executables @@ -37,7 +37,7 @@ - the shared library module used by repmgrd which + the shared library module used by &repmgrd; which is resident in the PostgreSQL backend @@ -45,8 +45,8 @@ With minor releases, usually changes are only made to the repmgr - and repmgrd executables. In this case, the upgrade is quite straightforward, - and is simply a case of installing the new version, and restarting repmgrd + and &repmgrd; executables. In this case, the upgrade is quite straightforward, + and is simply a case of installing the new version, and restarting &repmgrd; (if running). @@ -82,7 +82,7 @@ - restart repmgrd on all nodes where it is running + restart &repmgrd; on all nodes where it is running @@ -93,7 +93,7 @@ Some packaging systems (e.g. Debian/Ubuntu - may restart repmgrd as part of the package upgrade process. + may restart &repmgrd; as part of the package upgrade process. @@ -126,7 +126,7 @@ "major version" upgrades need to be planned more carefully, as they may include changes to the &repmgr; metadata (which need to be propagated from the primary to all - standbys) and/or changes to the shared object file used by repmgrd + standbys) and/or changes to the shared object file used by &repmgrd; (which require a PostgreSQL restart). @@ -138,14 +138,14 @@ - Stop repmgrd (if in use) on all nodes where it is running. + Stop &repmgrd; (if in use) on all nodes where it is running. - Disable the repmgrd service on all nodes where it is in use; - this is to prevent packages from prematurely restarting repmgrd. + Disable the &repmgrd; service on all nodes where it is in use; + this is to prevent packages from prematurely restarting &repmgrd;. @@ -167,12 +167,12 @@ systemctl daemon-reload If the &repmgr; shared library module has been updated (check the release notes!), - restart PostgreSQL, then repmgrd (if in use) on each node, + restart PostgreSQL, then &repmgrd; (if in use) on each node, The order in which this is applied to individual nodes is not critical, - and it's also fine to restart PostgreSQL on all nodes first before starting repmgrd. + and it's also fine to restart PostgreSQL on all nodes first before starting &repmgrd;. - Note that if the upgrade requires a PostgreSQL restart, repmgrd + Note that if the upgrade requires a PostgreSQL restart, &repmgrd; will only function correctly once all nodes have been restarted. @@ -188,7 +188,7 @@ ALTER EXTENSION repmgr UPDATE - Reenable the repmgrd service on all nodes where it is in use, and + Reenable the &repmgrd; service on all nodes where it is in use, and ensure it is running. @@ -212,7 +212,7 @@ ALTER EXTENSION repmgr UPDATE Checking repmgrd status after an upgrade From repmgr 4.2, once the upgrade is complete, execute the repmgr daemon status - command (on any node) to show an overview of the status of repmgrd on all nodes. + command (on any node) to show an overview of the status of &repmgrd; on all nodes. @@ -332,7 +332,7 @@ ALTER EXTENSION repmgr UPDATE monitoring_history: this replaces the - repmgrd command line option + &repmgrd; command line option --monitoring-history @@ -433,7 +433,7 @@ ALTER EXTENSION repmgr UPDATE 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. @@ -499,7 +499,7 @@ ALTER EXTENSION repmgr UPDATE 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.