Home / C/C++ / Database

A lightweight replication manager for PostgreSQL (Postgres)

repmgr: Replication Manager for PostgreSQL repmgr is a suite of open-source tools to manage replication and failover within a cluster of PostgreSQL se
Information
Category: C/C++ / Database
Watchers: 147
Star: 1.3k
Fork: 223
Last update: Dec 12, 2021
Resource links
https://repmgr.org/
https://github.com/EnterpriseDB/repmgr

repmgr: Replication Manager for PostgreSQL

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.

The most recent repmgr version (5.2.1) supports all PostgreSQL versions from 9.5 to 13. PostgreSQL 9.4 is also supported, with some restrictions.

repmgr is distributed under the GNU GPL 3 and maintained by EnterpriseDB.

Documentation

The full repmgr documentation is available here:

repmgr documentation

The old README file for repmgr 3.x is available here:

https://github.com/EnterpriseDB/repmgr/blob/REL3_3_STABLE/README.md

Note that the repmgr 3.x series is no longer supported and contains known bugs; please upgrade to the current repmgr version as soon as possible.

Versions

For an overview of repmgr versions and PostgreSQL compatibility, see the repmgr compatibility matrix.

Files

  • CONTRIBUTING.md: details on how to contribute to repmgr
  • COPYRIGHT: Copyright information
  • HISTORY: Summary of changes in each repmgr release
  • LICENSE: GNU GPL3 details

Directories

  • contrib/: additional utilities
  • doc/: DocBook-based documentation files
  • expected/: expected regression test output
  • scripts/: example scripts
  • sql/: regression test input

Support and Assistance

EnterpriseDB provides 24x7 production support for repmgr, including configuration assistance, installation verification and training for running a robust replication cluster. For further details see:

There is a mailing list/forum to discuss contributions or issues:

The IRC channel #repmgr is registered with freenode.

Please report bugs and other issues to:

Further information is available at https://repmgr.org/

We'd love to hear from you about how you use repmgr. Case studies and news are always welcome.

Thanks from the repmgr core team.

  • Ian Barwick
  • Jaime Casanova
  • Abhijit Menon-Sen
  • Simon Riggs
  • Cedric Villemain

Further reading

82 Open More issues
Closed

promote_command is not honoured

I'm running repmgr v4.0.6 on CenOS v7.5, and the promote_command does't seem to be honoured:

$ ps -ef | grep repmgrd
postgres 26638     1  0 16:33 ?        00:00:00 /usr/pgsql-9.6/bin/repmgrd -f /etc/repmgr/9.6/repmgr.conf -p /var/run/repmgr/repmgrd-9.6.pid -d --verbose

$ grep promote_command /etc/repmgr/9.6/repmgr.conf
promote_command='/var/lib/pgsql/scripts/repmgr_promote' # command to execute when promoting a new primary; use something like:
#service_promote_command = ''           # Note: this overrides any value contained in the setting
                                        # "promote_command". This is intended for systems which

If I force a failover, then it runs /usr/pgsql-9.6/bin/pg_ctl -w -D '/var/lib/pgsql/9.6/data' promote, not what's currently in the "promote_command" variable. Here is the /var/log/repmgr.log from a Standby that becomes a Primary:

[2018-07-13 16:33:05] [INFO] connecting to database "host=postgres02 user=repmgr dbname=repmgr connect_timeout=2"
[2018-07-13 16:33:05] [NOTICE] starting monitoring of node "postgres02" (ID: 2)
[2018-07-13 16:33:06] [INFO] monitoring connection to upstream node "postgres01" (node ID: 1)
[2018-07-13 16:33:44] [WARNING] unable to connect to upstream node "postgres01" (node ID: 1)
[2018-07-13 16:33:44] [INFO] checking state of node 1, 1 of 6 attempts
[2018-07-13 16:33:44] [INFO] sleeping 10 seconds until next reconnection attempt


[2018-07-13 16:33:54] [INFO] checking state of node 1, 2 of 6 attempts
[2018-07-13 16:33:54] [INFO] sleeping 10 seconds until next reconnection attempt
[2018-07-13 16:34:04] [INFO] checking state of node 1, 3 of 6 attempts
[2018-07-13 16:34:04] [INFO] sleeping 10 seconds until next reconnection attempt
[2018-07-13 16:34:14] [INFO] checking state of node 1, 4 of 6 attempts
[2018-07-13 16:34:14] [INFO] sleeping 10 seconds until next reconnection attempt
[2018-07-13 16:34:24] [INFO] checking state of node 1, 5 of 6 attempts
[2018-07-13 16:34:24] [INFO] sleeping 10 seconds until next reconnection attempt
[2018-07-13 16:34:34] [INFO] checking state of node 1, 6 of 6 attempts
[2018-07-13 16:34:34] [WARNING] unable to reconnect to node 1 after 6 attempts
[2018-07-13 16:34:34] [NOTICE] this node is the winner, will now promote itself and inform other nodes
[2018-07-13 16:34:34] [NOTICE] redirecting logging output to "/var/log/repmgr/repmgr-9.6.log"

[2018-07-13 16:34:34] [NOTICE] promoting standby to primary
[2018-07-13 16:34:34] [DETAIL] promoting server "postgres02" (ID: 2) using "/usr/pgsql-9.6/bin/pg_ctl  -w -D '/var/lib/pgsql/9.6/data' promote"
[2018-07-13 16:34:37] [NOTICE] STANDBY PROMOTE successful
[2018-07-13 16:34:37] [DETAIL] server "postgres02" (ID: 2) was successfully promoted to primary
[2018-07-13 16:34:42] [NOTICE] 3 followers to notify
[2018-07-13 16:34:42] [NOTICE] notifying node 3 to follow node 2
INFO:  node 3 received notification to follow node 2
[2018-07-13 16:34:42] [NOTICE] notifying node 4 to follow node 2
INFO:  node 4 received notification to follow node 2
[2018-07-13 16:34:42] [NOTICE] notifying node 5 to follow node 2
INFO:  node 5 received notification to follow node 2
[2018-07-13 16:34:42] [INFO] switching to primary monitoring mode
[2018-07-13 16:34:42] [NOTICE] monitoring cluster primary "postgres02" (node ID: 2)

