Update document "repmgrd-node-fencing.md"

This commit is contained in:
Ian Barwick
2017-08-25 15:58:52 +09:00
parent 3b9d201e18
commit 1452238613

View File

@@ -1,14 +1,14 @@
Fencing a failed master node with repmgrd and pgbouncer Fencing a failed master node with repmgrd and pgbouncer
======================================================= =======================================================
With automatic failover, it's essential to ensure that a failed master With automatic failover, it's essential to ensure that a failed primary
remains inaccessible to your application, even if it comes back online remains inaccessible to your application, even if it comes back online
again, to avoid a split-brain situation. again, to avoid a split-brain situation.
By using `pgbouncer` together with `repmgrd`, it's possible to combine By using `pgbouncer` together with `repmgrd`, it's possible to combine
automatic failover with a process to isolate the failed master from automatic failover with a process to isolate the failed primary from
your application and ensure that all connections which should go to your application and ensure that all connections which should go to
the master are directed there smoothly without having to reconfigure the primary are directed there smoothly without having to reconfigure
your application. (Note that as a connection pooler, `pgbouncer` can your application. (Note that as a connection pooler, `pgbouncer` can
benefit your application in other ways, but those are beyond the scope benefit your application in other ways, but those are beyond the scope
of this document). of this document).
@@ -22,14 +22,14 @@ of this document).
* * * * * *
In a failover situation, `repmgrd` promotes a standby to master by executing In a failover situation, `repmgrd` promotes a standby to primary by executing
the command defined in `promote_command`. Normally this would be something like: the command defined in `promote_command`. Normally this would be something like:
repmgr standby promote -f /etc/repmgr.conf repmgr standby promote -f /etc/repmgr.conf
By wrapping this in a custom script which adjusts the `pgbouncer` configuration By wrapping this in a custom script which adjusts the `pgbouncer` configuration
on all nodes, it's possible to fence the failed master and redirect write on all nodes, it's possible to fence the failed primary and redirect write
connections to the new master. connections to the new primary.
The script consists of two sections: The script consists of two sections:
@@ -40,7 +40,7 @@ Note that it requires password-less SSH access from the `repmgr` nodes
to all the `pgbouncer` nodes to be able to update the `pgbouncer` to all the `pgbouncer` nodes to be able to update the `pgbouncer`
configuration files. configuration files.
For the purposes of this demonstration, we'll assume there are 3 nodes (master For the purposes of this demonstration, we'll assume there are 3 nodes (primary
and two standbys), with `pgbouncer` listening on port 6432 handling connections and two standbys), with `pgbouncer` listening on port 6432 handling connections
to a database called `appdb`. The `postgres` system user must have write to a database called `appdb`. The `postgres` system user must have write
access to the `pgbouncer` configuration files on all nodes. We'll assume access to the `pgbouncer` configuration files on all nodes. We'll assume
@@ -106,7 +106,7 @@ The actual script is as follows; adjust the configurable items as appropriate:
REPMGR_DB="repmgr" REPMGR_DB="repmgr"
REPMGR_USER="repmgr" REPMGR_USER="repmgr"
# 1. Promote this node from standby to master # 1. Promote this node from standby to primary
repmgr standby promote -f /etc/repmgr.conf repmgr standby promote -f /etc/repmgr.conf
@@ -141,8 +141,7 @@ The actual script is as follows; adjust the configurable items as appropriate:
echo "Reconfiguration of pgbouncer complete" echo "Reconfiguration of pgbouncer complete"
Script and template file should be installed on each node where Script and template file should be installed on each node where `repmgrd` is running.
`repmgrd` is running.
Finally, set `promote_command` in `repmgr.conf` on each node to Finally, set `promote_command` in `repmgr.conf` on each node to
point to the custom promote script: point to the custom promote script: