repmgr standby switchover repmgr standby switchover repmgr standby switchover promote a standby to primary and demote the existing primary to a standby Promotes a standby to primary and demotes the existing primary to a standby. This command must be run on the standby to be promoted, and requires a passwordless SSH connection to the current primary. If other standbys are connected to the demotion candidate, &repmgr; can instruct these to follow the new primary if the option --siblings-follow is specified. This requires a passwordless SSH connection between the promotion candidate (new primary) and the standbys attached to the demotion candidate (existing primary). Performing a switchover is a non-trivial operation. In particular it relies on the current primary being able to shut down cleanly and quickly. &repmgr; will attempt to check for potential issues but cannot guarantee a successful switchover. --always-promote Promote standby to primary, even if it is behind original primary (original primary will be shut down in any case). --dry-run Check prerequisites but don't actually execute a switchover. Success of --dry-run does not imply the switchover will complete successfully, only that the prerequisites for performing the operation are met. -F --force Ignore warnings and continue anyway. Specifically, if a problem is encountered when shutting down the current primary, using -F/--force will cause &repmgr; to continue by promoting the standby to be the new primary, and if --siblings-follow is specified, attach any other standbys to the new primary. --force-rewind Use pg_rewind to reintegrate the old primary if necessary (PostgreSQL 9.5 and later). -R --remote-user System username for remote SSH operations (defaults to local system user). --siblings-follow Have standbys attached to the old primary follow the new primary. Execute with the --dry-run option to test the switchover as far as possible without actually changing the status of either node. repmgrd should not be active on any nodes while a switchover is being executed. This restriction may be lifted in a later version. External database connections, e.g. from an application, should not be permitted while the switchover is taking place. In particular, active transactions on the primary can potentially disrupt the shutdown process. standby_switchover and standby_promote event notifications will be generated for the new primary, and a node_rejoin event notification for the former primary (new standby). If using an event notification script, standby_switchover will populate the placeholder parameter %p with the node ID of the former primary. Following exit codes can be emitted by repmgr standby switchover: SUCCESS (0) The switchover completed successfully. ERR_SWITCHOVER_FAIL (18) The switchover could not be executed. ERR_SWITCHOVER_INCOMPLETE (22) The switchover was executed but a problem was encountered. Typically this means the former primary could not be reattached as a standby. For more details see the section .