I have tried these, but they didn't help:

  • Stoping and Starting repmgrd on all nodes, to try and force it to re-read the config
  • Force registering all databases again, in case something is kept in the registration
opened Jul 13, 2018 by gclough 23
Closed

Automatic failover doesn't work

I have configured a scheme with one master, one standby and one witness. repmgrd is running on standby and master server (as upstart service).

Example of normal repmgrd initialization log (on standby):

[2014-02-17 14:59:17] [INFO] repmgrd Connecting to database 'host=srv14 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_i
nterval=10 keepalives_count=6'
[2014-02-17 14:59:17] [INFO] repmgrd Connected to database, checking its state
[2014-02-17 14:59:17] [INFO] repmgrd Connecting to primary for cluster 'cluster0'
[2014-02-17 14:59:17] [INFO] finding node list for cluster 'cluster0'
[2014-02-17 14:59:17] [INFO] checking role of cluster node 'host=srv11 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_in
terval=10 keepalives_count=6'
[2014-02-17 14:59:17] [INFO] repmgrd Checking cluster configuration with schema 'repmgr_cluster0'
[2014-02-17 14:59:17] [INFO] repmgrd Checking node 2 in cluster 'cluster0'
[2014-02-17 14:59:17] [INFO] Reloading configuration file and updating repmgr tables
[2014-02-17 14:59:17] [INFO] repmgrd Starting continuous standby node monitoring

Then I killed postgres on master server and got this:

[2014-02-17 15:06:34] [WARNING] Can't stop current query: PQcancel() -- connect() failed: Connection refused

[2014-02-17 15:06:34] [INFO] repmgrd Connecting to database 'host=srv14 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_i
nterval=10 keepalives_count=6'
[2014-02-17 15:06:34] [INFO] repmgrd Connected to database, checking its state
[2014-02-17 15:06:34] [INFO] repmgrd Connecting to primary for cluster 'cluster0'
[2014-02-17 15:06:34] [INFO] finding node list for cluster 'cluster0'
[2014-02-17 15:06:34] [INFO] checking role of cluster node 'host=srv11 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_in
terval=10 keepalives_count=6'
[2014-02-17 15:06:34] [ERROR] Connection to database failed: could not connect to server: Connection refused
        Is the server running on host "srv11" (10.129.235.24) and accepting
        TCP/IP connections on port 5432?

[2014-02-17 15:06:34] [INFO] checking role of cluster node 'host=srv14 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_interval=10 keepalives_count=6'
[2014-02-17 15:06:34] [INFO] repmgrd Connecting to database 'host=srv14 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_interval=10 keepalives_count=6'
[2014-02-17 15:06:34] [INFO] repmgrd Connected to database, checking its state
[2014-02-17 15:06:34] [INFO] repmgrd Connecting to primary for cluster 'cluster0'
[2014-02-17 15:06:34] [INFO] finding node list for cluster 'cluster0'
[2014-02-17 15:06:34] [INFO] checking role of cluster node 'host=srv11 user=repmgr dbname=repmgr connect_timeout=10 keepalives_idle=10 keepalives_interval=10 keepalives_count=6'
[2014-02-17 15:06:34] [ERROR] Connection to database failed: could not connect to server: Connection refused
        Is the server running on host "srv11" (10.129.235.24) and accepting
        TCP/IP connections on port 5432?

Repmgrd can't be initialized and can't start a failover procedure.

I've already configured similar scheme one month ago and it worked. So I think a problem came with the latest changes (commits).

opened Feb 17, 2014 by lexqt 19
Closed

Repmgr 4 and split-brain regardless of quorum

Hi.

Working on my issue https://github.com/paunin/PostDock/issues/97 and try to understand why now in setup with 3 nodes isolated standby becomes promoted anyways even it stays in minority of nodes in the network! (is not an issue in v3)

Details:

>>> Master:
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | user=replication_user password=replication_pass host=pgmaster dbname=replication_db port=5432 connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | user=replication_user password=replication_pass host=pgslave1 dbname=replication_db port=5432 connect_timeout=2
 4  | node4 | standby |   running | node1    | default  | user=replication_user password=replication_pass host=pgslave3 dbname=replication_db port=5432 connect_timeout=2
>>>Standbys:
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | user=replication_user password=replication_pass host=pgmaster dbname=replication_db port=5432 connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | user=replication_user password=replication_pass host=pgslave1 dbname=replication_db port=5432 connect_timeout=2
 4  | node4 | standby |   running | node1    | default  | user=replication_user password=replication_pass host=pgslave3 dbname=replication_db port=5432 connect_timeout=2
 ID | Name  | Role    | Status    | Upstream | Location | Connection string
----+-------+---------+-----------+----------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | node1 | primary | * running |          | default  | user=replication_user password=replication_pass host=pgmaster dbname=replication_db port=5432 connect_timeout=2
 2  | node2 | standby |   running | node1    | default  | user=replication_user password=replication_pass host=pgslave1 dbname=replication_db port=5432 connect_timeout=2
 4  | node4 | standby |   running | node1    | default  | user=replication_user password=replication_pass host=pgslave3 dbname=replication_db port=5432 connect_timeout=2

Trying to isolate one of the standbys: docker-compose exec pgslave3 bash -c "echo 1.1.1.1 pgmaster >> /etc/hosts && echo 1.1.1.2 pgslave1 >> /etc/hosts"

result is that this node becomes master:

pgslave3_1       | [2018-05-29 08:16:45] [INFO] checking state of node 1, 1 of 3 attempts
pgslave3_1       | [2018-05-29 08:16:47] [INFO] sleeping 5 seconds until next reconnection attempt
pgslave3_1       | [2018-05-29 08:16:52] [INFO] checking state of node 1, 2 of 3 attempts
pgslave3_1       | [2018-05-29 08:16:54] [INFO] sleeping 5 seconds until next reconnection attempt
pgslave3_1       | [2018-05-29 08:16:59] [INFO] checking state of node 1, 3 of 3 attempts
pgslave3_1       | [2018-05-29 08:17:01] [WARNING] unable to reconnect to node 1 after 3 attempts
pgslave3_1       | [2018-05-29 08:17:03] [ERROR] connection to database failed:
pgslave3_1       |   timeout expired
pgslave3_1       |
pgslave3_1       | [2018-05-29 08:17:03] [DETAIL] attempted to connect using:
pgslave3_1       |   user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgslave1 port=5432 fallback_application_name=repmgr
pgslave3_1       | [2018-05-29 08:17:03] [NOTICE] this node is the winner, will now promote itself and inform other nodes
pgslave3_1       | DEBUG: connecting to: "user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgslave3 port=5432 fallback_application_name=repmgr"
pgslave3_1       | DEBUG: set_config():
pgslave3_1       |   SET synchronous_commit TO 'local'
pgslave3_1       | INFO: connected to standby, checking its state
pgslave3_1       | DEBUG: get_recovery_type(): SELECT pg_catalog.pg_is_in_recovery()
pgslave3_1       | INFO: searching for primary node
pgslave3_1       | DEBUG: get_primary_connection():
pgslave3_1       |   SELECT node_id, conninfo,          CASE WHEN type = 'primary' THEN 1 ELSE 2 END AS type_priority      FROM repmgr.nodes  WHERE active IS TRUE      AND type != 'witness' ORDER BY active DESC, type_priority, priority, node_id
pgslave3_1       | INFO: checking if node 1 is primary
pgslave3_1       | DEBUG: connecting to: "user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgmaster port=5432 fallback_application_name=repmgr"
pgslave3_1       | ERROR: connection to database failed:
pgslave3_1       |   timeout expired
pgslave3_1       |
pgslave3_1       | DETAIL: attempted to connect using:
pgslave3_1       |   user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgmaster port=5432 fallback_application_name=repmgr
pgslave3_1       | INFO: checking if node 2 is primary
pgslave3_1       | DEBUG: connecting to: "user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgslave1 port=5432 fallback_application_name=repmgr"
pgslave3_1       | ERROR: connection to database failed:
pgslave3_1       |   timeout expired
pgslave3_1       |
pgslave3_1       | DETAIL: attempted to connect using:
pgslave3_1       |   user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgslave1 port=5432 fallback_application_name=repmgr
pgslave3_1       | INFO: checking if node 4 is primary
pgslave3_1       | DEBUG: connecting to: "user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgslave3 port=5432 fallback_application_name=repmgr"
pgslave3_1       | DEBUG: set_config():
pgslave3_1       |   SET synchronous_commit TO 'local'
pgslave3_1       | DEBUG: get_recovery_type(): SELECT pg_catalog.pg_is_in_recovery()
pgslave3_1       | DEBUG: get_node_record():
pgslave3_1       |   SELECT n.node_id, n.type, n.upstream_node_id, n.node_name, n.conninfo, n.repluser, n.slot_name, n.location, n.priority, n.active, n.config_file, '' AS upstream_node_name   FROM repmgr.nodes n  WHERE n.node_id = 4
pgslave3_1       | NOTICE: promoting standby to primary
pgslave3_1       | DETAIL: promoting server "node4" (ID: 4) using "/usr/lib/postgresql/9.6/bin/pg_ctl  -w -D '/var/lib/postgresql/data' promote"
pgslave3_1       | LOG:  received promote request
pgslave3_1       | FATAL:  terminating walreceiver process due to administrator command
pgslave3_1       | LOG:  invalid record length at 0/4001B48: wanted 24, got 0
pgslave3_1       | LOG:  redo done at 0/4001B10
pgslave3_1       | LOG:  last completed transaction was at log time 2018-05-29 08:15:22.737921+00
pgslave3_1       | DEBUG: get_recovery_type(): SELECT pg_catalog.pg_is_in_recovery()
pgslave3_1       | LOG:  selected new timeline ID: 2
pgslave3_1       | LOG:  archive recovery complete
pgslave3_1       | LOG:  MultiXact member wraparound protections are now enabled
pgslave3_1       | LOG:  database system is ready to accept connections
pgslave3_1       | LOG:  autovacuum launcher started
pgslave3_1       | DEBUG: get_recovery_type(): SELECT pg_catalog.pg_is_in_recovery()
pgslave3_1       | INFO: standby promoted to primary after 1 second(s)
pgslave3_1       | DEBUG: setting node 4 as primary and marking existing primary as failed
pgslave3_1       | DEBUG: begin_transaction()
pgslave3_1       | DEBUG: commit_transaction()
pgslave3_1       | NOTICE: STANDBY PROMOTE successful
pgslave3_1       | DETAIL: server "node4" (ID: 4) was successfully promoted to primary
pgslave3_1       | DEBUG: _create_event():
pgslave3_1       |    INSERT INTO repmgr.events (              node_id,              event,              successful,              details        )       VALUES ($1, $2, $3, $4)    RETURNING event_timestamp
pgslave3_1       | DEBUG: _create_event(): Event timestamp is "2018-05-29 08:17:08.19667+00"
pgslave3_1       | DEBUG: _create_event(): command is '/usr/local/bin/cluster/repmgr/events/router.sh %n %e %s "%t" "%d"'
pgslave3_1       | INFO: executing notification command for event "standby_promote"
pgslave3_1       | DETAIL: command is:
pgslave3_1       |   /usr/local/bin/cluster/repmgr/events/router.sh 4 standby_promote 1 "2018-05-29 08:17:08.19667+00" "server \"node4\" (ID:4) was successfully promoted to primary"
pgslave3_1       | [2018-05-29 08:17:08] [INFO] executing notification command for event "repmgrd_failover_promote"
pgslave3_1       | [2018-05-29 08:17:08] [DETAIL] command is:
pgslave3_1       |   /usr/local/bin/cluster/repmgr/events/router.sh 4 repmgrd_failover_promote 1 "2018-05-29 08:17:08.214277+00" "node 4 promoted to primary; old primary 1 marked as failed"
pgslave3_1       | [2018-05-29 08:17:08] [NOTICE] 1 followers to notify
pgslave3_1       | [2018-05-29 08:17:10] [ERROR] connection to database failed:
pgslave3_1       |   timeout expired
pgslave3_1       |
pgslave3_1       | [2018-05-29 08:17:10] [DETAIL] attempted to connect using:
pgslave3_1       |   user=replication_user password=replication_pass connect_timeout=2 dbname=replication_db host=pgslave1 port=5432 fallback_application_name=repmgr
pgslave3_1       | [2018-05-29 08:17:10] [INFO] switching to primary monitoring mode
pgslave3_1       | [2018-05-29 08:17:10] [INFO] executing notification command for event "repmgrd_reload"
pgslave3_1       | [2018-05-29 08:17:10] [DETAIL] command is:
pgslave3_1       |   /usr/local/bin/cluster/repmgr/events/router.sh 4 repmgrd_reload 1 "2018-05-29 08:17:10.229704+00" "monitoring cluster primary \"node4\" (node ID: 4)"

>>>Master:
 ID | Name  | Role    | Status               | Upstream | Location | Connection string
----+-------+---------+----------------------+----------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | node1 | primary | * running            |          | default  | user=replication_user password=replication_pass host=pgmaster dbname=replication_db port=5432 connect_timeout=2
 2  | node2 | standby |   running            | node1    | default  | user=replication_user password=replication_pass host=pgslave1 dbname=replication_db port=5432 connect_timeout=2
 4  | node4 | standby | ! running as primary | node1    | default  | user=replication_user password=replication_pass host=pgslave3 dbname=replication_db port=5432 connect_timeout=2

WARNING: following issues were detected
  - node "node4" (ID: 4) is registered as standby but running as primary
>>> Standbys:
 ID | Name  | Role    | Status               | Upstream | Location | Connection string
----+-------+---------+----------------------+----------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | node1 | primary | * running            |          | default  | user=replication_user password=replication_pass host=pgmaster dbname=replication_db port=5432 connect_timeout=2
 2  | node2 | standby |   running            | node1    | default  | user=replication_user password=replication_pass host=pgslave1 dbname=replication_db port=5432 connect_timeout=2
 4  | node4 | standby | ! running as primary | node1    | default  | user=replication_user password=replication_pass host=pgslave3 dbname=replication_db port=5432 connect_timeout=2

WARNING: following issues were detected
  - node "node4" (ID: 4) is registered as standby but running as primary
 ID | Name  | Role    | Status        | Upstream | Location | Connection string
----+-------+---------+---------------+----------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | node1 | primary | - failed      |          | default  | user=replication_user password=replication_pass host=pgmaster dbname=replication_db port=5432 connect_timeout=2
 2  | node2 | standby | ? unreachable | node1    | default  | user=replication_user password=replication_pass host=pgslave1 dbname=replication_db port=5432 connect_timeout=2
 4  | node4 | primary | * running     |          | default  | user=replication_user password=replication_pass host=pgslave3 dbname=replication_db port=5432 connect_timeout=2

WARNING: following issues were detected
  - when attempting to connect to node "node1" (ID: 1), following error encountered :
"timeout expired"
  - when attempting to connect to node "node2" (ID: 2), following error encountered :
"timeout expired"
  - node "node2" (ID: 2) is registered as an active standby but is unreachable
bug 
opened May 29, 2018 by paunin 15
Closed

Cannot compile without Postgres 9.3+ libraries in pgdg on Ubuntu 14.04

Greetings,

After a lot of head scratching, I've figured out that repmgr 2.0.2 has a dependency against the 9.3+ version of the Postgres libraries. I'm currently restoring a 9.2 cluster before we migrate it to 9.3 and I am unable to compile repmgr when I install the postgresql-server-dev-9.2 package from the official pgdg repo. When I upgrade to the 9.3 version of the same package, it compiled normally without issue. Here is the stack trace of the make error so you can see the int definitions it is depending upon.

STDERR output:

In file included from repmgr.h:25:0,
                 from dbutils.c:24:
       /usr/include/postgresql/libpq-fe.h:547:1: error: unknown type name 'pg_int64'
        extern pg_int64 lo_lseek64(PGconn *conn, int fd, pg_int64 offset, int whence);
        ^
       /usr/include/postgresql/libpq-fe.h:547:50: error: unknown type name 'pg_int64'
        extern pg_int64 lo_lseek64(PGconn *conn, int fd, pg_int64 offset, int whence);
                                                  ^
       /usr/include/postgresql/libpq-fe.h:551:1: error: unknown type name 'pg_int64'
        extern pg_int64 lo_tell64(PGconn *conn, int fd);
        ^
       /usr/include/postgresql/libpq-fe.h:553:48: error: unknown type name 'pg_int64'
        extern int lo_truncate64(PGconn *conn, int fd, pg_int64 len);
                                                ^
       make: *** [dbutils.o] Error 1

This could be a change outside of repmgr in the included pg libs so I am not sure what could be done to resolve this to make it compatible with the previous versions. Googling around, it looks like people have had similar compile problems in other C libs, but it's not conclusive on which version this caused a break.

opened Feb 18, 2015 by martinisoft 15
Closed

Connections from repmgrd never close?

We have a cluster two Postgres servers, using streaming replication.

We use repmgrd to monitor the replication lag. Everything is working Ok, in the log of the master server, we can see repmgrd connecting every three seconds. But there is no log entry for disconnection.

$ tail -f /var/lib/pgsql/9.2/data/pg_log/postgresql-Mon.log | grep 192.168.70 2014-03-17 11:26:07 WET [28404]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=192.168.70.1 port=46885 2014-03-17 11:26:10 WET [28410]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=192.168.70.1 port=46886 2014-03-17 11:26:13 WET [28414]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=192.168.70.1 port=46887 2014-03-17 11:26:16 WET [28454]: [1-1] user=[unknown],db=[unknown] LOG: connection received: host=192.168.70.1 port=46888 . .

We can see disconnection entries for other hosts (log_disconnections = on).

We are using the last stable version, $ /usr/pgsql-9.2/bin/repmgr --version repmgr 1.2.0 (PostgreSQL 9.2beta2)

opened Mar 17, 2014 by ferfebles 15
Closed

Demoted primary does not start after "standby switchover" (repmgr 4.0.2)

Since upgrading to 4.x 'repmgr standby switchover' causes promotion of the standby to primary but then trashes the existing primary and does not inform other standbys of the change. #349 supposedly fixed this in repmgr 4.0.2 but sadly I'm still experiencing the same problem....

Before switchover:

 ID | Name | Role    | Status    | Upstream  | Location | Connection string                                                                                              
----+--------------------------+---------+-----------+--------------------------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | pg01 | primary | * running |           | default  | host=pg01 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5
 2  | pg02 | standby |   running | pg01      | default  | host=pg02 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5
 3  | pg03 | standby |   running | pg01      | default  | host=pg03 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5

On pg02 run ( full output to be attached separately ):

# repmgr standby switchover
... 
ERROR: unable to reestablish connection to remote node "pg01"
NOTICE: switchover was successful
DETAIL: node "pg02" is now primary
NOTICE: STANDBY SWITCHOVER is complete

After switchover:

Despite the 'ERROR' repmgr claims success, but 'repmgr cluster show' tells a different story:

[email protected]:~# su postgres -c "repmgr cluster show"

 ID | Name | Role    | Status        | Upstream | Location | Connection string                                                                                              
----+--------------------------+---------+---------------+--------------------------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | pg01 | primary | - failed      |          | default  | host=pg01 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5
 2  | pg02 | primary | * running     |          | default  | host=pg02 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5
 3  | pg03 | standby | ? unreachable | pg01     | default  | host=pg03 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5

WARNING: following issues were detected
  node "pg03" (ID: 3) is registered as an active standby but is unreachable

Extremely odd that it should think Node 3 is unreachable. This node is just a bystander here. And why is the pg01 'failed' status not listed as a detected issue?

And Node3's view of the world is also skewed:

[email protected]:~# su postgres -c "repmgr cluster show"
 ID | Name | Role    | Status               | Upstream | Location | Connection string                                                                                              
----+--------------------------+---------+----------------------+--------------------------+----------+-----------------------------------------------------------------------------------------------------------------
 1  | pg01 | standby | ! running as primary | pg02     | default  | host=pg01 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5
 2  | pg02 | primary | ? unreachable        |          | default  | host=pg02 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5
 3  | pg03 | standby |   running            | pg02     | default  | host=pg03 port=5432 user=replicator dbname=repmgr sslmode=require connect_timeout=5

WARNING: following issues were detected
  node "pg01" (ID: 1) is registered as standby but running as primary
  node "pg02" (ID: 2) is registered as an active primary but is unreachable

HOWEVER - After a few minutes, Node 3 automatically gave up on node 2 and started following Node 1 - seemingly through the failover election mechanism.

This bug is more critical in our environment that it might usually be as it is blocking us from upgrading repmgr from 3.x to 4.x in production... Because of the forced upgrade to 4.x when 3.x was purged from the official Postgres APT repos, we find ourselves unable to run puppet on our Postgres servers in prod because it will modify the repmgr config to the version 4.x format (i.e. breaking version 3) and we cannot upgrade repmgr to 4.x because it's still got unacceptable bugs.

Workaround

At present out only method for dealing with this is delete the postgres data files on the failed primary and re-initialise it using 'repmgr standby clone' and re-registering it.

pg2_swithover_failure-Redacted.txt

opened Jan 30, 2018 by JonathanDIT 13
Open

WAL replay is paused on nodes with WAL replay pending

Here issue is that after doing PITR for specific time wal replay resume at all node. For primary when I run pg_wal_replay_resume() that issue gone.

When I clone from primary to make standby it cloning and start standby node successfully but wal replay resume with wal replay pending. I am not sure where is the issue.

If I run wal_replay_resume() at standby in that case standby.signal gone. But as a standby node standby.signal should be there. Later I thought i need to wal replay, as like primary. Where there was a barman_wal folder which stored required wal file to replay. Next I copy that barman_wal folder all files and directory to standby node and also create recovery.signal file there and restart that standby node but server run successfully but now showing "node "node2" (ID: 2) is not attached to its upstream node "node1" (ID: 1)"

I am not sure how to do PITR for 3 node cluster where 1 is primary and other two node is standby. For single node it is working well.

`[[email protected] ~]$ repmgr cluster show ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string ----+---------+---------+-----------+----------+----------+----------+----------+-------------------------------------------------------------------------- 1 | node1 | primary | * running | | default | 100 | 9 | host=10.16.71.78 user=repmgr dbname=repmgr connect_timeout=2 port=5432 2 | node2 | standby | running | node1 | default | 100 | 9 | host=10.16.71.79 user=repmgr dbname=repmgr connect_timeout=2 port=5432 3 | node3 | standby | running | node1 | default | 100 | 9 | host=10.16.71.80 user=repmgr dbname=repmgr connect_timeout=2 port=5432 4 | Witness | witness | * running | node1 | default | 0 | n/a | host=10.16.71.77 user=repmgr dbname=repmgr connect_timeout=2 port=5432

WARNING: following issues were detected

  • WAL replay is paused on node "node2" (ID: 2) with WAL replay pending; this node cannot be manually promoted until WAL replay is resumed
  • WAL replay is paused on node "node3" (ID: 3) with WAL replay pending; this node cannot be manually promoted until WAL replay is resumed

If anyone know the issue please let me know.`

@ibarwick need your help on this.

opened Jun 4, 2022 by wasiualhasib 0
Open

repmgr showing wrong node status (repmgr14)

When I did switchover from node1 to node 2 it switch over successfully as like below. Here issue is that node1 is not attached with it.

[[email protected] ~]$ repmgr cluster show
 ID | Name  | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
----+-------+---------+-----------+----------+----------+----------+----------+--------------------------------------------------------------------------
 1  | node1 | standby |   running |          | default  | 100      | 4        | host=192.168.43.21 user=repmgr dbname=repmgr connect_timeout=2 port=5434
 2  | node2 | primary | * running |          | default  | 100      | 5        | host=192.168.43.22 user=repmgr dbname=repmgr connect_timeout=2 port=5434
 3  | node3 | standby |   running | node2    | default  | 100      | 5        | host=192.168.43.23 user=repmgr dbname=repmgr connect_timeout=2 port=5434

After checking replication slot status i found replication slot disable for node1 like below:

postgres=# select * from pg_replication_slots ;
   slot_name   | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size | two_phase
---------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------+-----------
 repmgr_slot_3 |        | physical  |        |          | f         | t      |      34402 |      |              | 3/52035A10  |                     | reserved   |               | f
 repmgr_slot_1 |        | physical  |        |          | f         | f      |            |      |              | 3/520000D0  |                     | reserved   |               | f

But when I checked from database I found below node status which is differ from above information. At backend it still showing node1 is primary. At repmgr14 I found this new issue. Is it bug or something else.

[[email protected] ~]$ psql -h 192.168.43.21 -d repmgr -U repmgr  -p 5434
psql (14.2)
Type "help" for help.

repmgr=# select * from nodes;
 node_id | upstream_node_id | active | node_name |  type   | location | priority |                                 conninfo                                 | repluser |   slot_name   |        config_file
---------+------------------+--------+-----------+---------+----------+----------+--------------------------------------------------------------------------+----------+---------------+----------------------------
       1 |                  | t      | node1     | primary | default  |      100 | host=192.168.43.21 user=repmgr dbname=repmgr connect_timeout=2 port=5434 | repmgr   | repmgr_slot_1 | /etc/repmgr/14/repmgr.conf
       2 |                1 | t      | node2     | standby | default  |      100 | host=192.168.43.22 user=repmgr dbname=repmgr connect_timeout=2 port=5434 | repmgr   | repmgr_slot_2 | /etc/repmgr/14/repmgr.conf
       3 |                1 | t      | node3     | standby | default  |      100 | host=192.168.43.23 user=repmgr dbname=repmgr connect_timeout=2 port=5434 | repmgr   | repmgr_slot_3 | /etc/repmgr/14/repmgr.conf
(3 rows)

To solve this I recover from previous backup and remove repmgr database. Next I create repmgr database again with extension. Given search path and repmgr role. As per 2ndquadrant
2ndquadrant document. Later try again with failover on node1 but result same. Here backend node status(select * from nodes) not macthed with frontend node status (repmgr node show);

Other necessary Information given:

OS: Centos 8.5 DB: PostgreSQL 14.2 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit repmgr:14 barman: 2.17 Barman by EnterpriseDB (www.enterprisedb.com) Note: Recently I upgrade current PostgreSQL database 13 to 14.

If need other information please let me know. Looking for solution from experts as early as possible. Thanks in advance @ibarwick

opened Apr 27, 2022 by wasiualhasib 1
Open

repmgr 5.2 -> 5.3 extension upgrade fails (could not find function "repmgr_set_local_node_id")

Hi,

I have several postgresql clusters running postgres version 10, 12, 13 on Rocky Linux 8. Postgres is installed from postgres yum repo, and repmgr from 2ndquadrant's repo.

