I have an environment where the old DBA used the repmgr. And now I need to add a second replica to use as a "dump server". But my question is regarding using the native mode of PostgreSQL via stream replication. When I perform base_backup and a second replica is added, can it cause any side effects on repmgr? I've never used repmgr in prod and I just want to make sure that a simple replica can ruin the whole cluster.

I use repmgr to provide failover to my PostgreSQL cluster. If I change a server-specific parameter in the repmgr.conf file for one of my standbys, how do I get repmgr to recognize the changed value? For example, if I wanted to change the priority of one of the nodes. I tried stopping & retarting repmgrd on the affected server. Then I tried unregistering the server from the cluster & re-registering the node. I tried registering the node with the force option. I tried stopping repmgrd for all my servers & then stopping & restarting PostgreSQL on the Primary & then restarting the repmgrd for all the servers. Nothing works - the cluster show command still shows the old value. I've searched on the internet, but I can't find any information on how to reload the repmgr configuration. Any help would be appreciated. Thanks, Karin

I am new to Postgresql and Pgpool II setup. I have configured the Postgresql HA/Load balancing using Pgpool II and Repmgr. I have followed the link to do the setup. The setup consist of 3 nodes and verison of Application and OS is as mentioned below: **OS version** => CentOS 6.8 (On all the 3 nodes) **Pgpool node** => 192.168.0.4 **Postgresql Nodes**: **node1** (Master in read-write mode) => 192.168.0.6 **node2** (Standby node in read only mode) => 192.168.0.7 **Pgpool II version** => pgpool-II version 3.5.0 (ekieboshi). **Postgresql Version** => PostgreSQL 9.4.8 **Repmgr Version** => repmgr 3.1.3 (PostgreSQL 9.4.8) **I have configured the Pgpool in Master-Slave mode using Streaming replication.** The setup is as shown in the below image: When I bring down the Master node(192.168.0.6), the automatic failover happens successfully and the Slave node(192.168.0.7) becomes the new Master node. After failover, I have to recover the failed node(192.168.0.6) manually and sync it with the new Master node. Then register the node(192.168.0.6) as a new Standby node. I want to automate the Recovery process of the failed node and add it to the cluster back. The **pgpool.conf** file on the Pgpool node(192.168.0.4) contains parameter **recovery_1st_stage_command**. I have set the parameter **recovery_1st_stage_command = 'basebackup.sh'**. I have placed the script 'basebackup.sh' file on **both** the Postgresql nodes(192.168.0.6, 192.168.0.7) under the data directory **'/var/lib/pgsql/9.4/data'**. Also I have placed the script **'pgpool_remote_start'** on both the Postgresql nodes(192.168.0.6, 192.168.0.7) under the directory '/var/lib/pgsql/9.4/data'. Also created the pgpool extension **"pgpool_recovery and pgpool_adm"** on both the database node. After the failover is completed, the 'basebackup.sh' is not executed automatically. I have to run the command **'pcp_recovey_node'** manually on the **Pgpool node(192.168.0.4)** to recover the failed node(192.168.0.6). How can I automate the execution of **pcp_recovery_node** command on the Pgpool node with out any manual intervention. Scripts used by me as follows: basebackup.sh script ------------- #!/bin/bash # first stage recovery # $1 datadir # $2 desthost # $3 destdir #as I'm using repmgr it's not necessary for me to know datadir(master) $1 RECOVERY_NODE=$2 CLUSTER_PATH=$3 #repmgr needs to know the master's ip MASTERNODE=/sbin/ifconfig eth0 | grep inet | awk '{print $2}' | sed 's/addr://' cmd1=ssh postgres@$RECOVERY_NODE "repmgr -D $CLUSTER_PATH --force standby clone $MASTERNODE" echo $cmd1 ## pgpool_remote_start script #! /bin/sh if [ $# -ne 2 ] then echo "pgpool_remote_start remote_host remote_datadir" exit 1 fi DEST=$1 DESTDIR=$2 PGCTL=/usr/pgsql-9.4/bin/pg_ctl ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null /dev/null 1>/dev/null &1 | tee -a /tmp/pgpool_failover.log Help me with the procedure to automate the recovery of the failed node. Also let me know, for failover is it compulsory to use repmgr or we can do it without repmgr. Also specify any other method for failover without using Repmgr, its advantages and disadvantages over Repmgr.

