La version 12 de PostgreSQL est sorti le 3 octobre dernier avec l’arrivée de quelques nouveautés assez intéressantes.
On citera l’authentification renforcée, le data checksum activable même après instance créée, la reindexation concurrentielle et bien d’autres….

Le sujet du jour qui va nous intéresser est celui de la réplication.
Pour rappel, depuis la version 9.0 PostgreSQL valide la replication au fil de l’eau, appelée “streaming replication”.

Voyons ce qui a changé dans cette fonctionnalité PostgreSQL

 

Mise en place de la streaming replication

Rappelons quelques concepts.

3 scénarii de haute disponibilité existent pour PostgreSQL:

• La réplication de type « warm_standby ». Les fichiers WAL archivés de l’instance primaire sont envoyés à la standby, qui les rejouera 1 par 1. Dans cette configuration, l’instance standby n’est pas accessible en lecture et le retard peut être d’au moins 1 WAL de 16Mo.
• La réplication de type « Hot_standby ». Fonctionnement identique à « warm_standby » mais avec l’instance standby ouverte en lecture seule.
• La réplication au fil de l’eau « streaming replication ». Dans cette configuration, toute transaction enregistrée sur la base primaire est également enregistrée sur la standby via la connexion réseau. C’est le mécanisme qui permet d’avoir une standby la plus à jour car elle se base sur le WAL courant de la base primaire. Nous pouvons perdre tout au plus 1 transaction dans le mode asynchrone.

C’est cette dernière que nous allons tester en version PostgreSQL 12.
A peu de choses près, la mise en place ressemblera à ce qui se fait depuis la version 9.

Préparer notre instance primaire

Tout d’abord, s’assurer que le fichier ${PGDATA}/postgresql.conf dispose des valeurs suivantes pour la mise en place de la streaming replication :

• wal_level = replica           
• max_wal_sender = 2                       
• wal_keep_segments = 100        
• hot_standby = on                                           # Ce paramètre sera utile sur la standby pour la lecture

Il s’agira ensuite de créer un nouveau user/role dans PostgreSQL qui sera utilisé par la standby pour lire les WAL au fil de l’eau.

PRIMARY> $ psql -x -c “CREATE USER repli WITH REPLICATION ENCRYPTED PASSWORD '*****'”
CREATE ROLE

Nous partons du principe que notre serveur primaire a l’IP 192.168.2.43.
Notre serveur de secours possède l’IP 192.168.2.13.

Ajouter la ligne suivante dans le “pg_hba.conf” de l’instance primaire :

PRIMARY> $ vi ${PGDATA}/pg_hba.conf
…
# TYPE    DATABASE            USER       ADDRESS                    METHOD
Host      replication         repli      192.168.2.13/32            md5
Host      replication         repli      192.168.2.43/32            md5

L’adresse IP de l’hôte standby sera à renseigner afin qu’il puisse se connecter avec l’utilisateur « repli » de l’instance primaire.
Nous renseignerons également l’IP de l’instance primaire, car en cas de changement de rôle, c’est celle-ci qui répondra aux connexions de la nouvelle standby.
Ne pas oublier de renseigner également le PASSFILE avec les informations du user « repli ».

PRIMARY> $ vi $HOME/.passfile
192.168.2.43:5432:*:repli:********
192.168.2.13:5432:*:repli:********

Recharger la configuration une fois ceci effectuer.

PRIMARY> $ psql -c "select pg_reload_conf()"

Préparer notre standby

La suite consistera à effectuer un transfert des fichiers de l’instance PostgreSQL avec Pg_basebackup (outil de backup à chaud).
Effectuer une copie, avant cela, des fichiers de conf de la standby.

