From c070c649f785b464609caf6208949bb2dfe89ff7 Mon Sep 17 00:00:00 2001
From: Ian Barwick <ian@2ndquadrant.com>
Date: Mon, 5 Feb 2018 14:01:37 +0900
Subject: [PATCH] doc: minor fixes to BDR docs

Also remove duplicate file.
---
 doc/repmgr-bdr.sgml  | 37 -------------------------------------
 doc/repmgrd-bdr.sgml | 10 ++++++----
 2 files changed, 6 insertions(+), 41 deletions(-)
 delete mode 100644 doc/repmgr-bdr.sgml

diff --git a/doc/repmgr-bdr.sgml b/doc/repmgr-bdr.sgml
deleted file mode 100644
index 58685c6e..00000000
--- a/doc/repmgr-bdr.sgml
+++ /dev/null
@@ -1,37 +0,0 @@
-<chapter id="repmgrd-bdr">
-  <indexterm>
-    <primary>repmgrd</primary>
-    <secondary>BDR</secondary>
-  </indexterm>
-
-  <indexterm>
-    <primary>BDR</primary>
-  </indexterm>
-
-  <title>BDR failover with repmgrd</title>
-  <para>
-    &repmgr; 4.x provides support for monitoring BDR nodes and taking action in
-    case one of the nodes fails.
-  </para>
-  <note>
-    <simpara>
-      Due to the nature of BDR, it's only safe to use this solution for
-      a two-node scenario. Introducing additional nodes will create an inherent
-      risk of node desynchronisation if a node goes down without being cleanly
-      removed from the cluster.
-    </simpara>
-  </note>
-  <para>
-    In contrast to streaming replication, there's no concept of "promoting" a new
-    primary node with BDR. Instead, "failover" involves monitoring both nodes
-    with `repmgrd` and redirecting queries from the failed node to the remaining
-    active node. This can be done by using an
-    <link linkend="event-notifications">event notification</link> script
-    which is called by <application>repmgrd</application> to dynamically
-    reconfigure a proxy server/connection pooler such as <application>PgBouncer</application>.
-  </para>
-
-  <sect1 id="prerequisites" xreflable="BDR prequisites">
-  </sect1>
-</chapter>
-
diff --git a/doc/repmgrd-bdr.sgml b/doc/repmgrd-bdr.sgml
index aa3f97a8..45d1e36a 100644
--- a/doc/repmgrd-bdr.sgml
+++ b/doc/repmgrd-bdr.sgml
@@ -24,7 +24,7 @@
   <para>
     In contrast to streaming replication, there's no concept of "promoting" a new
     primary node with BDR. Instead, "failover" involves monitoring both nodes
-    with `repmgrd` and redirecting queries from the failed node to the remaining
+    with <application>repmgrd</application> and redirecting queries from the failed node to the remaining
     active node. This can be done by using an
     <link linkend="event-notifications">event notification</link> script
     which is called by <application>repmgrd</application> to dynamically
@@ -231,7 +231,7 @@
         <term><option>%c</option></term>
         <listitem>
           <para>
-            conninfo string of the next available node (<varname>bdr_failover</varname>)
+            conninfo string of the next available node (<varname>bdr_failover</varname> and <varname>bdr_recovery</varname>)
           </para>
         </listitem>
       </varlistentry>
@@ -239,7 +239,7 @@
         <term><option>%a</option></term>
         <listitem>
           <para>
-            name of the next available node (<varname>bdr_failover</varname>)
+            name of the next available node (<varname>bdr_failover</varname> and <varname>bdr_recovery</varname>)
           </para>
         </listitem>
       </varlistentry>
@@ -250,7 +250,9 @@
       particular failover events, in this case <varname>bdr_failover</varname>.
     </para>
     <para>
-      The provided sample script (`scripts/bdr-pgbouncer.sh`) is configured as follows:
+      The provided sample script
+     (<literal><ulink url="https://raw.githubusercontent.com/2ndQuadrant/repmgr/master/scripts/bdr-pgbouncer.sh">scripts/bdr-pgbouncer.sh</ulink></literal>)
+      is configured as follows:
       <programlisting>
         event_notification_command='/path/to/bdr-pgbouncer.sh %n %e %s "%c" "%a"'</programlisting>
     </para>