I'm trying to setup postgre with repmgr and here is the rsult The scenario is, 1. i tried to spinup 1 primary and 2 standby. 2. then i stop the primary so the postgres-2 got promoted. 3. Unfortunately the postgres-3 got disconnected due to some reason but here is the error log It looks like it was able to connect but the postgres restared and didn't come back. 4. I spin up another standby but the master it was pointing is the old one which is postgres-1 That might be the reason why it is saying !running and still primary even if the actual primary is postgres-2. My question is how can i make other standby not disconnected every time i promoted (automatically due to failure etc.) a new primary? here is my repmgr.conf

NET_IF=netstat -rn | awk '/^0.0.0.0/ {thif=substr($0,74,10); print thif;} /^default.*UG/ {thif=substr($0,65,10); print thif;}'
NET_IP=ifconfig ${NET_IF} | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1' 

HOSTNAME='postgres-'${my_node}

cat /etc/repmgr.conf
	node_id=${my_node}
	node_name=$HOSTNAME
	conninfo='host=${NET_IP} user=repmgr password=repmgr dbname=repmgr connect_timeout=2'
	data_directory='${PGDATA}'

	log_level=INFO
	log_facility=STDERR
	log_status_interval=300
	
	pg_bindir='/usr/lib/postgresql/10/bin'
	use_replication_slots=1
	
	failover=automatic
	promote_command='repmgr standby promote'
	follow_command='repmgr standby follow -W'
EOF

Also, I'm running using docker extending the official postgres docker image

FROM postgres:10

RUN echo "deb http://apt.postgresql.org/pub/repos/apt/  stretch-pgdg main 10" \
          >> /etc/apt/sources.list.d/pgdg.list

# RUN ln -s /home/postgres/repmgr.conf /etc/repmgr.conf

RUN apt-get update && apt-get install wget -y
RUN apt-get install net-tools -y
RUN apt-get update; apt-get install -y git make postgresql-server-dev-10 libpq-dev postgresql-10-repmgr repmgr-common

#RUN wget -c https://repmgr.org/download/repmgr-5.1.tar.gz  -O - | tar -xz

RUN touch /etc/repmgr.conf; \
    chown postgres:postgres /etc/repmgr.conf

ENV PRIMARY_NAME=localhost
ENV REPMGR_USER=repmgr
ENV REPMGR_DB=repmgr
ENV REPMGR_PASSWORD=repmgr

COPY postgresql.replication.conf /tmp/postgresql.replication.conf

COPY scripts/*.sh /docker-entrypoint-initdb.d/

Lastly, here is how i check if should be register as primary or standby

PGHOST=${PRIMARY_NAME}

installed=$(psql -qAt -h ${PGHOST} repmgr -c "SELECT 1 FROM pg_tables WHERE tablename='nodes'")

if [ "${installed}" != "1" ]; then
    echo "Registering as PRIMARY SERVER"
    repmgr primary register
else
    my_node=$(grep node_id /etc/repmgr.conf | cut -d= -f 2)
    is_reg=$(psql -qAt -h ${PGHOST} repmgr -c "SELECT 1 FROM repmgr.nodes WHERE node_id=${my_node}")

    if [ "${is_reg}" != "1" ] && [ ${my_node} -gt 1 ]; then
        echo "Registering as STANDBY SERVER"

        pg_ctl -D ${PGDATA} stop -m fast
        rm -Rf ${PGDATA}/*
        repmgr -h ${PRIMARY_NAME} -d repmgr standby clone --fast-checkpoint
        pg_ctl -D ${PGDATA} start &
        sleep 1
        repmgr -h ${PRIMARY_NAME} -d repmgr standby register    
    fi
fi

here is my update for the postgres.conf

sed -i "s/#*\(shared_preload_libraries\).*/\1='repmgr'/;" ${PGDATA}/postgresql.conf
sed -i "s/#port = 5432/port = 5432/g" ${PGDATA}/postgresql.conf
sed -i "s/#max_wal_senders/max_wal_senders/g"  ${PGDATA}/postgresql.conf
sed -i "s/#wal_level/wal_level/g"  ${PGDATA}/postgresql.conf
sed -i "s/#max_replication_slots/max_replication_slots/g"  ${PGDATA}/postgresql.conf
sed -i "s/#hot_standby/hot_standby/g"  ${PGDATA}/postgresql.conf

