repmgr node rejoin repmgr node rejoin repmgr node rejoin rejoin a dormant (stopped) node to the replication cluster Description Enables a dormant (stopped) node to be rejoined to the replication cluster. This can optionally use pg_rewind to re-integrate a node which has diverged from the rest of the cluster, typically a failed primary. If the node is running and needs to be attached to the current primary, use . Usage repmgr node rejoin -d '$conninfo' where $conninfo is the conninfo string of any reachable node in the cluster. repmgr.conf for the stopped node *must* be supplied explicitly if not otherwise available. Notes Currently repmgr node rejoin can only be used to attach a standby to the current primary, not another standby. The node must have been shut down cleanly; if this was not the case, it will need to be manually started (remove any existing recovery.conf file first) until it has reached a consistent recovery point, then shut down cleanly. If PostgreSQL is started in single-user mode and input is directed from /dev/null/, it will perform recovery then immediately quit, and will then be in a state suitable for use by pg_rewind. rm -f /var/lib/pgsql/data/recovery.conf postgres --single -D /var/lib/pgsql/data/ < /dev/null Using <command>pg_rewind</command> repmgr node rejoin can optionally use pg_rewind to re-integrate a node which has diverged from the rest of the cluster, typically a failed primary. pg_rewind is available in PostgreSQL 9.5 and later. pg_rewind *requires* that either wal_log_hints is enabled, or that data checksums were enabled when the cluster was initialized. See the pg_rewind documentation for details. To have repmgr node rejoin use pg_rewind if required, pass the command line option --force-rewind, which will tell &repmgr; to execute pg_rewind to ensure the node can be rejoined successfully. Be aware that if pg_rewind is executed and actually performs a rewind operation, any configuration files in the PostgreSQL data directory will be overwritten with those from the source server. To prevent this happening, provide a comma-separated list of files to retain using the --config-file command line option; the specified files will be archived in a temporary directory (whose parent directory can be specified with --config-archive-dir) and restored once the rewind operation is complete. Example, first using --dry-run, then actually executing the node rejoin command. $ repmgr node rejoin -f /etc/repmgr.conf -d 'host=node1 dbname=repmgr user=repmgr' \ --force-rewind --config-files=postgresql.local.conf,postgresql.conf --verbose --dry-run NOTICE: using provided configuration file "/etc/repmgr.conf" INFO: prerequisites for using pg_rewind are met INFO: file "postgresql.local.conf" would be copied to "/tmp/repmgr-config-archive-node1/postgresql.local.conf" INFO: file "postgresql.conf" would be copied to "/tmp/repmgr-config-archive-node1/postgresql.local.conf" INFO: 2 files would have been copied to "/tmp/repmgr-config-archive-node1" INFO: directory "/tmp/repmgr-config-archive-node1" deleted INFO: pg_rewind would now be executed DETAIL: pg_rewind command is: pg_rewind -D '/var/lib/postgresql/data' --source-server='host=node1 dbname=repmgr user=repmgr' $ repmgr node rejoin -f /etc/repmgr.conf -d 'host=node1 dbname=repmgr user=repmgr' \ --force-rewind --config-files=postgresql.local.conf,postgresql.conf --verbose NOTICE: using provided configuration file "/etc/repmgr.conf" INFO: prerequisites for using pg_rewind are met INFO: 2 files copied to "/tmp/repmgr-config-archive-node1" NOTICE: executing pg_rewind NOTICE: 2 files copied to /space/sda1/ibarwick/repmgr-test/node_1/data INFO: directory "/tmp/repmgr-config-archive-node1" deleted INFO: deleting "recovery.done" INFO: setting node 1's primary to node 2 NOTICE: starting server using "pg_ctl-l /var/log/postgres/startup.log -w -D '/var/lib/pgsql/data' start" waiting for server to start.... done server started NOTICE: NODE REJOIN successful DETAIL: node 1 is now attached to node 2 See also