github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-22 22:56:29 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Documentation: update markup

Browse Source
This commit is contained in:
Ian Barwick
2017-10-18 11:12:20 +09:00
parent c9fbb7febf
commit 946683182c
18 changed files with 55 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
doc/appendix-faq.sgml
View File

@@ -15,7 +15,7 @@
<para>
&repmgr; 3.x builds on the improved replication facilities added
in PostgreSQL 9.3, as well as improved automated failover support
via <command>repmgrd</command>, and is not compatible with PostgreSQL 9.2
via <application>repmgrd</application>, 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.
</para>
@@ -126,19 +126,19 @@
<sect2 id="faq-repmgr-shared-preload-libaries-no-repmgrd" xreflabel="shared_preload_libraries without repmgrd">
<title>Do I need to include <literal>shared_preload_libraries = 'repmgr'</literal>
in <filename>postgresql.conf</filename> if I'm not using <command>repmgrd</command>?</title>
in <filename>postgresql.conf</filename> if I'm not using <application>repmgrd</application>?</title>
<para>
No, the <literal>repmgr</literal> shared library is only needed when running <command>repmgrd</command>.
If you later decide to run <command>repmgrd</command>, you just need to add
No, the <literal>repmgr</literal> shared library is only needed when running <application>repmgrd</application>.
If you later decide to run <application>repmgrd</application>, you just need to add
<literal>shared_preload_libraries = 'repmgr'</literal> and restart PostgreSQL.
</para>
</sect2>
<sect2 id="faq-repmgr-permissions" xreflabel="Replication permission problems">
<title>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?</title>
but <command>repmgr</command>/<application>repmgrd</application> complains it can't connect to the server... Why?</title>
<para>
<command>repmgr</command> and<command>repmgrd</command> need to be able to connect to the repmgr database
<command>repmgr</command> and<application>repmgrd</application> need to be able to connect to the repmgr database
with a normal connection to query metadata. The <literal>replication</literal> connection
permission is for PostgreSQL's streaming replication (and doesn't necessarily need to be the <literal>repmgr</literal> user).
</para>
@@ -170,7 +170,7 @@
</sect1>
<sect1 id="faq-repmgrd" xreflabel="repmgrd">
<title><command>repmgrd</command></title>
<title><application>repmgrd</application></title>
<sect2 id="faq-repmgrd-prevent-promotion" xreflabel="Prevent standby from being promoted to primary">
@@ -186,12 +186,12 @@
</sect2>
<sect2 id="faq-repmgrd-delayed-standby" xreflabel="Delayed standby support">
<title>Does <command>repmgrd</command> support delayed standbys?</title>
<title>Does <application>repmgrd</application> support delayed standbys?</title>
<para>
<command>repmgrd</command> can monitor delayed standbys - those set up with
<application>repmgrd</application> can monitor delayed standbys - those set up with
<varname>recovery_min_apply_delay</varname> set to a non-zero value
in <filename>recovery.conf</filename> - but as it's not currently possible
to directly examine the value applied to the standby, <command>repmgrd</command>
to directly examine the value applied to the standby, <application>repmgrd</application>
may not be able to properly evaluate the node as a promotion candidate.
</para>
<para>
@@ -200,13 +200,13 @@
<filename>repmgr.conf</filename>.
</para>
<para>
Note that after registering a delayed standby, <command>repmgrd</command> will only start
Note that after registering a delayed standby, <application>repmgrd</application> will only start
once the metadata added in the master node has been replicated.
</para>
</sect2>
<sect2 id="faq-repmgrd-logfile-rotate" xreflabel="repmgrd logfile rotation">
<title>How can I get <command>repmgrd</command> to rotate its logfile?</title>
<title>How can I get <application>repmgrd</application> to rotate its logfile?</title>
<para>
Configure your system's <literal>logrotate</literal> service to do this; see <xref linkend="repmgrd-log-rotation">.
</para>
@@ -214,11 +214,11 @@
</sect2>
<sect2 id="faq-repmgrd-recloned-no-start" xreflabel="repmgrd not restarting after node cloned">
<title>I've recloned a failed master as a standby, but <command>repmgrd</command> refuses to start?</title>
<title>I've recloned a failed master as a standby, but <application>repmgrd</application> refuses to start?</title>
<para>
Check you registered the standby after recloning. If unregistered, the standby
cannot be considered as a promotion candidate even if <varname>failover</varname> is set to
<literal>automatic</literal>, which is probably not what you want. <command>repmgrd</command> will start if
<literal>automatic</literal>, which is probably not what you want. <application>repmgrd</application> will start if
<varname>failover</varname> is set to <literal>manual</literal> so the node's replication status can still
be monitored, if desired.
</para>