sed -i "s/#archive_mode = off/archive_mode = on/g"  ${PGDATA}/postgresql.conf

echo "archive_command = '/bin/true'" >>  ${PGDATA}/postgresql.conf

I'm using postgres:10 and repmgr-5.0 hope someone could help me on this. Thanks,

I've setup a PostgreSQL v16.6 HA Cluster using repmgr. Ensured replication is working between primary and standby nodes. Then I tried simulating a failover event by shutting down PostgreSQL service at the primary node and saw cluster switched to standby node. However, the application using this cluster reported the database was down. Apparently, the app needs to use kind of a listener/monitor object connection URL instead of a direct primary node IP address to connect to DB. This can be an equivalent of MS SQL Server Availability Group Listener . However, I don't seem to find the name of this object/component in PostgreSQL world. In PostgreSQL it seems like there is more than one way to setup HA replication cluster between nodes: repmgr, pgPool-II, probably some others. So it is a bit confusing. Could you please advise what component/package to use which would make PostgreSQL Cluster failovers transparent to the apps? And what the connection URL should be for apps in this case to connect to the PG SQL Cluster and not care which node is currently the primary one?

I maked the configuration of the failover system based in Repmgr , but i don't haved success to promote the Standby Cluster to Master Cluster in case of failover. Following my configurations, this process shoulded happens automatically, but does not works. Additional Information: - Debian 9.2, PostgresSQL 9.6, Repmgr 3.3 - IP Master (host1): 10.0.0.1, IP Standby (host2): 10.0.0.2 - Contents included in /etc/postgresql/9.6/main/postgresql.conf, the same for all wal_keep_segments = 5000 hot_standby = on archive_mode = on listen_addresses = '*' max_wal_senders = 18 wal_level = hot_standby shared_preload_libraries = 'repmgr_funcs' archive_command = 'cd .' - Contents of /etc/postgresql/9.6/main/pg_hba.conf ####Master local all postgres peer local all all peer host all all 127.0.0.1/32 trust host all all ::1/128 md5 host repmgr repmgr 10.0.0.2/32 trust host replication repmgr 10.0.0.2/32 trust ####Standby local all postgres peer local all all peer host all all 127.0.0.1/32 trust host all all ::1/128 md5 host repmgr repmgr 10.0.0.1/32 trust host replication repmgr 10.0.0.1/32 trust - Contents of /etc/repmgr.conf ####Master cluster=cluster node=1 node_name=host1 conninfo='host=host1 user=repmgr dbname=repmgr connect_timeout=2' failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file' follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file' logfile='/var/log/postgresql/repmgr.log' loglevel=NOTICE reconnect_attempts=4 reconnect_interval=5 ####Standby cluster=cluster node=2 node_name=host2 conninfo='host=host2 user=repmgr dbname=repmgr connect_timeout=2' failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf --log-to-file' follow_command='repmgr standby follow -f /etc/repmgr.conf --log-to-file' logfile='/var/log/postgresql/repmgr.log' loglevel=NOTICE reconnect_attempts=4 reconnect_interval=5 - Contents included in /etc/default/repmgrd, the same for all REPMGRD_ENABLED=yes REPMGRD_CONF="/etc/repmgr.conf" - Result of repmgr cluster show command postgres@host1:~$ repmgr cluster show Role | Name | Upstream | Connection String ----------+--------|----------|-------------------------------------------------------- * master | host1 | | host=host1 user=repmgr dbname=repmgr connect_timeout=2 standby | host2 | host1 | host=host2 user=repmgr dbname=repmgr connect_timeout=2 - Error found in log file (/var/log/postgresql/repmgr.log) when executing command "repmgrd" [ERROR] unable to retrieve record for node 1: ERROR: relation "repmgr_cluster.repl_nodes" does not exist LINE 1: ...onninfo, slot_name, priority, active FROM "repmgr_cl... Complete Tutorial: https://medium.com/@victor.boissiere/how-to-setup-postgresql-cluster-with-repmgr-febc2f10c243

I have such setup: * 2 VM with Rocky Linux 8 for PostgreSQL Primary + Standby setup * PostgreSQL 15 from official rpm repo * [repmgr](http://www.repmgr.org/) for replication * [PgBackRest](https://pgbackrest.org) for backups to S3 (minio instance) My goal is to find out how to restore to a specific backup. I performed such actions: 1. Setup test db with data from [pagila](https://github.com/devrimgunduz/pagila) 2. Make full backup with sudo -u postgres pgbackrest --stanza=cluster --log-level-console=info --type=full backup 3. Drop film table: drop table film cascade; At this point I want to restore to the backup.

[root@rocky2 ~]# sudo -u postgres pgbackrest --stanza=cluster info
stanza: cluster
    status: ok
    cipher: none

    db (current)
        wal archive min/max (15): 000000010000000000000001/00000003000000000000000B

        full backup: 20231228-165042F
            timestamp start/stop: 2023-12-28 16:50:42 / 2023-12-28 16:51:32
            wal start/stop: 000000010000000000000005 / 000000010000000000000006
            database size: 36.4MB, database backup size: 36.4MB
            repo1: backup set size: 4.8MB, backup size: 4.8MB

        full backup: 20231228-171910F
            timestamp start/stop: 2023-12-28 17:19:10 / 2023-12-28 17:20:04
            wal start/stop: 000000010000000000000009 / 000000010000000000000009
            database size: 47.7MB, database backup size: 47.7MB
            repo1: backup set size: 7.3MB, backup size: 7.3MB

1. Stop PostgreSQL on primary and standby: systemctl stop postgresql-15 2. Remove all data files: find /var/lib/pgsql/15/data -mindepth 1 -delete 3. Restore to the latest backup: sudo -u postgres pgbackrest --stanza=cluster restore 4. Start primary again Unfortunately PostgreSQL had applied all WAL records from S3, so film table does not exist anymore. I tried to perform point-in-time restore: 1. Take a loook at backup start timestamp 2. Restore to this time: sudo -u postgres pgbackrest --stanza=cluster --type=time --target="2023-12-28 17:19:10" restore 3. Start PostgreSQL on primary: systemctl start postgresql-15 I have such lines in PostgreSQL logs:

[16-1] user=,db=,app=,client= LOG:  restored log file "00000003000000000000000C" from archive
[17-1] user=,db=,app=,client= LOG:  recovery stopping before commit of transaction 1018, time 2023-12-28 18:14:58.468349==
[18-1] user=,db=,app=,client= LOG:  pausing at the end of recovery
[19-1] user=,db=,app=,client= HINT:  Execute pg_wal_replay_resume() to promote.

So PostgreSQL is in recovery mode:

demo=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t
(1 row)

And I execute pg_wal_replay_resume() like it is said in the logs. film table exists as expected. Then I try to attach standby:

sudo -u postgres /usr/pgsql-15/bin/repmgr -h 192.168.1.125 -U repmgr -d repmgr -f /etc/repmgr/15/repmgr.conf standby clone
systemctl start postgresql-15
sudo -u postgres /usr/pgsql-15/bin/repmgr standby register -F

When I check the status of the cluster it shows that something is wrong with standby:

[root@rocky2 ~]# sudo -u postgres /usr/pgsql-15/bin/repmgr -f /etc/repmgr/15/repmgr.conf cluster show
 ID | Name          | Role    | Status    | Upstream      | Location | Priority | Timeline | Connection string                         
----+---------------+---------+-----------+---------------+----------+----------+----------+--------------------------------------------
 1  | 192.168.1.125 | primary | * running |               | default  | 100      | 4        | host=192.168.1.125 user=repmgr user=repmgr
 2  | 192.168.1.126 | standby |   running | 192.168.1.125 | default  | 100      | 4        | host=192.168.1.126 user=repmgr user=repmgr

WARNING: following issues were detected
  - WAL replay is paused on node "192.168.1.126" (ID: 2) with WAL replay pending; this node cannot be manually promoted until WAL replay is resumed

What am I doing wrong? If I perform select pg_wal_replay_resume(); the standby is promoted to the primary, but I don't do so. So the question is: how to perform point-in-time recovery on the primary-slave setup properly?

We are considering a 3-node Postgres setup where 1-master and 2-standby with replication and master failover handled by repmgr and connection pooling with Pgbouncer. Is there a way to let our application too automatically connect to the newly elected master? I dont see that happening with Pgbouncer or did I miss something? We always need our app to connect to the master db node.

I'm trying to setup a highly available postgres (13) cluster(3 servers) with streaming replication. I first tried native replication and then decided to use repmgr to manage this so I could use the switchover option. So far so good, managed to get this up and running (happy). I then needed to set up the high availability part and considered haproxy pgbouncer and pgpool. I chose pgpool(4.3) but am beginning to regret this choice! After some pain I have have a working cluster of 3 dedicated pgpool machines. I wanted to be able to manually switchover (using repmgr) the primary so that I can do server maintenance without impacting the clients using the DBs. I don't want to use the pgpool automatic failover as repmgr has this covered and works. Problem is that I can't get pgpool to follow the primary when it moves. I have tried a restart of pgpool with -D but that is not working as expected and is not a very good solution. How can I force pgpool to automatically reevaluate the pg cluster and use the new primary? Checking the replicating cluster structure (primary standby standby)should be an option. Just following the primary should also be an option if the rest is to be managed outside of pgpool. The health check should be able to check for this too. (another question as it's not clear: when i have a cluster of pgpool is the status info shared between members of the cluster? )

