Use 100 as the default priority; 0 or less means node will never be promoted

FAQ.md

@@ -92,4 +92,22 @@ General
   Not necessarily. However if you have an uneven number of nodes spread
   over more than one network segment, a witness server will enable
   better handling of a 'split brain' situation by providing a "casting
-  vote" on the preferred network segment.
+  vote" on the preferred network segment.
+
+- How can I prevent a node from ever being promoted to master?
+
+  In `rempgr.conf`, set its priority to a value of 0 or less.
+
+- Does `repmgrd` support delayed standbys?
+
+  `repmgrd` can monitor delayed standbys - those set up with
+  `recovery_min_apply_delay` set to a non-zero value in `recovery.conf` -
+  but as it's not currently possible to directly examine the value
+  applied to the standby, `repmgrd` may not be able to properly evaluate
+  the node as a promotion candidate.
+
+  We recommend that delayed standbys are explicitly excluded from promotion
+  by setting `priority` to 0 in `repmgr.conf`.
+
+  Note that after registering a delayed standby, `repmgrd` will only start
+  once the metadata added in the master node has been replicated.

README.md

@@ -169,7 +169,7 @@ If your PostgreSQL binaries (`pg_ctl`, `pg_basebackup`) are not in your
 
     pg_bindir=/path/to/postgres/bin
 
-See `repmgr.conf.sample` for an example configuration file with
+See `repmgr.conf.sample` for an example configuration file with all
 available configuration settings annotated.
 
 ### Starting up
@@ -186,14 +186,14 @@ Failover
 
 To promote a standby to master, on the standby execute e.g.:
 
-    repmgr -f $HOME/repmgr/repmgr.conf --verbose standby promote
+    repmgr -f /etc/repmgr/repmgr.conf --verbose standby promote
 
 `repmgr` will attempt to connect to the current master to verify that it
 is not available (if it is, `repmgr` will not promote the standby).
 
 Other standby servers need to be told to follow the new master with e.g.:
 
-    repmgr -f $HOME/repmgr/repmgr.conf --verbose standby follow
+    repmgr -f /etc/repmgr/repmgr.conf --verbose standby follow
 
 See file `FAILOVER.rst` for details on setting up automated failover.
 
@@ -206,7 +206,7 @@ as a standby. First, ensure that the master's PostgreSQL server is
 no longer running; then use `repmgr standby clone` to re-sync its
 data directory with the current master, e.g.:
 
-    repmgr -f $HOME/repmgr/repmgr.conf \
+    repmgr -f /etc/repmgr/repmgr.conf \
       --force --rsync-only \
       -h node2 -d repmgr -U repmgr --verbose \
       standby clone
@@ -222,7 +222,7 @@ The node can then be restarted.
 The node will then need to be re-registered with `repmgr`; again
 the `--force` option is required to update the existing record:
 
-     repmgr -f $HOME/repmgr/repmgr.conf
+     repmgr -f /etc/repmgr/repmgr.conf
        --force \
        standby register
 
@@ -235,13 +235,13 @@ Replication management with repmgrd
 and which can automate actions such as failover and updating standbys to
 follow the new master.`repmgrd`   can be started simply with e.g.:
 
-    repmgrd -f $HOME/repmgr/repmgr.conf --verbose > $HOME/repmgr/repmgr.log 2>&1
+    repmgrd -f /etc/repmgr/repmgr.conf --verbose > $HOME/repmgr/repmgr.log 2>&1
 
 or alternatively:
 
-    repmgrd -f $HOME/repmgr/repmgr.conf --verbose --monitoring-history > $HOME/repmgr/repmgrd.log 2>&1
+    repmgrd -f /etc/repmgr/repmgr.conf --verbose --monitoring-history > $HOME/repmgr/repmgrd.log 2>&1
 
-which will track replication advance or lag on all registerd standbys.
+which will track replication advance or lag on all registered standbys.
 
 For permanent operation, we recommend using the options `-d/--daemonize` to
 detach the `repmgrd` process, and `-p/--pid-file` to write the process PID
@@ -344,12 +344,12 @@ Following event types currently exist:
 
     master_register
     standby_register
-    standby_clone 
-    standby_promote 
-    witness_create 
+    standby_clone
+    standby_promote
+    witness_create
     repmgrd_start
-    repmgrd_failover_promote 
-    repmgrd_failover_follow 
+    repmgrd_failover_promote
+    repmgrd_failover_follow
 
 
 

config.c

@@ -117,7 +117,7 @@ parse_config(const char *config_file, t_configuration_options *options)
 	options->upstream_node = NO_UPSTREAM_NODE;
 	memset(options->conninfo, 0, sizeof(options->conninfo));
 	options->failover = MANUAL_FAILOVER;
-	options->priority = 0;
+	options->priority = DEFAULT_PRIORITY;
 	memset(options->node_name, 0, sizeof(options->node_name));
 	memset(options->promote_command, 0, sizeof(options->promote_command));
 	memset(options->follow_command, 0, sizeof(options->follow_command));

repmgr.conf.sample

@@ -116,7 +116,7 @@ reconnect_interval=10
 
 # Autofailover options
 failover=automatic  # one of 'automatic', 'manual'
-priority=-1
+priority=100        # a value of zero or less prevents the node being promoted to master
 promote_command='repmgr standby promote -f /path/to/repmgr.conf'
 follow_command='repmgr standby follow -f /path/to/repmgr.conf -W'
 

repmgr.h

@@ -44,7 +44,7 @@
 #define DEFAULT_MASTER_PORT		"5432"
 #define DEFAULT_DBNAME			"postgres"
 #define DEFAULT_REPMGR_SCHEMA_PREFIX	"repmgr_"
-
+#define DEFAULT_PRIORITY		100
 #define FAILOVER_NODES_MAX_CHECK 50
 
 #define MANUAL_FAILOVER		0
@@ -52,7 +52,6 @@
 #define NO_UPSTREAM_NODE	-1
 
 
-
 typedef enum {
     UNKNOWN = 0,
 	MASTER,

repmgrd.c

@@ -1065,7 +1065,8 @@ do_master_failover(void)
 			"  FROM %s.repl_nodes "
 			" WHERE cluster = '%s' "
             "   AND active IS TRUE "
-			" ORDER BY priority, id "
+			"   AND priority > 0 "
+			" ORDER BY priority DESC, id "
 			" LIMIT %i ",
 			get_repmgr_schema_quoted(my_local_conn),
 			local_options.cluster_name,

sql/repmgr2_repmgr3.sql

@@ -44,7 +44,7 @@ INSERT INTO repl_nodes
             cluster,
             name,
             conninfo,
-            priority
+            priority + 100
        FROM repl_nodes2_0;
 
 /*