From 3f558416f3f9567a23c8d777d0a606ad183b0079 Mon Sep 17 00:00:00 2001 From: Ian Barwick Date: Tue, 7 Aug 2018 13:10:30 +0900 Subject: [PATCH] doc: clarify witness server location --- doc/configuring-witness-server.sgml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/doc/configuring-witness-server.sgml b/doc/configuring-witness-server.sgml index b0b18eb3..90e48fb3 100644 --- a/doc/configuring-witness-server.sgml +++ b/doc/configuring-witness-server.sgml @@ -16,15 +16,22 @@ A typical use case for a witness server is a two-node streaming replication setup, where the primary and standby are in different locations (data centres). - By creating a witness server in the same location as the primary, if the primary - becomes unavailable it's possible for the standby to decide whether it can - promote itself without risking a "split brain" scenario: if it can't see either the + By creating a witness server in the same location (data centre) as the primary, + if the primary becomes unavailable it's possible for the standby to decide whether + it can promote itself without risking a "split brain" scenario: if it can't see either the witness or the primary server, it's likely there's a network-level interruption and it should not promote itself. If it can seen the witness but not the primary, this proves there is no network interruption and the primary itself is unavailable, and it can therefore promote itself (and ideally take action to fence the former primary). + + + Never install a witness server on the same physical host + as another node in the replication cluster managed by &repmgr; - it's essential + the witness is not affected in any way by failure of another node. + + For more complex replication scenarios,e.g. with multiple datacentres, it may be preferable to use location-based failover, which ensures that only nodes