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

doc: various spelling fixes

Browse Source 
Via GitHub #687.
This commit is contained in:
Josh Soref
2020-12-16 19:14:28 -05:00
committed by Ian Barwick
parent f619c3a8ff
commit 842c67ca18
16 changed files with 23 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
HISTORY
View File

@@ -43,7 +43,7 @@
repmgr: ensure postgresql.auto.conf is created with correct permissions (Ian)
repmgr: minimize requirement to check upstream data directory location
during "standby clone" (Ian)
repmgr: warn about missing pg_rewind prerequisites when excuting
repmgr: warn about missing pg_rewind prerequisites when executing
"standby clone" (Ian)
repmgr: add --upstream option to "node check"
repmgr: report error code on follow/rejoin failure due to non-available

2
TODO.md
View File

@@ -1,7 +1,7 @@
TODO
====
This file contains a list of improvements which are desireable and/or have
This file contains a list of improvements which are desirable and/or have
been requested, and which we aim to address/implement when time and resources
permit.

10
doc/appendix-faq.xml
View File

@@ -170,7 +170,7 @@
<para>
If different &quot;minor&quot; &repmgr; versions (e.g. 4.1.1 and 4.1.6) are installed,
&repmgr; will function, but we strongly recommend always running the same version
to ensure there are no unexpected suprises, e.g. a newer version behaving slightly
to ensure there are no unexpected surprises, e.g. a newer version behaving slightly
differently to the older version.
</para>
<para>
@@ -212,7 +212,7 @@
</para>
</sect2>
<sect2 id="faq-third-party-packages" xreflabel="Compatability with third party vendor packages">
<sect2 id="faq-third-party-packages" xreflabel="Compatibility with third party vendor packages">
<title>Are &repmgr; packages compatible with <literal>$third_party_vendor</literal>'s packages?</title>
<para>
&repmgr; packages provided by 2ndQuadrant are compatible with the community-provided PostgreSQL
@@ -311,7 +311,7 @@
</para>
</sect2>
<sect2 id="faq-repmgr-shared-preload-libaries-no-repmgrd" xreflabel="shared_preload_libraries without repmgrd">
<sect2 id="faq-repmgr-shared-preload-libraries-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 &repmgrd;?</title>
<para>
@@ -459,7 +459,7 @@
</title>
<para>
<varname>promote_command</varname> or <varname>follow_command</varname> can be user-defined scripts,
so &repmgr; will not apply <option>pg_bindir</option> even if excuting &repmgr;. Always provide the full
so &repmgr; will not apply <option>pg_bindir</option> even if executing &repmgr;. Always provide the full
path; see <xref linkend="repmgrd-automatic-failover-configuration"/> for more details.
</para>
</sect2>
@@ -479,7 +479,7 @@
is out-of-date, which may lead to incorrect failover behaviour.
</para>
<para>
The onus is therefore on the adminstrator to manually set the cluster to a stable, healthy state before
The onus is therefore on the administrator to manually set the cluster to a stable, healthy state before
starting &repmgrd;.
</para>
</sect2>

4
doc/appendix-packages.xml
View File

@@ -398,7 +398,7 @@
</indexterm>
<indexterm>
<primary>packages</primary>
<secondary>snaphots</secondary>
<secondary>snapshots</secondary>
</indexterm>
<para>
@@ -439,7 +439,7 @@ curl https://dl.2ndquadrant.com/default/snapshot/get/9.6/rpm | sudo bash</progra
The package name will be formatted like this:
<programlisting>
repmgr96-4.1.1-0.0git320.g5113ab0.1.el7.x86_64.rpm</programlisting>
containg the snapshot build number (here: <literal>320</literal>) and the hash
containing the snapshot build number (here: <literal>320</literal>) and the hash
of the <application>git</application> commit it was built from (here: <literal>g5113ab0</literal>).
</para>

2
doc/appendix-release-notes.xml
View File

@@ -1199,7 +1199,7 @@ REPMGRD_OPTS="--daemonize=false"</programlisting>
</para>
<para>
Possible values are <literal>ping</literal> (default; uses <command>PQping()</command> to
determine server availability), <literal>connection</literal> (attempst to make a new connection to
determine server availability), <literal>connection</literal> (attempts to make a new connection to
the upstream node), and <literal>query</literal> (determines server availability
by executing an SQL statement on the node via the existing connection).
</para>

2
doc/appendix-support.xml
View File

@@ -64,7 +64,7 @@
<listitem>
<simpara>
<filename>repmpgr.conf</filename> files (suitably anonymized if necessary)
<filename>repmgr.conf</filename> files (suitably anonymized if necessary)
</simpara>
</listitem>

4
doc/cloning-standbys.xml
View File

