kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/databases/repmgr/distinfo

8 lines
465 B
Text
Raw Normal View History

repmgr: updated to 4.4.0 4.4.0: repmgr client enhancements -------------------------- repmgr standby clone: prevent a standby from being cloned from a witness server (PostgreSQL 9.6 and later only). repmgr witness register: prevent a witness server from being registered on the replication cluster primary server (PostgreSQL 9.6 and later only). Registering a witness on the primary node would defeat the purpose of having a witness server, which is intended to remain running even if the cluster's primary goes down. repmgr standby follow: note that an active, reachable cluster primary is required for this command; and provide a more helpful error message if no reachable primary could be found. repmgr: when executing repmgr standby switchover, if --siblings-follow is not supplied, list all nodes which repmgr considers to be siblings (this will include the witness server, if in use), and which will remain attached to the old primary. repmgr: when executing repmgr standby switchover, ignore nodes which are unreachable and marked as inactive. Previously it would abort if any node was unreachable, as that means it was unable to check if repmgrd is running. However if the node has been marked as inactive in the repmgr metadata, it's reasonable to assume the node is no longer part of the replication cluster and does not need to be checked. repmgr standby switchover and repmgr standby promote: when executing with the --dry-run option, continue checks as far as possible even if errors are encountered. repmgr standby promote: add --siblings-follow (similar to repmgr standby switchover). repmgr daemon status: make output similar to that of repmgr cluster show for consistency and to make it easier to identify nodes not in the expected state. repmgr cluster show: display each node's timeline ID (PostgreSQL 9.6 and later only). repmgr cluster show and repmgr daemon status: show the upstream node name as reported by each individual node - this helps visualise situations where the cluster is in an unexpected state, and provide a better idea of the actual cluster state. For example, if a cluster has divided somehow and a set of nodes are following a new primary, when running either of these commands, repmgr will now show the name of the primary those nodes are actually following, rather than the now outdated node name recorded on the other side of the "split". A warning will also be issued about the unexpected situation. repmgr cluster show and repmgr daemon status: check if a node is attached to its advertised upstream node, and issue a warning if the node is not attached. repmgrd enhancements -------------------- On the primary node, repmgrd is now able to monitor standby connections and, if the number of nodes connected falls below a certain (configurable) value, execute a custom script. This provides an additional method for fencing an isolated primary node, and/or taking other action if one or more standys become disconnected. See section Monitoring standby disconnections on the primary node for more details. In a failover situation, repmgrd nodes on the standbys of the failed primary are now able confirm among themselves that none can still see the primary before continuing with the failover. The repmgr.conf option primary_visibility_consensus must be set to true to enable this functionality. See section Primary visibility consensus for more details. Bug fixes --------- Ensure BDR2-specific functionality cannot be used on BDR3 and later. The BDR support present in repmgr is for specific BDR2 use cases. repmgr: when executing repmgr standby clone in --dry-run mode, ensure provision of the --force option does not result in an existing data directory being modified in any way. repmgr: when executing repmgr primary register with the --force option, if another primary record exists but the associated node is unreachable (or running as a standby), set that node's record to inactive to enable the current node to be registered as a primary. repmgr: when executing repmgr standby clone with the --upstream-conninfo, ensure that application_name is set correctly in primary_conninfo. repmgr: when executing repmgr standby switchover, don't abort if one or more nodes are not reachable and they are marked as inactive. repmgr: canonicalize the data directory path when parsing the configuration file, so the provided path matches the path PostgreSQL reports as its data directory. Otherwise, if e.g. the data directory is configured with a trailing slash, repmgr node check --data-directory-config will return a spurious error. repmgrd: fix memory leak which occurs while the monitored PostgreSQL node is not running. Other ----- The repmgr documentation has been converted to DocBook XML format, as currently used by the main PostgreSQL project. This means it can now be built against any PostgreSQL version from 9.5 (previously it was not possible to build the documentation against PostgreSQL 10 or later), and makes it easier to provide the documentation in other formats such as PDF.
2019-07-12 14:49:26 +02:00
$NetBSD: distinfo,v 1.6 2019/07/12 12:49:26 adam Exp $
Import repmgr-4.0.1 as databases/repmgr Based on package provided by Matthieu Guegan in joyent/pkgsrc#49 repmgr is a suite of open-source tools to manage replication and failover within a cluster of PostgreSQL servers. It enhances PostgreSQL's built-in replication capabilities with utilities to set up standby servers, monitor replication, and perform administrative tasks such as failover or switchover operations.
2017-12-08 16:27:46 +01:00
repmgr: updated to 4.4.0 4.4.0: repmgr client enhancements -------------------------- repmgr standby clone: prevent a standby from being cloned from a witness server (PostgreSQL 9.6 and later only). repmgr witness register: prevent a witness server from being registered on the replication cluster primary server (PostgreSQL 9.6 and later only). Registering a witness on the primary node would defeat the purpose of having a witness server, which is intended to remain running even if the cluster's primary goes down. repmgr standby follow: note that an active, reachable cluster primary is required for this command; and provide a more helpful error message if no reachable primary could be found. repmgr: when executing repmgr standby switchover, if --siblings-follow is not supplied, list all nodes which repmgr considers to be siblings (this will include the witness server, if in use), and which will remain attached to the old primary. repmgr: when executing repmgr standby switchover, ignore nodes which are unreachable and marked as inactive. Previously it would abort if any node was unreachable, as that means it was unable to check if repmgrd is running. However if the node has been marked as inactive in the repmgr metadata, it's reasonable to assume the node is no longer part of the replication cluster and does not need to be checked. repmgr standby switchover and repmgr standby promote: when executing with the --dry-run option, continue checks as far as possible even if errors are encountered. repmgr standby promote: add --siblings-follow (similar to repmgr standby switchover). repmgr daemon status: make output similar to that of repmgr cluster show for consistency and to make it easier to identify nodes not in the expected state. repmgr cluster show: display each node's timeline ID (PostgreSQL 9.6 and later only). repmgr cluster show and repmgr daemon status: show the upstream node name as reported by each individual node - this helps visualise situations where the cluster is in an unexpected state, and provide a better idea of the actual cluster state. For example, if a cluster has divided somehow and a set of nodes are following a new primary, when running either of these commands, repmgr will now show the name of the primary those nodes are actually following, rather than the now outdated node name recorded on the other side of the "split". A warning will also be issued about the unexpected situation. repmgr cluster show and repmgr daemon status: check if a node is attached to its advertised upstream node, and issue a warning if the node is not attached. repmgrd enhancements -------------------- On the primary node, repmgrd is now able to monitor standby connections and, if the number of nodes connected falls below a certain (configurable) value, execute a custom script. This provides an additional method for fencing an isolated primary node, and/or taking other action if one or more standys become disconnected. See section Monitoring standby disconnections on the primary node for more details. In a failover situation, repmgrd nodes on the standbys of the failed primary are now able confirm among themselves that none can still see the primary before continuing with the failover. The repmgr.conf option primary_visibility_consensus must be set to true to enable this functionality. See section Primary visibility consensus for more details. Bug fixes --------- Ensure BDR2-specific functionality cannot be used on BDR3 and later. The BDR support present in repmgr is for specific BDR2 use cases. repmgr: when executing repmgr standby clone in --dry-run mode, ensure provision of the --force option does not result in an existing data directory being modified in any way. repmgr: when executing repmgr primary register with the --force option, if another primary record exists but the associated node is unreachable (or running as a standby), set that node's record to inactive to enable the current node to be registered as a primary. repmgr: when executing repmgr standby clone with the --upstream-conninfo, ensure that application_name is set correctly in primary_conninfo. repmgr: when executing repmgr standby switchover, don't abort if one or more nodes are not reachable and they are marked as inactive. repmgr: canonicalize the data directory path when parsing the configuration file, so the provided path matches the path PostgreSQL reports as its data directory. Otherwise, if e.g. the data directory is configured with a trailing slash, repmgr node check --data-directory-config will return a spurious error. repmgrd: fix memory leak which occurs while the monitored PostgreSQL node is not running. Other ----- The repmgr documentation has been converted to DocBook XML format, as currently used by the main PostgreSQL project. This means it can now be built against any PostgreSQL version from 9.5 (previously it was not possible to build the documentation against PostgreSQL 10 or later), and makes it easier to provide the documentation in other formats such as PDF.
2019-07-12 14:49:26 +02:00
SHA1 (repmgr-4.4.0.tar.gz) = e41a42dc5267e1b5f19d13f43a243eb7bc34d1a3
RMD160 (repmgr-4.4.0.tar.gz) = 0de9f3710a5765fda8e9b54ec599b74889ea5679
SHA512 (repmgr-4.4.0.tar.gz) = 1099420720aefd9b4453b479dd4124de05d93a44654c07b7bc62007d3cdf2f3c33d35748da1b228f1425ac7544fee0b64215aa12afe844d9c01d1d2e23ecbf8d
Size (repmgr-4.4.0.tar.gz) = 416148 bytes
SHA1 (patch-repmgr.c) = e83bdddf1722e4cb5d1861baa33ab8c6930db693
Reference in a new issue Copy permalink