2
doc/event-notifications.sgml
View File

@@ -1,7 +1,7 @@
<chapter id="event-notifications" xreflabel="event notifications">
<title>Event Notifications</title>
<para>
Each time &repmgr; or <command>repmgrd</command> perform a significant event, a record
Each time &repmgr; or <application>repmgrd</application> perform a significant event, a record
of that event is written into the <literal>repmgr.events</literal> 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

2
doc/install-requirements.sgml
View File

@@ -31,7 +31,7 @@
<para>
A dedicated system user for &repmgr; is *not* required; as many &repmgr; and
<command>repmgrd</command> actions require direct access to the PostgreSQL data directory,
<application>repmgrd</application> actions require direct access to the PostgreSQL data directory,
these commands should be executed by the <literal>postgres</literal> user.
</para>

6
doc/overview.sgml
View File

@@ -57,7 +57,7 @@
<listitem>
<simpara>
This is the action which occurs if a primary server fails and a suitable standby
is promoted as the new primary. The <command>repmgrd</command> daemon supports automatic failover
is promoted as the new primary. The <application>repmgrd</application> daemon supports automatic failover
to minimise downtime.
</simpara>
</listitem>
@@ -173,7 +173,7 @@
</listitem>
<listitem>
<simpara><literal>repmgr.monitoring_history</literal>: historical standby monitoring information
written by <command>repmgrd</command></simpara>
written by <application>repmgrd</application></simpara>
</listitem>
</itemizedlist>
</para>
@@ -189,7 +189,7 @@
name of the server's upstream node</simpara>
</listitem>
<listitem>
<simpara>repmgr.replication_status: when <command>repmgrd</command>'s monitoring is enabled, shows
<simpara>repmgr.replication_status: when <application>repmgrd</application>'s monitoring is enabled, shows
current monitoring status for each standby.</simpara>
</listitem>
</itemizedlist>

2
doc/quickstart.sgml
View File

@@ -286,7 +286,7 @@
slot_name |
config_file | /etc/repmgr.conf</programlisting>
<para>
Each server in the replication cluster will have its own record. If <command>repmgrd</command>
Each server in the replication cluster will have its own record. If <application>repmgrd</application>
is in use, the fields <literal>upstream_node_id</literal>, <literal>active</literal> and
<literal>type</literal> will be updated when the node's status or role changes.
</para>

2
doc/repmgr-cluster-cleanup.sgml
View File

@@ -15,7 +15,7 @@
</para>
<note>
<simpara>
Monitoring history will only be written if <command>repmgrd</command> is active, and
Monitoring history will only be written if <application>repmgrd</application> is active, and
<varname>monitoring_history</varname> is set to <literal>true</literal> in
<filename>repmgr.conf</filename>.
</simpara>

2
doc/repmgr-standby-promote.sgml
View File

@@ -12,7 +12,7 @@
<para>
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 <xref linkend="repmgr-standby-follow">; if <command>repmgrd</command>
by using <xref linkend="repmgr-standby-follow">; if <application>repmgrd</application>
is active, it will handle this automatically.
</para>
</chapter>

4
doc/repmgr-standby-register.sgml
View File

@@ -4,7 +4,7 @@
<para>
<command>repmgr standby register</command> adds a standby's information to
the &repmgr; metadata. This command needs to be executed to enable
promote/follow operations and to allow <command>repmgrd</command> to work with the node.
promote/follow operations and to allow <application>repmgrd</application> to work with the node.
An existing standby can be registered using this command. Execute with the
<literal>--dry-run</literal> option to check what would happen without actually registering the
standby.
@@ -15,7 +15,7 @@
<para>
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 <command>repmgrd</command>) require that the standby's node record
actions (such as starting <application>repmgrd</application>) require that the standby's node record
is present and up-to-date to function correctly.
</para>
<para>

2
doc/repmgr-standby-switchover.sgml
View File

@@ -18,7 +18,7 @@
possible without actually changing the status of either node.
</para>
<para>
<command>repmgrd</command> should not be active on any nodes while a switchover is being
<application>repmgrd</application> should not be active on any nodes while a switchover is being
executed. This restriction may be lifted in a later version.
</para>
<para>

2
doc/repmgrd-automatic-failover.sgml
View File

