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

Standardize terminology on "primary" (in place of "master")

Browse Source
This commit is contained in:
Ian Barwick
2017-10-24 13:42:50 +09:00
parent 90733aecf7
commit f58b102d51
6 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/appendix-faq.sgml
View File

@@ -205,7 +205,7 @@
</para>
<para>
Note that after registering a delayed standby, <application>repmgrd</application> will only start
once the metadata added in the master node has been replicated.
once the metadata added in the primary node has been replicated.
</para>
</sect2>
@@ -218,7 +218,7 @@
</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 <application>repmgrd</application> refuses to start?</title>
<title>I've recloned a failed primary 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

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

@@ -19,7 +19,7 @@
If the standby is not running, the command can be executed on another
node by providing the id of the node to be unregistered using
the command line parameter <literal>--node-id</literal>, e.g. executing the following
command on the master server will unregister the standby with
command on the primary server will unregister the standby with
id <literal>3</literal>:
<programlisting>
repmgr standby unregister -f /etc/repmgr.conf --node-id=3