While trying to browse repmgr.monitoring_history, I noticed it has many tens of millions of records. Wanting to get a peak at the indexes that (may or may not) already exist on the table, I try a quickie pg_dump ...

# pg_dump -U postgres -d repmgr --table=repmgr.monitoring_history --schema-only

...which frustratingly returns only the boilerplate header/footer info...

--
-- PostgreSQL database dump
--

-- Dumped from database version 10.8
-- Dumped by pg_dump version 10.8

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SELECT pg_catalog.set_config('search_path', '', false);
SET check_function_bodies = false;
SET xmloption = content;
SET client_min_messages = warning;
SET row_security = off;

--
-- PostgreSQL database dump complete
--

...well darnit! Did I typo something? 🤔

# pg_dump -U postgres -d repmgr --table=foo.bar --schema-only
pg_dump: no matching tables were found

...no... I _am_ connected to the host I thought I was, right?...

# psql -U postgres -d repmgr -c 'select count(*) from repmgr.monitoring_history;'
  count   
----------
 43597932
(1 row)

... so what gives? Why can't I dump the schema definition for this table? --- Possibly also worth noting that **pg_dump -s -d repmgr** returns only the **CREATE EXTENSION...** & **CREATE SCHEMA...** commands and none of the tables. The behaviour is consistent across a few different repmgr installations. Perhaps I'm having the same issue as this guy ? Also _also_ worth noting that attempting to dump data _only_ also comes up blank. And that I've tried **sudo -u postgres pg_dump...** as well. Dumping another database on the same cluster works just fine returning data & schema as expected.

Please help me to figure it out, help is much appreciated! ERROR: FATAL: no pg_hba.conf entry for replication connection from host "172.18.0.4", user "repmgr", SSL on The following is a list of my pg_hba entries: The following is the query output from pg_hba_file_rules: line_number | type | database | user_name | address | netmask | auth_method | options | error ------------+-------+---------------+------------+------------+-----------------------------------------+-------------+---------+------- 85 | local | {all} | {postgres} | | | peer | | 90 | local | {all} | {all} | | | peer | | 92 | host | {all} | {all} | 127.0.0.1 | 255.255.255.255 | md5 | | 94 | host | {all} | {all} | ::1 | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | md5 | | 97 | local | {replication} | {all} | | | peer | | 98 | host | {replication} | {all} | 127.0.0.1 | 255.255.255.255 | md5 | | 99 | host | {replication} | {all} | ::1 | ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | md5 | | 101 | host | {all} | {repmgr} | 172.18.0.0 | 255.255.255.0 | trust | | 102 | host | {replication} | {repmgr} | 172.18.0.0 | 255.255.255.0 | trust | | As you can see, the pg_hba.conf did get loaded to the database. Where did I do wrong?