STANDBY> $ cp ${PGDATA}/*.conf /data/postgres/backup
STANDBY> $ ls -l /data/postgres/backup
total 44
-rw-------. 1 postgres postgres  4513 Nov 14 13:13 pg_hba.conf
-rw-------. 1 postgres postgres  1636 Nov 14 13:13 pg_ident.conf
-rw-------. 1 postgres postgres    88 Nov 14 13:13 postgresql.auto.conf
-rw-------. 1 postgres postgres 26754 Nov 14 13:13 postgresql.conf

Puis supprimer ce qu’il y’a dans ${PGDATA}

 

STANDBY> $ rm -rf ${PGDATA}/*

L’utilisateur « postgres » sur la machine de standby devra être configuré comme celui de la machine primaire, à savoir :

• Les mêmes variables d’environnement (reprendre le fichier .pgsql_profile du $HOME)
• La partition /data identique pour les fichiers bases de données PostgreSQL
• Le passwordfile $HOME/.passfile avec les droits 600.

Pour le backup via « pg_basebackup », nous utiliserons l’option -R afin de spécifier à l’outil que nous souhaitons faire cette sauvegarde pour une réplication.

La commande sera à passer sur la standby. On sait que l’adresse IP du serveur primaire est 192.168.2.43.

STANDBY> $ pg_basebackup -h 192.168.2.43 -U repli -D $PGDATA -Fp -Xs -P -R
Password:
32637/32637 kB (100%), 1/1 tablespace

 

On vérifie ce qui est présent dans le répertoire $PGDATA de la standby.

STANDBY> $ ls -l
total 128
-rw-------. 1 postgres postgres   224 Nov 14 13:47 backup_label
drwx------. 6 postgres postgres  4096 Nov 14 13:47 base
-rw-------. 1 postgres postgres    30 Nov 14 13:47 current_logfiles
drwx------. 2 postgres postgres  4096 Nov 14 13:47 global
drwx------. 2 postgres postgres  4096 Nov 14 13:47 log
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_commit_ts
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_dynshmem
-rw-------. 1 postgres postgres  4623 Nov 14 13:47 pg_hba.conf
-rw-------. 1 postgres postgres  1636 Nov 14 13:47 pg_ident.conf
drwx------. 4 postgres postgres  4096 Nov 14 13:47 pg_logical
drwx------. 4 postgres postgres  4096 Nov 14 13:47 pg_multixact
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_notify
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_replslot
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_serial
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_snapshots
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_stat
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_stat_tmp
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_subtrans
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_tblspc
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_twophase
-rw-------. 1 postgres postgres     3 Nov 14 13:47 PG_VERSION
drwx------. 3 postgres postgres  4096 Nov 14 13:47 pg_wal
drwx------. 2 postgres postgres  4096 Nov 14 13:47 pg_xact
-rw-------. 1 postgres postgres   262 Nov 14 13:47 postgresql.auto.conf
-rw-------. 1 postgres postgres 26748 Nov 14 13:47 postgresql.conf
-rw-------. 1 postgres postgres     0 Nov 14 13:47 standby.signal

 

Bye Bye le “recovery.conf” !!

Nous sommes sur une version PostgreSQL 12, nous n’avons plus de fichier « recovery.conf » comme avec les versions antérieures.
En revanche, comme nous avons spécifié l’option -R pour pg_basebackup, nous avons maintenant le fichier « standby.signal » dans $PGDATA.
Ce fichier indique à notre moteur PostgreSQL local qu’il est standby.

De plus, avec notre version PostgreSQL 12, l’outil pg_basebackup a alimenté le fichier nommé « postgresql.auto.conf » avec la ligne suivante :

STANDBY> $ cat postgresql.auto.conf
primary_conninfo = 'user=repli password=****** host=192.168.2.43 port=5432 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

Rappelons que le fichier « postgresql.auto.conf » est un fichier de configuration embarquant automatiquement les paramètres passés via la commande ALTER SYSTEM .
Ce fichier est lu par le « postmaster » juste après le « postgresql.conf » au moment du démarrage de l’instance.

Afin de respecter la sécurité, il sera nécessaire de changer cette chaîne de connexion dans le fichier « postgresql.auto.conf ».
Changer la valeur « password= » par l’appel au passwordfile.
Soit

primary_conninfo = 'user=repli passfile=/var/lib/pgsql/.passfile host=192.168.2.43 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

Synchronisation

L’instance standby peut alors être redémarrée afin de se synchroniser avec la primaire.

STANDBY> $ pg_ctl start

On peut voir dans le log de démarrage que la base standby effectue un recover du WAL 0/6000028 -> 0/6000100. Puis elle se synchronise directement avec la primaire sur son WAL courant (0/7000000).

2019-11-14 14:00:31.689 UTC [1771] LOG:  entering standby mode
2019-11-14 14:00:31.693 UTC [1771] LOG:  redo starts at 0/6000028
2019-11-14 14:00:31.695 UTC [1771] LOG:  consistent recovery state reached at 0/6000100
2019-11-14 14:00:31.695 UTC [1769] LOG:  database system is ready to accept read only connections
2019-11-14 14:00:31.776 UTC [1775] LOG:  started streaming WAL from primary at 0/7000000 on timeline 1

Vérifications

Sur la base primaire, lancer la commande :

PRIMARY> $ psql -x -c "select * from pg_stat_replication"
-[ RECORD 1 ]----+------------------------------
pid              | 2470
usesysid         | 16389
usename          | repli
application_name | walreceiver
client_addr      | 192.168.2.13
client_hostname  |
client_port      | 37218
backend_start    | 2019-11-14 14:00:31.701736+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/7000148
write_lsn        | 0/7000148
flush_lsn        | 0/7000148
replay_lsn       | 0/7000148
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async
reply_time       | 2019-11-14 14:03:02.091004+00

Sur l’instance standby, lancer la commande

STANDBY> $ psql -x -c "select * from pg_stat_wal_receiver"
-[ RECORD 1 ]---------+--------------------------------------------
pid                   | 1775
status                | streaming
receive_start_lsn     | 0/7000000
receive_start_tli     | 1
received_lsn          | 0/7000148
received_tli          | 1
last_msg_send_time    | 2019-11-14 14:06:02.55313+00
last_msg_receipt_time | 2019-11-14 14:06:02.552627+00
latest_end_lsn        | 0/7000148
latest_end_time       | 2019-11-14 14:00:31.776142+00
slot_name             |
sender_host           | 192.168.2.43
sender_port           | 5432
conninfo              | user=repli password=******** dbname=replication host=192.168.2.43 port=5432 fallback_application_name=walreceiver sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any

 

On validera qu’il n’y ait pas de « lag » dans le processus, soit vérifier que « received_lsn » = « latest_end_lsn ».
L’autre test consistera à créer une table sur la primaire et s’assurer qu’elle est présente coté standby

PRIMARY> $ psql -dmanuelo -Umanu
manuelo=# create table replicatest (nom varchar(10));
CREATE TABLE
manuelo=# insert into replicatest values ('table OK');
INSERT 0 1

Puis

STANDBY> ]$ psql -dmanuelo -Umanu
manuelo=# select * from replicatest;
   nom
----------
 table OK
(1 row)

 

Le switchover

Concept

Nous allons nous mettre dans la situation ou l’on souhaite changer de rôle, c’est-à-dire que notre serveur primaire va passer standby et le standby sera primaire.

Arrêt de l’instance primaire

Le mode fast sera choisi pour fermer proprement les connexions.

PRIMARY> $ pg_ctl stop -m fast
waiting for server to shut down.... done
server stopped

Dans le log de la primaire

2019-11-15 11:14:18.048 UTC [725] LOG:  shutting down
2019-11-15 11:14:18.110 UTC [725] LOG:  checkpoint starting: shutdown immediate
2019-11-15 11:14:18.183 UTC [725] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s, total=0.078 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16383 kB, estimate=16383 kB
2019-11-15 11:14:18.287 UTC [717] LOG:  database system is shut down

 

Sur la standby, nous irons voir quel est le dernier WAL reçu de la primaire

 

STANDBY> $ psql -x -c « select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp(); »
-[ RECORD 1 ]-----------------+----------
pg_last_wal_receive_lsn       | 0/90000A0
pg_last_wal_replay_lsn        | 0/90000A0
pg_last_xact_replay_timestamp |

 

Sur la standby, le dernier WAL reçu et traité est le 0/90000A0. Si celui-ci n’évolue plus au cours des dernières secondes, on passe à la suite.

 

Changement de rôle sur la standby

Nous allons pouvoir effectuer le « promote » de la standby pour changer son rôle.

 

STANDBY>  pg_ctl promote
waiting for server to promote.... done
server promoted

Dans le log de la standby. Nous remarquons un changement de Timeline suite à cela. Nous sommes maintenant dans le Timeline 2 sur notre nouvelle instance primaire.

 

2019-11-15 11:22:38.853 UTC [732] LOG:  received promote request
2019-11-15 11:22:38.853 UTC [732] LOG:  redo done at 0/9000028
2019-11-15 11:22:38.857 UTC [732] LOG:  selected new timeline ID: 2
2019-11-15 11:22:38.902 UTC [732] LOG:  archive recovery complete
2019-11-15 11:22:38.924 UTC [733] LOG:  checkpoint starting: force
2019-11-15 11:22:38.925 UTC [729] LOG:  database system is ready to accept connections

 

On s’assurera que notre ancienne standby n’est plus en mode RECOVERY (tagger à f comme false).

 

STANDBY> $ psql -x -c "select pg_is_in_recovery();"
-[ RECORD 1 ]-----+--
pg_is_in_recovery | f

 

Le fichier « standby.signal » a également disparu sur le serveur standby dans le $PGDATA.

STANDBY> $  ls -l $PGDATA/standby.signal
ls: cannot access '/data/postgres/12/stabdy.signal': No such file or directory

Changement de rôle sur la primaire

L’objectif est de passer notre ancienne instance primaire en nouvelle standby.
Nous allons pour cela, alimenter le fichier « postgresql.auto.conf » avec la chaîne de connexion vers notre nouvelle primaire.

Il suffira d’ajouter la ligne suivante :

NEW_STANDBY> $ echo « primary_conninfo = 'user=repli passfile=/var/lib/pgsql/.passfile host=192.168.2.13 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any' » >> $PGDATA/postgresql.auto.conf

L’IP 192.168.2.13 correspond à notre ancienne standby qui maintenant, est notre primaire.
Puis ne pas oublier de créer le fichier « standby.signal » sur notre nouvelle instance standby.

Rappelons qu’en version PostgreSQL 12, nous n’avons plus de “recovery.conf” à gérer !

NEW_STANDBY> $ touch $PGDATA/standby.signal

Par la suite, nous redémarrerons la nouvelle standby.

NEW_STANDBY> $ pg_ctl start

La log de notre nouvelle standby donne les informations suivantes

 

2019-11-15 12:56:47.589 UTC [1777] LOG:  entering standby mode
2019-11-15 12:56:47.593 UTC [1777] LOG:  consistent recovery state reached at 0/90000A0
2019-11-15 12:56:47.593 UTC [1777] LOG:  invalid record length at 0/90000A0: wanted 24, got 0
2019-11-15 12:56:47.594 UTC [1775] LOG:  database system is ready to accept read only connections
2019-11-15 12:56:47.679 UTC [1781] LOG:  fetching timeline history file for timeline 2 from primary server
2019-11-15 12:56:47.684 UTC [1781] LOG:  started streaming WAL from primary at 0/9000000 on timeline 1
2019-11-15 12:56:47.685 UTC [1781] LOG:  replication terminated by primary server
2019-11-15 12:56:47.685 UTC [1781] DETAIL:  End of WAL reached on timeline 1 at 0/90000A0.
2019-11-15 12:56:47.685 UTC [1777] LOG:  new target timeline is 2
2019-11-15 12:56:47.686 UTC [1781] LOG:  restarted WAL streaming at 0/9000000 on timeline 2
2019-11-15 12:56:47.734 UTC [1777] LOG:  redo starts at 0/90000A0

 

Le log de notre standby nous indique bien ce changement de TIMELINE que nous avons également relevé au moment du « promote » de la standby.
Nous sommes actuellement dans le Timeline 2.

Vérfications

La vérification consistera à jouer les 2 requêtes de contrôle des status sur la primaire, et la standby

PRIMARY> $ psql -x -c « select * from pg_stat_replication; »

STANDBY> $ psql -x -c « select * from pg_stat_wal_receiver ; »

 

On remarque ainsi aisément, que l’opération switchover dans le cadre d’instances PostgreSQL 12 est facilitée car nous n’avons que ce fichier témoin nommé « standby.signal » à recréer manuellement.

Le Failover

Concept

L’opération de failover se produit lorsque l’instance primaire devient indisponible. L’instance standby n’arrive plus à communiquer avec, et l’on considère que les connexions utilisateurs doivent être envoyés vers la standby. Il faut donc déclarer celle-ci comme nouvelle primaire et casser le lien de réplication.

L’objectif est de rendre la base standby autonome.
Après cela, une resynchronisation devra être réeffectuée avec un backup/restore de l’instance nouvellement primaire ou bien via l’outil « pg_rewind ».

Arrêt brutale de l’instance primaire

L’arrêt du serveur primaire se fait soudainement, et dans le log de l’instance standby, nous voyons

 

2019-11-15 13:51:18.045 UTC [1929] LOG:  recovery restart point at 0/A0000D0
2019-11-15 14:12:40.641 UTC [1932] FATAL:  could not receive data from WAL stream: FATAL:  terminating connection    due to administrator command
2019-11-15 14:12:40.642 UTC [1928] LOG:  invalid record length at 0/A0001B8: wanted 24, got 0
2019-11-15 14:12:40.720 UTC [1969] FATAL:  could not connect to the primary server: FATAL:  the database system i   s shutting down
2019-11-15 14:13:52.703 UTC [1973] FATAL:  could not connect to the primary server: could not connect to server: No route to host
                Is the server running on host "192.168.2.43" and accepting
                TCP/IP connections on port 5432?
2019-11-15 14:13:55.775 UTC [1974] FATAL:  could not connect to the primary server: could not connect to server: No route to host
                Is the server running on host "192.168.2.43" and accepting
                TCP/IP connections on port 5432?
2019-11-15 14:13:58.847 UTC [1975] FATAL:  could not connect to the primary server: could not connect to server: No route to host

 

On suppose un souci grave coté serveur primaire que nous ne pourrons résoudre rapidement.
Nous allons donc passer l’instance standby en tant qu’instance primaire et autonome.

Changement de rôle de l’instance standby

On passe le promote sur l’instance standby

STANDBY> $  pg_ctl promote
waiting for server to promote.... done
server promoted

 

Le log de la standby indique un changement de rôle et un nouvel ID de timeline, l’ID 4.

2019-11-15 14:16:19.850 UTC [1928] LOG:  received promote request
2019-11-15 14:16:19.850 UTC [1928] LOG:  redo done at 0/A000180
2019-11-15 14:16:19.854 UTC [1928] LOG:  selected new timeline ID: 4
2019-11-15 14:16:19.907 UTC [1928] LOG:  archive recovery complete
2019-11-15 14:16:19.916 UTC [1929] LOG:  checkpoint starting: force
2019-11-15 14:16:19.917 UTC [1926] LOG:  database system is ready to accept connections
2019-11-15 14:16:19.946 UTC [1929] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s, total=0.029 s; sync files=0, longest=0.000 s, average=0.000 s; distance=0 kB, estimate=0 kB

 

Le fichier « standby.signal » n’est plus présent dans $PGDATA et le mode recovery sur l’instance est passé à FALSE

NEW_PRIMARY> $ ls -l standby.signal
ls: cannot access 'standby.signal': No such file or directory

NEW_PRIMARY> $ psql -x -c "select pg_is_in_recovery()"
-[ RECORD 1 ]-----+--
pg_is_in_recovery | f

 

La resynchronisation

Une fois le noeud anciennement primaire réactivé, il s’agira de faire une opération de resynchonisation entre les 2 instances. Rappelons que nous avons changé de TIMELINE sur notre nouvelle primaire. L’ancienne doit donc être réactualisée.

L’outil “pg_rewind”

L’outil pg_rewind est, depuis la version 9.5 de PostgreSQL, intégré dans les binaires.
Il sera donc possible, si l’instance de base de données de l’ancien site primaire n’est pas trop endommagée, de reprendre les blocks de données qui sont différents vis-à-vis de la source.

Attention, pg_rewind comporte quelques prérequis de fonctionnement :

• Le « data_checksum » doit être activé. Ce qui est le cas dans notre installation qui un cluster 12, donc activable ultérieurement.
• Pg_rewind va reprendre les fichiers de conf sans regarder les différences. Faire donc un backup si possible au cas où, une fois le serveur en échec remonté proprement et avant de lancer la commande pg_rewind.
• Comme le serveur anciennement primaire ne s’est pas arrêté correctement ( en cas de coupure électrique, arrêt brutale …..), il sera nécessaire de faire un arrêt/redémarrage propre de l’instance à resynchroniser.

Avant d’utiliser pg_rewind, penser, si ce n’est pas fait, à renseigner le « pg_hba.conf » afin que les nœuds acceptent les connexions depuis l’utilisateur « postgres » avec le mode md5. Ajouter ces lignes sur les 2 instances.

# connexions pour pg_rewind
host    all             postgres        192.168.2.13/32         md5
host    all             postgres        192.168.2.43/32         md5

 

Faire un « reload » de la configuration après cette modification.

$ psql -c « select pg_reload_conf() ; »

Remonter l’ancienne primaire et lancer la reconstruction via “pg_admin”

 

OLD_PRIMARY> $ pg_ctl start

Arrêter la de façon propre.

OLD_PRIMARY> $ pg_ctl stop -m fast
waiting for server to shut down.... done
server stopped

Il sera possible d’évaluer l’opération en utilisant l’option « –dry-run » de pg_rewind.

OLD_PRIMARY> $ pg_rewind --target-pgdata=/data/postgres/12 --source-server="host=192.168.2.13 port=5432 user=postgres passfile=/var/lib/pgsql/.passfile" --dry-run --progress
pg_rewind: connected to server
pg_rewind: servers diverged at WAL location 0/A0001B8 on timeline 3
pg_rewind: rewinding from last common checkpoint at 0/A000108 on timeline 3
pg_rewind: reading source file list
pg_rewind: reading target file list
pg_rewind: reading WAL in target
pg_rewind: need to copy 149 MB (total source directory size is 175 MB)
152678/152678 kB (100%) copied
pg_rewind: creating backup label and updating control file
pg_rewind: syncing target data directory
pg_rewind: Done!

 

Lancer ensuite la reconstruction via pg_admin sans le dry–run.

OLD_PRIMARY> $   pg_rewind --target-pgdata=/data/postgres/12 --source-server="host=192.168.2.13 port=5432 user=postgres passfile=/var/lib/pgsql/.passfile" --progress 
pg_rewind: connected to server
pg_rewind: servers diverged at WAL location 0/A0001B8 on timeline 3
pg_rewind: rewinding from last common checkpoint at 0/A000108 on timeline 3
pg_rewind: reading source file list
pg_rewind: reading target file list
pg_rewind: reading WAL in target
pg_rewind: need to copy 149 MB (total source directory size is 175 MB)
152678/152678 kB (100%) copied
pg_rewind: creating backup label and updating control file
pg_rewind: syncing target data directory
pg_rewind: Done!

 

L’instance PostgreSQL, nouvelle standby, devra être redémarrée et on validera la synchronisation.
Les commandes suivantes seront utilisées sur la primaire et la standby.

PRIMARY> $ psql -x -c « select * from pg_stat_replication; »

STANDBY> $ psql -x -c « select * from pg_stat_wal_receiver ; »

 

n’hésitez pas à faire des commentaires à ce sujet.

Emmanuel RAMI

 

 

Continuez votre lecture sur le blog :

• Haute disponibilité de PostgreSQL avec Patroni (Ludovic AUGEREAU) [PostgreSQL]
• PostgreSQL 17 : des sauvegardes incrémentales avec pg_basebackup (Emmanuel RAMI) [Non classéPostgreSQL]
• Linux Out-Of-Memory Killer (OOM-Killer) pour un serveur base de données PostgreSQL (Emmanuel RAMI) [Non classé]
• Kubegres : l’opérateur Kubernetes clé en main pour PostgreSQL (David Baffaleuf) [ContainerDevopsPostgreSQL]
• Création d’un Dataguard physique (Benjamin VESAN) [Oracle]