repmgr 3.3 removes ordering constraints from standby registration
Standbys can register before startup, and cascading replicas can register before their upstream nodes. The changes separate replication provisioning from metadata ordering.
Provisioning a cascading replication cluster involves dependencies that do not all need to become startup dependencies. A downstream standby needs an upstream server to receive changes, but the management catalogue need not require every server to finish registration in exactly that order. repmgr 3.3, released January 6, relaxes that ordering while adding more explicit control over the connection information written during cloning.
The distinction matters for PostgreSQL automation. A provisioning process may know the intended replication topology before every database process has started. Requiring that process to wait for each node simply to record the topology imposes coordination beyond the physical replication requirement. The new registration behavior lets repmgr represent some of that intended state earlier.
I prefer PostgreSQL tools that make the state they manage explicit. A replica data directory, a running standby, and a registered management record describe different conditions. Combining them into one assumed state makes automation harder to reason about, especially when a command stops halfway through provisioning.
Registration can precede startup
The 3.3 release notes explain that standby registration previously required the standby PostgreSQL process to be running. It can now register a stopped standby when the command receives connection details for the primary. The management record can therefore exist before that standby accepts connections.
This is a change to the registration procedure. It does not mean that a registered standby is already replaying changes or ready for application queries. An automation system still needs to distinguish recording a node from starting it. The useful improvement is that those actions can follow the dependencies appropriate to each action, instead of requiring a running database simply to create its record.
Cascading replication adds another dependency. The README at the release tag defines an upstream node as either the primary or another standby. Each node record identifies its upstream. That relationship lets repmgr describe a topology in which some standbys receive changes through an intermediate replica.
Previously, an unregistered upstream could obstruct registration of a downstream standby. Version 3.3 permits forced registration to create a placeholder for that missing upstream record. The real upstream node must subsequently register with the force option to replace the placeholder. The mechanism accommodates provisioning processes that cannot reliably control the order in which standby cloning completes.
The placeholder has a specific purpose. It represents a referenced node until the actual registration supplies its information. Treating it as a completed registration would lose the distinction the feature introduces. The topology can be recorded incrementally, but provisioning still has to replace the temporary entry. The release notes explicitly require that replacement step.
Cloning needs an explicit connection policy
A clone operation prepares more than a copy of database files. According to the versioned README, standby clone also creates recovery.conf, which configures the new server as a standby. The connection information placed there determines how the standby reaches its upstream after startup. It is therefore part of the provisioned server state, separate from the connection used to run an administrative command.
Version 3.3 adds the upstream-conninfo option to supply the connection string for primary_conninfo explicitly. That helps when the administrative connection and the eventual replication connection need different parameters. The provisioner can state the intended runtime connection instead of relying on incidental details of how it reached the source during cloning.
The no-conninfo-password option separately prevents a password from being written into primary_conninfo. That option controls one output of the cloning process. It does not establish a complete authentication configuration by itself. The standby still needs an authentication arrangement that permits its connection, but a password no longer has to appear in that particular generated setting.
The release also fixes escaping of parameters written to primary_conninfo. This is a correctness issue at the boundary between accepting a connection string and generating another configuration file. A value that reaches an administrative command successfully must retain its meaning when the standby later reads the generated configuration. Correct escaping is necessary for those two interpretations to agree.
Logging changes affect failover commands
The command line utility now logs to the console by default. Earlier versions sent its output to the same destination as repmgrd, often a file or syslog. Interactive use benefits because the person invoking the command sees the explanation where they ran it. An automated failover has a different requirement because the daemon may invoke the utility without an interactive reader.
The release notes provide the log-to-file option for that case. Existing commands executed by repmgrd need to account for the changed destination if their output belongs in the daemon logging arrangement. This is an operational interface change even though it does not alter how PostgreSQL streams changes between servers.
I consider that distinction useful because an administrative utility and a monitoring daemon have different callers. Console output suits a command a person runs, while captured output suits a command triggered during failover. Making the choice explicit gives the deployment a way to preserve the evidence of an automated operation.
Compatibility remains bounded
The release supports PostgreSQL 9.3 and later. Its announcement also begins accommodating PostgreSQL 10 development, while warning that replication changes remain in progress. Testing against that development server requires the repmgr master branch. That is a statement about ongoing compatibility work, not a promise that the released package already supports every future replication change.
For installations on repmgr 3.1.2 or later, the release notes permit replacing the installed version directly and restarting repmgrd if it is running. Older installations have metadata upgrade scripts appropriate to their starting version. The practical change in 3.3 is a more flexible provisioning sequence, with explicit placeholders and connection settings that still require the deployment to complete the intended node state.