I have a **PostgreSQL repmgr Master-Slave setup with HOT standby enabled**. In such repmgr configuration isnt it possible to configure the postgresql.conf in Primary and secondary DIFFERENTLY WHILE HOT STANDBY WILL BE ON. I mean parameters below: - *shared_buffers,* - *max_parallel_workers,* - *max_worker_process,* - *max_connections* etc MUST have to be same or different? If it is different then I saw the DB in secondary through some Errors. So, it ill require same H/W (Resources like RAM, CPU same) setup for both master-slave which is costly enough. Please, I cant start my slave with less config and need a solution to work on less H/W Slave environment to be worked as HOT standby.

I have a master PostgreSQL 9.5 server and a standby server. For replication I use repmgr (WAL streaming). Typically the delay between master and standby is <5s: $ psql -t -c "SELECT extract(epoch from now() - pg_last_xact_replay_timestamp());" 0.044554 Periodically pg_repack is invoked on master in order to optimize indexes and tables. Repacking tables causes massive changes in WAL streaming and significantly slows down replication, so that the difference between master and standby could be more than 1h. Is there a way how to reduce such delay? Is it possible to synchronize newly incoming data with higher priority than repack changes?

I am using PostgreSQL cluster with Barman backup tools. I just recovered one of my backups. After recover, I found barman slot is inactive. Later, I deleted that inactive barman slot and created another barman slot. Below is the command: barman cron barman check pg It shows barman not initialized. Then, I ran another command: barman receiver-wal --reset pg It shows receive wal position ahead of current WAL. So, in that case what is the solution? Thanks In Advance for your support.

I've set up a replica of a Postgresql instance using repmgr, and the replica is totally in sync with the master instance and have been in sync since some days, but repmgr tells me replica isn't connected. This is what the cluster looks like: postgres@www:~$ repmgr cluster show ID | Name | Role | Status | Upstream | Location | Connection string ----+------------------+---------+-----------+-------------+---------+------------------------------------------------------------------ 1 | orig_master | primary | * running | | default | host=MASTER user=USER dbname=repmgr connect_timeout=2 2 | orig_slave | standby | running | orig_master | default | host=SLAVE user=USER dbname=repmgr connect_timeout=2 This is what we get on the replica instance: postgres@db:~$ repmgr node status Node "orig_slave": PostgreSQL version: 9.6.11 Total data size: 5603 MB Conninfo: host=SLAVE user=USER dbname=repmgr connect_timeout=2 Role: standby WAL archiving: disabled (on standbys "archive_mode" must be set to "always" to be effective) Archive command: rsync -a %p barman@BARMAN:/mnt/volume/prod/incoming/%f WALs pending archiving: 0 pending files Replication connections: 0 (of maximal 6) Replication slots: disabled Upstream node: orig_master (ID: 1) Replication lag: 0 seconds Last received LSN: 63/BB0E3C10 Last replayed LSN: 63/BB0E3C10 Which clearly shows that we have no relpication lag and instances are in sync, and WAL numbers are correct too. This is what I get on the master instance: postgres@www:~$ repmgr node status Node "orig_master": PostgreSQL version: 9.6.11 Total data size: 5603 MB Conninfo: host=MASTER user=USER dbname=repmgr connect_timeout=2 Role: primary WAL archiving: enabled Archive command: rsync -a %p barman@BARMAN:/mnt/volume/prod/incoming/%f WALs pending archiving: 0 pending files Replication connections: 1 (of maximal 6) Replication slots: disabled Replication lag: n/a WARNING: following issue(s) were detected: - 1 of 1 downstream nodes not attached: - orig_slave (ID: 2) HINT: execute "repmgr node check" for more details Which tells me that downstream node isn't connected, which is clearly connected! Now, my question is: Is there actually a problem in replication process? If yes, then What is it and how can I solve it? If not, how can I make repmgr sure that there is no problem? P.S.: Postgresql 9.6.11, repmgr 4.2

