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

Merge pull request #50 from wking/autofailover-quick-setup-copy-edits

Browse Source 
autofailover_quick_setup.rst: Assorted copy edits
This commit is contained in:
Abhijit Menon-Sen
2015-03-15 23:13:28 +05:30
parent 7ad001e0c5 5d26e27b48
commit 6d608aea7f
1 changed files with 42 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

78
autofailover_quick_setup.rst
View File

@@ -1,11 +1,11 @@
=====================================================
PostgreSQL Automatic Fail-Over - User Documentation
=====================================================
====================================================
PostgreSQL Automatic Failover - User Documentation
====================================================
Automatic Failover
==================
repmgr allows setups for automatic failover when it detects the failure of the master node.
repmgr allows for automatic failover when it detects the failure of the master node.
Following is a quick setup for this.
Installation
@@ -14,34 +14,33 @@ Installation
For convenience, we define:
**node1**
is the hostname fully qualified of the Master server, IP 192.168.1.10
is the fully qualified domain name of the Master server, IP 192.168.1.10
**node2**
is the hostname fully qualified of the Standby server, IP 192.168.1.11
is the fully qualified domain name of the Standby server, IP 192.168.1.11
**witness**
is the hostname fully qualified of the server used for witness, IP 192.168.1.12
is the fully qualified domain name of the server used as a witness, IP 192.168.1.12
**Note:** It is not recommanded to use name defining status of a server like «masterserver»,
this is a name leading to confusion once a failover take place and the Master is
**Note:** We don't recommend using names with the status of a server like «masterserver»,
because it would be confusing once a failover takes place and the Master is
now on the «standbyserver».
Summary
-------
2 PostgreSQL servers are involved in the replication. Automatic fail-over need
to vote to decide what server it should promote, thus an odd number is required
and a witness-repmgrd is installed in a third server where it uses a PostgreSQL
2 PostgreSQL servers are involved in the replication. Automatic failover needs
a vote to decide what server it should promote, so an odd number is required.
A witness-repmgrd is installed in a third server where it uses a PostgreSQL
cluster to communicate with other repmgrd daemons.
1. Install PostgreSQL in all the servers involved (including the server used for
witness)
1. Install PostgreSQL in all the servers involved (including the witness server)
2. Install repmgr in all the servers involved (including the server used for witness)
2. Install repmgr in all the servers involved (including the witness server)
3. Configure the Master PostreSQL
4. Clone the Master to the Standby using "repmgr standby clone" command
5. Configure repmgr in all the servers involved (including the server used for witness)
5. Configure repmgr in all the servers involved (including the witness server)
6. Register Master and Standby nodes
@@ -66,14 +65,14 @@ Install repmgr following the steps in the README file.
Configure PostreSQL
-------------------
Log in node1.
Log in to node1.
Edit the file postgresql.conf and modify the parameters::
listen_addresses='*'
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .' # we can also use exit 0, anything that
archive_command = 'cd .' # we can also use exit 0, anything that
# just does nothing
max_wal_senders = 10
wal_keep_segments = 5000 # 80 GB required on pg_xlog
@@ -117,9 +116,9 @@ Create the ssh-key for the postgres user and copy it to other servers::
Clone Master
------------
Log in node2.
Log in to node2.
Clone the node1 (the current Master)::
Clone node1 (the current Master)::
su - postgres
repmgr -d repmgr -U repmgr -h node1 standby clone
@@ -133,7 +132,7 @@ And check everything is fine in the server log.
Configure repmgr
----------------
Log in each server and configure repmgr by editing the file
Log in to each server and configure repmgr by editing the file
/etc/repmgr/repmgr.conf::
cluster=my_cluster
@@ -154,13 +153,13 @@ Log in each server and configure repmgr by editing the file
**node_name**
is an identifier for every node.
**conninfo**
is used to connect to the local PostgreSQL server (where the configuration file is) from any node. In the witness server configuration it is needed to add a 'port=5499' to the conninfo.
is used to connect to the local PostgreSQL server (where the configuration file is) from any node. In the witness server configuration you need to add a 'port=5499' to the conninfo.
**master_response_timeout**
is the maximum amount of time we are going to wait before deciding the master has died and start failover procedure.
is the maximum amount of time we are going to wait before deciding the master has died and start the failover procedure.
**reconnect_attempts**
is the number of times we will try to reconnect to master after a failure has been detected and before start failover procedure.
is the number of times we will try to reconnect to master after a failure has been detected and before start the failover procedure.
**reconnect_interval**
is the amount of time between retries to reconnect to master after a failure has been detected and before start failover procedure.
is the amount of time between retries to reconnect to master after a failure has been detected and before start the failover procedure.
**failover**
configure behavior: *manual* or *automatic*.
**promote_command**
@@ -171,14 +170,14 @@ Log in each server and configure repmgr by editing the file
Register Master and Standby
---------------------------
Log in node1.
Log in to node1.
Register the node as Master::
su - postgres
repmgr -f /etc/repmgr/repmgr.conf master register
Log in node2. Register it as a standby::
Log in to node2. Register it as a standby::
su - postgres
repmgr -f /etc/repmgr/repmgr.conf standby register
@@ -186,23 +185,30 @@ Log in node2. Register it as a standby::
Initialize witness server
-------------------------
Log in witness.
Log in to witness.
Initialize the witness server::
su - postgres
repmgr -d repmgr -U repmgr -h 192.168.1.10 -D $WITNESS_PGDATA -f /etc/repmgr/repmgr.conf witness create
It needs information to connect to the master to copy the configuration of the cluster, also it needs to know where it should initialize it's own $PGDATA.
As part of the procees it also ask for the superuser password so it can connect when needed.
The witness server needs the following information from the command
line:
* Connection details for the current master, to copy the cluster
configuration.
* A location for initializing its own $PGDATA.
It will also ask for the superuser password on the witness database so
it can reconnect when needed.
Start the repmgrd daemons
-------------------------
Log in node2 and witness.
Log in to node2 and witness::
su - postgres
repmgrd -f /etc/repmgr/repmgr.conf --daemonize -> /var/log/postgresql/repmgr.log 2>&1
su - postgres
repmgrd -f /etc/repmgr/repmgr.conf --daemonize -> /var/log/postgresql/repmgr.log 2>&1
**Note:** The Master does not need a repmgrd daemon.
@@ -212,12 +218,12 @@ Suspend Automatic behavior
Edit the repmgr.conf of the node to remove from automatic processing and change::
failover=manual
failover=manual
Then, signal repmgrd daemon::
su - postgres
kill -HUP `pidof repmgrd`
su - postgres
kill -HUP $(pidof repmgrd)
Usage
=====