@@ -319,7 +319,7 @@ description = "Main cluster"
Cascading replication, introduced with PostgreSQL 9.2, enables a standby server
to replicate from another standby server rather than directly from the primary,
meaning replication changes "cascade" down through a hierarchy of servers. This
can be used to reduce load on the primary and minimize bandwith usage between
can be used to reduce load on the primary and minimize bandwidth usage between
sites. For more details, see the
<ulink url="https://www.postgresql.org/docs/current/warm-standby.html#CASCADING-REPLICATION">
PostgreSQL cascading replication documentation</ulink>.
@@ -391,7 +391,7 @@ description = "Main cluster"
cluster, you may wish to clone a downstream standby whose upstream node
does not yet exist. In this case you can clone from the primary (or
another upstream node); provide the parameter <literal>--upstream-conninfo</literal>
to explictly set the upstream's <varname>primary_conninfo</varname> string
to explicitly set the upstream's <varname>primary_conninfo</varname> string
in <filename>recovery.conf</filename>.
</simpara>
</tip>

2
doc/quickstart.xml
View File

@@ -284,7 +284,7 @@
<tip>
<simpara>
For Debian-based distributions we recommend explictly setting
For Debian-based distributions we recommend explicitly setting
<option>pg_bindir</option> to the directory where <command>pg_ctl</command> and other binaries
not in the standard path are located. For PostgreSQL 9.6 this would be <filename>/usr/lib/postgresql/9.6/bin/</filename>.
</simpara>

2
doc/repmgr-daemon-start.xml
View File

@@ -25,7 +25,7 @@
</para>
<para>
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>--wait</option>
started. This behaviour can be overridden by specifying a different value using the <option>--wait</option>
option, or disabled altogether with the <option>--no-wait</option> option.
</para>

2
doc/repmgr-daemon-stop.xml
View File

@@ -26,7 +26,7 @@
<para>
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>--wait</option>
stopped. This behaviour can be overridden by specifying a different value using the <option>--wait</option>
option, or disabled altogether with the <option>--no-wait</option> option.
</para>
<note>

2
doc/repmgr-node-rejoin.xml
View File

@@ -457,7 +457,7 @@
and ensure the standby can be attached to it. If <application>pg_rewind</application> was actually executed,
it will have copied in the <filename>.history</filename> file from the target primary server; this must
be removed. <command>repmgr node rejoin</command> can then be used to attach the standby to the original
primary. Ensure any changes pending on the primary have propogated to the standby. Then shut down the primary
primary. Ensure any changes pending on the primary have propagated to the standby. Then shut down the primary
server <emphasis>first</emphasis>, before shutting down the standby. It should then be possible to
use <command>repmgr node rejoin</command> to attach the standby to the new primary.
</para>

4
doc/repmgr-standby-promote.xml
View File

@@ -189,14 +189,14 @@
</listitem>
<listitem>
<simpara>
If the promotion candidate has insufficient free walsenders to accomodate the standbys which will
If the promotion candidate has insufficient free walsenders to accommodate the standbys which will
be attached to it, the standby will be promoted anyway.
</simpara>
</listitem>
<listitem>
<simpara>
If replication slots are in use but the promotion candidate has insufficient free replication slots
to accomodate the standbys which will be attached to it, the standby will be promoted anyway.
to accommodate the standbys which will be attached to it, the standby will be promoted anyway.
</simpara>
</listitem>
</itemizedlist>

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

@@ -586,7 +586,7 @@ INFO: node 3 received notification to rerun promotion candidate election
<sect2 id="repmgrd-primary-child-disconnection-caveats">
<title>Standby disconnections monitoring caveats</title>
<para>
The follwing caveats should be considered if you are intending to use this functionality.
The following caveats should be considered if you are intending to use this functionality.
</para>
<para>
<itemizedlist mark="bullet">

2
doc/repmgrd-configuration.xml
View File

@@ -969,7 +969,7 @@ repmgrd_service_stop_command='sudo systemctl repmgr12 stop'
</para>
<para>
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
in the operating system's temporary directory (as determined by the environment variable
<varname>TMPDIR</varname>, or if that is not set, will use <filename>/tmp</filename>).
</para>
<para>

2
doc/upgrading-repmgr.xml
View File

@@ -482,7 +482,7 @@ ALTER EXTENSION repmgr UPDATE</programlisting>
<simpara>
If you don't care about any data from the existing &repmgr; installation,
(e.g. the contents of the <structname>events</structname> and <structname>monitoring</structname>
tables), the follwing steps can be skipped; proceed to <xref linkend="upgrade-reregister-nodes"/>.
tables), the following steps can be skipped; proceed to <xref linkend="upgrade-reregister-nodes"/>.
</simpara>
</tip>

2
repmgr.conf.sample
View File

@@ -323,7 +323,7 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh"
# for the the local node to restart and become ready to accept connections after
# executing "follow_command" (defaults to the value set in "standby_reconnect_timeout")
#monitoring_history=no # Whether to write monitoring data to the "montoring_history" table
#monitoring_history=no # Whether to write monitoring data to the "monitoring_history" table
#monitor_interval_secs=2 # Interval (in seconds) at which to write monitoring data
#degraded_monitoring_timeout=-1 # Interval (in seconds) after which repmgrd will terminate if the
# server(s) being monitored are no longer available. -1 (default)