I want to run ~10k PostgreSQL clusters. Each cluster will be quite small with moderate traffic. I have will have roughly 100 virtual machines. Each VM should run roughly 100 clusters. Each cluster should run in one container. 100 VMs. Each running 100 containers. One cluster per container --> 10k clusters Features which are not available from PG out-of-the-box: * If I create a new cluster I need to check: Which VM has room for a new cluster? * I want to be able to move a cluster to a different VM Before I re-invent the wheel: Is there already a PostgreSQL-way to handle such a scenario? Does it make sense to use a [Kubernetes Postgres-Operator](https://blog.flant.com/comparing-kubernetes-operators-for-postgresql/) or Patroni? Background: It will be some kind of open source learning/teaching environment. Each user should get full database superuser permissions. That's why it is not enough to give each user a database. Each user needs a cluster. At least that's my current impression. Please leave a comment if you have an idea for a different architecture.

How do I remove failed node from a PostgreSQL cluster? postgres@db-prod-ms47ox-10-3-104-92:~$ repmgr -f /etc/repmgr/repmgr.conf cluster show Role | Connection String * master | host=db-prod-ms47ox-10-3-105-192.vandelay.io standby | host=db-prod-ms47ox-10-3-104-92.vandelay.io FAILED | host=db-prod-lu8spc-10-3-104-145.vandelay.io Running repmgr cluster cleanup does not remove this node and it appears to stop me from adding a new node into the cluster. This is with repmgr 2.0 and postgres 9.1

I need to change the roles between two nodes. Circumstance: 2servers: primary: psql01 and standby: psql02 After psql01 stops, psql02 becomes the new primary. After a while, start psql01 On psql01:

[-bash-4.2$ repmgr -f /var/lib/pgsql/repmgr/repmgr.conf cluster show
 ID | Name         | Role    | Status               | Upstream | Location | Priority | Timeline | Connection string
----+--------------+---------+----------------------+----------+----------+----------+----------+---------------------------------------------
 1  | psql01       | primary | * running            |          | default  | 100      | 7        | host=psql01 user=repmgr dbname=repmgr
 2  | psql02       | standby | ! running as primary |          | default  | 100      | 8        | host=psql02 user=repmgr dbname=repmgr

WARNING: following issues were detected
  - node "postgresql02" (ID: 2) is registered as standby but running as primary](url)

On psql02:

repmgr -f /var/lib/pgsql/repmgr/repmgr.conf cluster show

	 ID | Name         | Role    | Status    | Upstream | Location | Priority | Timeline | Connection string
	----+--------------+---------+-----------+----------+----------+----------+----------+---------------------------------------------
	 1  | psql01       | primary | ! running |          | default  | 100      | 7        | host=psql01 user=repmgr dbname=repmgr
	 2  | psql02       | primary | * running |          | default  | 100      | 8        | host=psql02 user=repmgr dbname=repmgr

	WARNING: following issues were detected
	  - node "psql01" (ID: 1) is running but the repmgr node record is inactive

I try to put my old primary to standby with the following commands:

-bash-4.2$ repmgr -f /var/lib/pgsql/repmgr/repmgr.conf node service --action=stop --checkpoint
NOTICE: issuing CHECKPOINT
DETAIL: executing server command "sudo systemctl stop postgresql-11"

-bash-4.2$ repmgr -f /var/lib/pgsql/repmgr/repmgr.conf -d 'host=psql01 user=repmgr dbname=repmgr' node rejoin
ERROR: connection to database failed
DETAIL:
could not connect to server: Connection refused
        Is the server running on host "psql01" (172.16.11.171) and accepting
        TCP/IP connections on port 5432?

What's exaclty happen? If psql01 goes down how can I change the role to secondary?

I've got a PostgreSQL Replication set up using Repmgr. Replication works fine, until one of the databases is deleted on the master node. Standby replica throws off 'WAL cannot be found' error and disconnects from the Upstream which causes a major issue for the failover system. Standby replicas won't recover unless postgres directory is wiped clean and the database is fully cloned from the master again. PostgreSQL version: 12.5 Repmgr version: 5.1.0 System: CentOS 7 Any help would be appreciated!

I'm new to postgres administration and was wondering what does the "*" symbol means in the repmgr cluster show command output. ID | Name | Role | Status | Upstream | Location | Connection string ----+---------+---------+-----------+----------+----------+------------------------------------------------------------------ 1 | node-1 | standby | running | node-2 | default | host= [...] 2 | node-2 | primary | * running | | default | host= [...] 3 | node-3 | witness | * running | node-2 | default | host= [...] I didn't find anything about it in the documentation (https://repmgr.org/docs/4.0/repmgr-cluster-show.html) Using repmgr cluster show --csv as mentioned in the documentation, I can see that the node with ID 1 is in recovery state "*in recovery*". Is it related ? postgresql version : 10.5 repmgr version : 4.0