| repmgr 4.2 Documentation | |||
|---|---|---|---|
| Prev | Up | Appendix C. FAQ (Frequently Asked Questions) | Next |
repmgr 4 is a complete rewrite of the existing repmgr code base and implements repmgr as a PostgreSQL extension. It supports all PostgreSQL versions from 9.3 (although some repmgr features are not available for PostgreSQL 9.3 and 9.4).
repmgr 3.x builds on the improved replication facilities added in PostgreSQL 9.3, as well as improved automated failover support via repmgrd, and is not compatible with PostgreSQL 9.2 and earlier. We recommend upgrading to repmgr 4, as the repmgr 3.x series is no longer maintained.
repmgr 2.x supports PostgreSQL 9.0 ~ 9.3. While it is compatible with PostgreSQL 9.3, we recommend using repmgr 4.x. repmgr 2.x is no longer maintained.
See also repmgr compatibility matrix and Should I upgrade repmgr?.
Replication slots, introduced in PostgreSQL 9.4, ensure that the primary server will retain WAL files until they have been consumed by all standby servers. This means standby servers should never fail due to not being able to retrieve required WAL files from the primary.
However this does mean that if a standby is no longer connected to the primary, the presence of the replication slot will cause WAL files to be retained indefinitely, and eventually lead to disk space exhaustion.
Tip: 2ndQuadrant's recommended configuration is to configure Barman as a fallback source of WAL files, rather than maintain replication slots for each standby. See also: Using Barman as a WAL file source.
Normally at least same number as the number of standbys which will connect to the node. Note that changes to max_replication_slots require a server restart to take effect, and as there is no particular penalty for unused replication slots, setting a higher figure will make adding new nodes easier.
Before PostgreSQL 10, hash indexes were not WAL logged and are therefore not suitable for use in streaming replication in PostgreSQL 9.6 and earlier. See the PostgreSQL documentation for details.
From PostgreSQL 10, this restriction has been lifted and hash indexes can be used in a streaming replication cluster.
For minor version upgrades, e.g. from 9.6.7 to 9.6.8, a common approach is to upgrade a standby to the latest version, perform a switchover promoting it to a primary, then upgrade the former primary.
For major version upgrades (e.g. from PostgreSQL 9.6 to PostgreSQL 10), the traditional approach is to "reseed" a cluster by upgrading a single node with pg_upgrade and recloning standbys from this.
To minimize downtime during major upgrades, for more recent PostgreSQL versions (PostgreSQL 9.4 and later), pglogical can be used to set up a parallel cluster using the newer PostgreSQL version, which can be kept in sync with the existing production cluster until the new cluster is ready to be put into production.
It means the repmgr extension code is not installed in the PostgreSQL application directory. This typically happens when using PostgreSQL packages provided by a third-party vendor, which often have different filesystem layouts.
Either use PostgreSQL packages provided by the community or 2ndQuadrant; if this is not possible, contact your vendor for assistance.
See appendix Installing old package versions for details.
No.
repmgr (together with repmgrd) assists with managing replication. It does not actually perform replication, which is part of the core PostgreSQL functionality.
No. See preceding question.
Yes. If different "major" repmgr versions (e.g. 3.3.x and 4.1.x) are present, repmgr (in particular repmgrd) may not run, or run properly, or in the worst case (if different repmgrd versions are running and there are differences in the failover implementation) break your replication cluster.
If different "minor" repmgr versions (e.g. 4.1.1 and 4.1.6) are installed, repmgr will function, but we strongly recommend always running the same version to ensure there are no unexpected suprises, e.g. a newer version behaving slightly differently to the older version.
See also Should I upgrade repmgr?.
Yes.
We don't release new versions for fun, you know. Upgrading may require a little effort, but running an older repmgr version with bugs which have since been fixed may end up costing you more effort. The same applies to PostgreSQL itself.
In some circumstances repmgr may need to access a PostgreSQL data directory while the PostgreSQL server is not running, e.g. to confirm it shut down cleanly during a switchover.
Additionally, this provides support when using repmgr on PostgreSQL 9.6 and earlier, where the repmgr user is not a superuser; in that case the repmgr user will not be able to access the data_directory configuration setting, access to which is restricted to superusers. (In PostgreSQL 10 and later, non-superusers can be added to the group pg_read_all_settings which will enable them to read this setting).