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

docs: miscellaneous cleanup

Browse Source
This commit is contained in:
Ian Barwick
2017-11-17 09:20:43 +09:00
parent 3164bfa043
commit e2b94adec3
7 changed files with 13 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/overview.sgml
View File

@@ -150,7 +150,7 @@
<listitem>
<para>
&repmgr; provides functionality to set up a so-called "witness server" to
assist in determining a new master server in a failover situation with more
assist in determining a new primary server in a failover situation with more
than one standby. The witness server itself is not part of the replication
cluster, although it does contain a copy of the repmgr metadata schema
(see below).
@@ -160,8 +160,8 @@
in the replication cluster are split over more than one location. In the event
of a loss of connectivity between locations, the presence or absence of
the witness server will decide whether a server at that location is promoted
to master; this is to prevent a "split-brain" situation where an isolated
location interprets a network outage as a failure of the (remote) master and
to primary; this is to prevent a "split-brain" situation where an isolated
location interprets a network outage as a failure of the (remote) primary and
promotes a (local) standby.
</para>
<para>

3
doc/repmgr-node-rejoin.sgml
View File

@@ -125,7 +125,7 @@
INFO: prerequisites for using pg_rewind are met
INFO: 2 files copied to "/tmp/repmgr-config-archive-node1"
NOTICE: executing pg_rewind
NOTICE: 2 files copied to /space/sda1/ibarwick/repmgr-test/node_1/data
NOTICE: 2 files copied to /var/lib/pgsql/data
INFO: directory "/tmp/repmgr-config-archive-node1" deleted
INFO: deleting "recovery.done"
INFO: setting node 1's primary to node 2
@@ -136,7 +136,6 @@
DETAIL: node 1 is now attached to node 2</programlisting>
</para>
</refsect1>
<refsect1>

4
doc/repmgr-witness-unregister.sgml
View File

@@ -32,7 +32,7 @@
<para>
Unregistering a running witness node:
<programlisting>
$ ./repmgr -f /space/sda1/ibarwick/repmgr-test/node_3/repmgr.conf witness unregister
$ repmgr -f /etc/repmgr.conf witness unregister
INFO: connecting to witness node "node3" (ID: 3)
INFO: unregistering witness node 3
INFO: witness unregistration complete
@@ -41,7 +41,7 @@
<para>
Unregistering a non-running witness node:
<programlisting>
$ ./repmgr -f /space/sda1/ibarwick/repmgr-test/node_3/repmgr.conf witness unregister -h localhost -p 5501 -F
$ repmgr -f /etc/repmgr.conf witness unregister -h localhost -p 5501 -F
INFO: connecting to witness node "node3" (ID: 3)
NOTICE: unable to connect to witness node "node3" (ID: 3), removing node record on cluster primary only
INFO: unregistering witness node 3

2
doc/repmgrd-demonstration.sgml
View File

@@ -61,7 +61,7 @@
[2017-08-24 23:32:12] [NOTICE] this node is the winner, will now promote self and inform other nodes
INFO: connecting to standby database
NOTICE: promoting standby
DETAIL: promoting server using '/home/barwick/devel/builds/HEAD/bin/pg_ctl -l /var/log/postgres/startup.log -w -D '/tmp/repmgr-test/node_2/data' promote'
DETAIL: promoting server using 'pg_ctl -l /var/log/postgres/startup.log -w -D '/var/lib/pgsql/data' promote'
INFO: reconnecting to promoted server
NOTICE: STANDBY PROMOTE successful
DETAIL: node 2 was successfully promoted to primary

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

@@ -15,7 +15,7 @@
in the main data centre and promoted a standby among themselves.
</para>
<para>
Previous &repmgr; versions used the concept of a "witness server" to
&repmgr; enables provision of &quot;<xref linkend="witness-server">&quot; to
artificially create a quorum of servers in a particular location, ensuring
that nodes in another location will not elect a new primary if they
are unable to see the majority of nodes. However this approach does not

4
doc/repmgrd-witness-server.sgml
View File

@@ -9,12 +9,12 @@
In a situation caused e.g. by a network interruption between two
data centres, it's important to avoid a "split-brain" situation where
both sides of the network assume they are the active segment and the
side without an active master unilaterally promotes one of its standbys.
side without an active primary unilaterally promotes one of its standbys.
</para>
<para>
To prevent this situation happening, it's essential to ensure that one
network segment has a "voting majority", so other segments will know
they're in the minority and not attempt to promote a new master. Where
they're in the minority and not attempt to promote a new primary. Where
an odd number of servers exists, this is not an issue. However, if each
network has an even number of nodes, it's necessary to provide some way
of ensuring a majority, which is where the witness server becomes useful.

6
doc/switchover.sgml
View File

@@ -62,9 +62,9 @@
Double-check which commands will be used to stop/start/restart the current
primary; on the primary execute:
<programlisting>
repmgr -f /etc./repmgr.conf node service --list --action=stop
repmgr -f /etc./repmgr.conf node service --list --action=start
repmgr -f /etc./repmgr.conf node service --list --action=restart
repmgr -f /etc/repmgr.conf node service --list --action=stop
repmgr -f /etc/repmgr.conf node service --list --action=start
repmgr -f /etc/repmgr.conf node service --list --action=restart
</programlisting>
</para>
<note>