@@ -2,7 +2,7 @@
<title>Automatic failover with repmgrd</title>
<para>
<command>repmgrd</command> is a management and monitoring daemon which runs
<application>repmgrd</application> 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.

2
doc/repmgrd-cascading-replication.sgml
View File

@@ -3,7 +3,7 @@
<para>
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
<command>repmgrd</command> support cascading replication by keeping track of the relationship
<application>repmgrd</application> 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).
</para>

16
doc/repmgrd-configuration.sgml
View File

@@ -1,7 +1,7 @@
<chapter id="repmgrd-configuration">
<title>repmgrd configuration</title>
<para>
To use <command>repmgrd</command>, its associated function library must be
To use <application>repmgrd</application>, its associated function library must be
included in <filename>postgresql.conf</filename> with:
<programlisting>
@@ -12,7 +12,7 @@
the <ulink url="https://www.postgresql.org/docs/current/static/runtime-config-client.html#GUC-SHARED-PRELOAD-LIBRARIES">PostgreSQL documentation</ulink>.
</para>
<para>
Additionally the following <command>repmgrd</command> options *must* be set in
Additionally the following <application>repmgrd</application> options *must* be set in
<filename>repmgr.conf</filename> (adjust configuration file locations as appropriate):
<programlisting>
failover=automatic
@@ -21,13 +21,13 @@
</para>
<para>
Note that the <literal>--log-to-file</literal> option will cause
output generated by the &repmgr; command, when executed by <command>repmgrd</command>,
to be logged to the same destination configured to receive log output for <command>repmgrd</command>.
See <filename>repmgr.conf.sample</filename> for further <command>repmgrd</command>-specific settings.
output generated by the &repmgr; command, when executed by <application>repmgrd</application>,
to be logged to the same destination configured to receive log output for <application>repmgrd</application>.
See <filename>repmgr.conf.sample</filename> for further <application>repmgrd</application>-specific settings.
</para>
<para>
When <varname>failover</varname> is set to <literal>automatic</literal>, upon detecting failure
of the current primary, <command>repmgrd</command> will execute one of
of the current primary, <application>repmgrd</application> will execute one of
<varname>promote_command</varname> or <varname>follow_command</varname>,
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 @@
<para>
The <varname>follow_command</varname> should provide the <literal>--upstream-node-id=%n</literal>
option to <command>repmgr standby follow</command>; the <literal>%n</literal> will be replaced by
<command>repmgrd</command> with the ID of the new primary node. If this is not provided, &repmgr;
<application>repmgrd</application> 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
<command>repmgr standby follow</command> will result in the node continuing to follow
@@ -73,7 +73,7 @@
<sect1 id="repmgrd-log-rotation">
<title>repmgrd log rotation</title>
<para>
To ensure the current <command>repmgrd</command> logfile does not grow
To ensure the current <application>repmgrd</application> logfile does not grow
indefinitely, configure your system's <command>logrotate</command> to
regularly rotate it.
</para>

6
doc/repmgrd-degraded-monitoring.sgml
View File

@@ -1,9 +1,9 @@
<chapter id="repmgrd-degraded-monitoring">
<title>"degraded monitoring" mode</title>
<para>
In certain circumstances, <command>repmgrd</command> is not able to fulfill its primary mission
In certain circumstances, <application>repmgrd</application> is not able to fulfill its primary mission
of monitoring the nodes' upstream server. In these cases it enters "degraded
monitoring" mode, where <command>repmgrd</command> remains active but is waiting for the situation
monitoring" mode, where <application>repmgrd</application> remains active but is waiting for the situation
to be resolved.
</para>
<para>
@@ -63,7 +63,7 @@
<para>
By default, <literal>repmgrd</literal> will continue in degraded monitoring mode indefinitely.
However a timeout (in seconds) can be set with <varname>degraded_monitoring_timeout</varname>,
after which <command>repmgrd</command> will terminate.
after which <application>repmgrd</application> will terminate.
</para>

12
doc/repmgrd-demonstration.sgml
View File