I'm attempting an upgrade from repmgr 5.2.1 to 5.3.1, using the following steps

  1. stopping & disabling repmgrd
  2. yum upgrade of the repmgr package from 5.2.1 to 5.3.1
  3. systemctl daemon-reload
  4. (no restart of postgres here since release notes does not state it's required, unlike 5.1 upgrade)
  5. ALTER EXTENSION repmgr UPDATE; The ALTER EXTENSION fails with;
Cannot execute SQL 'ALTER EXTENSION repmgr UPDATE;' None: could not find function "repmgr_set_local_node_id" in file "/usr/pgsql-13/lib/repmgr.so"

Restarting postgres and attempting ALTER EXTENSION repmgr UPDATE; again succeeds.

Is a restart supposed to be required when upgrading 5.2 to 5.3? I'm guessing this could be the culprit;

repmgrd: rename internal shared library functions to minimize the risk of clashes with other shared libraries. This does not affect user-facing SQL functions. However an upgrade of the installed extension version is required.

opened Apr 21, 2022 by MannerMan 1
Open

LOG: could not receive data from client: Connection reset by peer

Hello

Sometimes we hit this kind of issue when launching "repmgr cluster show" by an automatic script which is monitoring the cluster state do you have an idea what's wrong because the script doesn't get the status of cluster and returns an error ?

2022-03-25` 20:45:11 CET [57351]: [1-1] user=repmgr,db=repmgr,client=x.x.x.138 LOG: could not receive data from client: Connection reset by peer

2022-03-25 21:12:43 CET [37218]: [1-1] user=repmgr,db=repmgr,client=x.x.x.138 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37220]: [1-1] user=repmgr,db=repmgr,client=x.x.x.137 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37223]: [1-1] user=repmgr,db=repmgr,client=x.x.x.138 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37224]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37226]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37227]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37228]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37229]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37230]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37232]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37233]: [1-1] user=repmgr,db=repmgr,client=x.x.x.139 LOG: could not receive data from client: Connection reset by peer 2022-03-25 21:12:43 CET [37235]: [1-1] user=repmgr,db=repmgr,client=x.x.x.145 LOG: could not receive data from client: Connection reset by peer ...

repmgr 5.3 PostgreSQL 10.19 There is a pgbouncer and an haproxy too,

here is the output of cluster show : ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string
-------+-----------------+---------+-----------+-----------------+----------+----------+----------+--------------------------------------------------------------------------------------------------------------------------- 11101 | pgsql-a2s11-101 | primary | * running | | GE | 100 | 142 | host=x.x.x.137 port=5432 application_name=pgsql-a2s11-101 user=repmgr dbname=repmgr connect_timeout=2 sslmode=disable 12102 | pgsql-a2s12-102 | standby | running | pgsql-a2s11-101 | GE | 100 | 142 | host=x.x.x.138 port=5432 application_name=pgsql-a2s12-102 user=repmgr dbname=repmgr connect_timeout=2 sslmode=disable 21101 | pgsql-a2s21-101 | standby | running | pgsql-a2s12-102 | BE | 0 | 142 | host=x.x.x.139 port=5432 application_name=pgsql-a2s21-101 user=repmgr dbname=repmgr connect_timeout=2 sslmode=disable 22102 | pgsql-a2s22-102 | standby | running | pgsql-a2s21-101 | BE | 0 | 142 | host=x.x.x.145 port=5432 application_name=pgsql-a2s22-102 user=repmgr dbname=repmgr connect_timeout=2 sslmode=disable

opened Mar 28, 2022 by lohengrin1870 0
Open

Incorrect random value for repmgr.get_upstream_node_id() on witness node

Hi,

We are using repmgr 5.2.1 and observing that the function repmgr.get_upstream_node_id() is always producing random values even though no change is cluster state.

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:24:59.903786+00 |     101 | witness |                1 |                    1
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:01.733538+00 |     101 | witness |                1 |                    2
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:02.745435+00 |     101 | witness |                1 |                    2
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:03.851729+00 |     101 | witness |                1 |                    2
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:04.751673+00 |     101 | witness |                1 |                    1
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:05.940818+00 |     101 | witness |                1 |                    2
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
      current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:06.78803+00 |     101 | witness |                1 |                    1
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:07.560983+00 |     101 | witness |                1 |                    2
(1 row)

pgwitness=# select CURRENT_TIMESTAMP, node_id, type, upstream_node_id, get_upstream_node_id() from nodes where node_id = get_local_node_id();
       current_timestamp       | node_id |  type   | upstream_node_id | get_upstream_node_id
-------------------------------+---------+---------+------------------+----------------------
 2022-03-10 02:25:08.370091+00 |     101 | witness |                1 |                    1
(1 row)

Thanks, chvsunny.

opened Mar 9, 2022 by chvsunny 7
Open

Password less authentication for repmgrd process

Hi, I'll be looking for secure authentication for Postgres where i should not use .pgpass or trust authentication method.

I have come across a issue during Standby switchover, where the switchover command internally executing "ssh -o Batchmode=yes -p 222 master /usr/pgsql-11/bin/repmgr -f repmgr_5432.conf node check --db-connection"

Primary Server = master standby server = secondary

[email protected]:~ $ ./switchover
NOTICE: using provided configuration file "repmgr_5432.conf"
NOTICE: executing switchover on node "master" (ID: 2)
INFO: searching for primary node
INFO: checking if node 1 is primary
INFO: current primary node is 1
INFO: SSH connection to host "master" succeeded
DETAIL: an error was encountered when attempting to connect to PostgreSQL on node "master" (ID: 1)
HINT: diagnose with:
  ssh -o Batchmode=yes -p 222 master /usr/pgsql-11/bin/repmgr -f repmgr_5432.conf node check --db-connection

[email protected]:~ $ ssh -o Batchmode=yes -p 222 master /usr/pgsql-11/bin/repmgr -f repmgr_5432.conf node check --db-connection
ERROR: connection to database failed
DETAIL: 
fe_sendauth: no password supplied

CRITICAL (connection parameters used: user=repmgr passfile=/var/lib/pgsql/.pgpass connect_timeout=3 dbname=repmgr host=master port=5321 options=-csearch_path= application_name=repmgrd fallback_application_name=repmgr sslmode=require sslcompression=0 krbsrvname=postgres target_session_attrs=any)

Details: i'll be using a script to fetch password from remote server instead of storing in the local node, i.e no .pgpass or trust method. if i do export PGPASSWORD="xxx" and run the command(/usr/pgsql-11/bin/repmgr -f repmgr_5432.conf node check --db-connection) manually in the primary, its perfectly working.

Requirements:

  1. is there any way we can fetch password first or provisioning of fetching password fetch in repmgr and check connection to the database. i.e Example: if i do switchover, repmgr does ssh to the primary server, fetch password, check health connection...?,

  2. Do we have possibility of using or integrating some third party password fetch tools(without using .pgpass or trust method, Currently i am doing export PGPASSWORD=xxx and executing repmgrd everytime) and allowing repmgrd to connect to the database for monitoring.

Thank you Very much for the support.

Siva

question 
opened Mar 8, 2022 by siva-postgres 3

v5.3.2(May 25, 2022)

repmgr 5.3.2 has been released; for details see the release notes:

https://repmgr.org/docs/current/release-5.3.2.html

v5.3.1(Feb 15, 2022)

repmgr 5.3.1 has been released; for details see the release notes:

https://repmgr.org/docs/current/release-5.3.1.html

v5.3.0(Oct 19, 2021)

repmgr 5.3.0 has been released; for details see the release notes:

https://repmgr.org/docs/current/release-5.3.0.html

v5.2.1(Dec 10, 2020)

repmgr 5.2.1 has been released; for details see the release notes:

https://repmgr.org/docs/current/release-5.2.1.html

v5.2.0(Oct 22, 2020)

repmgr 5.2.0 has been released; for details see the release notes:

https://repmgr.org/docs/current/release-5.2.0.html

v5.1.0(Apr 12, 2020)

repmgr 5.1.0 has been released; for details see the release notes:

https://repmgr.org/docs/current/release-5.1.0.html

Contents

    signal18 Signal 18 repman - Replication Manager for MySQL / MariaDB / Percona Server
    paunin PostDock - Postgres & Docker - Postgres streaming replication cluster for any docker environment
    2ndQuadrant Logical Replication extension for PostgreSQL 13, 12, 11, 10, 9.6, 9.5, 9.4 (Postgres), providing much faster replication than Slony, Bucardo or Londiste, as well as cross-version upgrades.
    sfackler Rust-Postgres — A native PostgreSQL client
    aiven PostgreSQL replication monitoring and failover daemon
    zalando Postgres operator creates and manages PostgreSQL clusters running in Kubernetes
    alaisi Asynchronous PostgreSQL Java driver
    sorintlab PostgreSQL cloud native High Availability and more.
    kingluo Enhanced PostgreSQL logical replication
    reactive-tech Kubegres is a Kubernetes operator allowing to create a cluster of PostgreSql instances and manage databases replication, failover and backup.
    PgOutput2Json The PgOutput2Json library for .NET Core uses PostgreSQL logical replication to push changes, as JSON messages, from database tables to a .NET Core application, or a message broker, such as RabbitMq (implemented) or Redis (todo).
    citusdata Basic implementation of Paxos and Paxos-based table replication for a cluster of PostgreSQL nodes
    2tvenom Golang MySql binary log replication listener
    julien-duponchelle Pure Python Implementation of MySQL replication protocol build on top of PyMYSQL
    EnterpriseDB PostgreSQL foreign data wrapper for MongoDB
    diogob Simple PostgreSQL's COPY command support in ActiveRecord models
    citusdata Postgres extension and service for automated failover and high-availability
    oelmekki Easy postgres codebase injection - aka postgres non data live reload
    postgres Mirror of the official PostgreSQL GIT repository. Note that this is just a *mirror* - we don't work with pull requests on github. To contribute, please see https://wiki.postgresql.org/wiki/Submitting_a_Patch
    the4thdoctor MySQL to PostgreSQL replica system
    PostgresApp The easiest way to get started with PostgreSQL on the Mac
    Share this repo

    Related Repos


    Database
    2.2k
    A hierarchical note taking application, featuring rich text and syntax highlighting, stori...
    giuspen CherryTree A hierarchical note taking application, featuring rich text and syntax highlighting, storing data in a single XML or SQLite file. The proje
     
    Database
    216
    Modern cryptography for PostgreSQL using libsodium.
    michelp pgsodium pgsodium is an encryption library extension for PostgreSQL using the libsodium library for high level cryptographic algorithms. pgsodium can
     
    Database
    10
    Full-stack to-do app to try out SvelteKit. Minimal with SQLite database + HTTP basic auth
    Ameobea SvelteKit To-Do List This application was created to accompany a blog post about my experience trying out SvelteKit for the first time. It is deployed
     
    Database
    8
    Copy a Postgres database to a target Postgres server (pg_dump | pg_restore on steroids)
    dimitri pgcopydb pgcopydb is a tool that automates running pg_dump | pg_restore between two running Postgres servers. To make a copy of a database to another
     
    Database
    3
    Setup ClickHouse cluster with replication using `clickhouse-keeper`
    mr-karan ClickHouse Keeper Example An example of running a local ClickHouse cluster using clickhouse-keeper for replication. Config examples accompanying the b
     
    Database
    91
    Trilogy is a client library for MySQL-compatible database servers, designed for performanc...
    github Trilogy Trilogy is a client library for MySQL-compatible database servers, designed for performance, flexibility, and ease of embedding. It's currentl
     
    Database
    8
    Data Redistribution on MySQL
    FlashSQL MySQL Data Redistribution Motivation While B-Tree is a ubiquitous index structure used in managing data, it is well known for its low space utilizatio
     
    Database
    1.3k
    A lightweight replication manager for PostgreSQL (Postgres)
    EnterpriseDB repmgr: Replication Manager for PostgreSQL repmgr is a suite of open-source tools to manage replication and failover within a cluster of PostgreSQL se
     
    Database
    295
    PostgreSQL Automatic Failover: High-Availibility for Postgres, based on Pacemaker and Coro...
    ClusterLabs PostgreSQL Automatic Failover High-Availibility for Postgres, based on industry references Pacemaker and Corosync. Description Pacemaker is nowadays t
     
    Database
    169
    Advanced WAL File Management Tools for PostgreSQL
    omniti-labs OmniPITR OVERVIEW OmniPITR is a set of scripts to ease setting up WAL replication, and making hot backups from both Master and Slave systems. This set
     
    Database
    4.9k
    Greenplum Database - Massively Parallel PostgreSQL for Analytics.
    greenplum-db Greenplum Database - Massively Parallel PostgreSQL for Analytics. An open-source massively parallel data platform for analytics, machine learning and AI.
     
    Database
    149
    Monitor PostgreSQL with Zabbix
    zabbix-tools libzbxpgsql This project provides comprehensive monitoring of PostgreSQL servers using a natively compiled Zabbix agent module, written in C. A precon
     
    Database
    542
    Logical Replication extension for PostgreSQL 13, 12, 11, 10, 9.6, 9.5, 9.4 (Postgres), pro...
    2ndQuadrant pglogical 2 The pglogical 2 extension provides logical streaming replication for PostgreSQL, using a publish/subscribe model. It is based on technolog
     
    Database
    1.2k
    Partition management extension for PostgreSQL
    pgpartman PG Partition Manager pg_partman is an extension to create and manage both time-based and serial-based table partition sets. Native partitioning in Pos
     
    Database
    296
    Basic implementation of Paxos and Paxos-based table replication for a cluster of PostgreSQ...
    citusdata pg_paxos This PostgreSQL extension provides a basic implementation of the Paxos algorithm in PL/pgSQL and basic table replication through Paxos. Warni