@@ -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 </programlisting>
3 | node3 | standby | running | node1 | default | host=node3 dbname=repmgr user=repmgr</programlisting>
</para>
<para>
Start <command>repmgrd</command> on each standby and verify that it's running by examining the
Start <application>repmgrd</application> on each standby and verify that it's running by examining the
log output, which at log level <literal>INFO</literal> will look like this:
<programlisting>
[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 <literal>node2</literal> (ID: 2)
[2017-08-24 17:31:00] [INFO] monitoring connection to upstream node "node1" (node ID: 1) </programlisting>
[2017-08-24 17:31:00] [INFO] monitoring connection to upstream node "node1" (node ID: 1)</programlisting>
</para>
<para>
Each <command>repmgrd</command> should also have recorded its successful startup as an event:
Each <application>repmgrd</application> should also have recorded its successful startup as an event:
<programlisting>
$ repmgr -f /etc/repmgr.conf cluster event --event=repmgrd_start
Node ID | Name | Event | OK | Timestamp | Details
@@ -38,8 +38,8 @@
</para>
<para>
This will force the primary to shut down straight away, aborting all processes
and transactions. This will cause a flurry of activity in the <command>repmgrd</command> log
files as each <command>repmgrd</command> detects the failure of the primary and a failover
and transactions. This will cause a flurry of activity in the <application>repmgrd</application> log
files as each <application>repmgrd</application> detects the failure of the primary and a failover
decision is made. This is an extract from the log of a standby server (<literal>node2</literal>)
which has promoted to new primary after failure of the original primary (<literal>node1</literal>).
<programlisting>

2
doc/repmgrd-monitoring.sgml
View File

@@ -39,7 +39,7 @@
specify how many day's worth of data should be retained.
</para>
<para>
It's possible to use <command>repmgrd</command> to run in monitoring
It's possible to use <application>repmgrd</application> to run in monitoring
mode only (without automatic failover capability) for some or all
nodes by setting <literal>failover=manual</literal> in the node's
<filename>repmgr.conf</filename> file. In the event of the node's upstream failing,

4
doc/repmgrd-network-split.sgml
View File

@@ -32,8 +32,8 @@
location='dc1'</programlisting>
</para>
<para>
In a failover situation, <command>repmgrd</command> will check if any servers in the
same location as the current primary node are visible. If not, <command>repmgrd</command>
In a failover situation, <application>repmgrd</application> will check if any servers in the
same location as the current primary node are visible. If not, <application>repmgrd</application>
will assume a network interruption and not promote any node in any
other location (it will however enter <xref linkend="repmgrd-degraded-monitoring"> mode until
a primary becomes visible).

6
doc/switchover.sgml
View File

@@ -90,7 +90,7 @@
manually with <command>repmgr node check --archive-ready</command>.
</para>
<para>
Ensure that <command>repmgrd</command> is *not* running anywhere to prevent it unintentionally
Ensure that <application>repmgrd</application> is *not* running anywhere to prevent it unintentionally
promoting a node.
</para>
<para>
@@ -195,9 +195,9 @@
</listitem>
<listitem>
<simpara>
<command>repmgrd</command> should not be running with setting <varname>failover=automatic</varname>
<application>repmgrd</application> should not be running with setting <varname>failover=automatic</varname>
in <filename>repmgr.conf</filename> when a switchover is carried out, otherwise the
<command>repmgrd</command> daemon may try and promote a standby by itself.
<application>repmgrd</application> daemon may try and promote a standby by itself.
</simpara>
</listitem>
</itemizedlist>

10
doc/upgrading-repmgr.sgml
View File

@@ -18,9 +18,9 @@
<command>ALTER EXTENSION repmgr UPDATE</command>.
</para>
<para>
If <command>repmgrd</command> is running, it may be necessary to restart
If <application>repmgrd</application> is running, it may be necessary to restart
the PostgreSQL server if the upgrade contains changes to the shared object
file used by <command>repmgrd</command>; check the release notes for details.
file used by <application>repmgrd</application>; check the release notes for details.
</para>
<sect1 id="upgrading-from-repmgr-3" xreflabel="Upgrading from repmgr 3.x">
@@ -83,7 +83,7 @@
</listitem>
<listitem>
<simpara><varname>monitoring_history</varname>: this replaces the
<command>repmgrd</command> command line option
<application>repmgrd</application> command line option
<literal>--monitoring-history</literal></simpara>
</listitem>
</itemizedlist>
@@ -169,7 +169,7 @@
<sect2>
<title>Upgrading the repmgr schema</title>
<para>
Ensure <command>repmgrd</command> is not running, or any cron jobs which execute the
Ensure <application>repmgrd</application> is not running, or any cron jobs which execute the
<command>repmgr</command> binary.
</para>
<para>
@@ -235,7 +235,7 @@
</para>
<para>
Check the data is updated as expected by examining the <structname>repmgr.nodes</structname>
table; restart <command>repmgrd</command> if required.
table; restart <application>repmgrd</application> if required.
</para>
<para>
The original <literal>repmgr_$cluster</literal> schema can be dropped at any time.