![Share on Twitter twitter](https://sp-ao.shortpixel.ai/client/to_webp,q_glossy,ret_img,w_24,h_24/https://blog.capdata.fr/wp-content/plugins/social-media-feather/synved-social/image/social/regular/48x48/twitter.png)
![Share on Linkedin linkedin](https://sp-ao.shortpixel.ai/client/to_webp,q_glossy,ret_img,w_24,h_24/https://blog.capdata.fr/wp-content/plugins/social-media-feather/synved-social/image/social/regular/48x48/linkedin.png)
![Share by email mail](https://sp-ao.shortpixel.ai/client/to_webp,q_glossy,ret_img,w_24,h_24/https://blog.capdata.fr/wp-content/plugins/social-media-feather/synved-social/image/social/regular/48x48/mail.png)
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]
![Share on Twitter twitter](https://sp-ao.shortpixel.ai/client/to_webp,q_glossy,ret_img,w_24,h_24/https://blog.capdata.fr/wp-content/plugins/social-media-feather/synved-social/image/social/regular/48x48/twitter.png)
![Share on Linkedin linkedin](https://sp-ao.shortpixel.ai/client/to_webp,q_glossy,ret_img,w_24,h_24/https://blog.capdata.fr/wp-content/plugins/social-media-feather/synved-social/image/social/regular/48x48/linkedin.png)
![Share by email mail](https://sp-ao.shortpixel.ai/client/to_webp,q_glossy,ret_img,w_24,h_24/https://blog.capdata.fr/wp-content/plugins/social-media-feather/synved-social/image/social/regular/48x48/mail.png)
Bel article très complet !
En remplacement de “recovery.conf”, il reste toujours un fichier à manipuler (standby.signal) en le créant sur l’ancien primary devenu standby lors d’un switchover. Cependant, il n’y a plus de fichier de configuration dédié au recovery, celle-ci étant reportée dans la configuration d’instance postgresql.conf. C’est une évolution très intéressante simplifiant encore l’administration de la solution.
Bonjour Emmanuel,
Je confirme top article très complet.
Il y a juste une petite coquille dans les commandes:
Remplacer “psql -x -x” par “psql -x -c”
Bravo et encore merci Emmanuel.
Hello
merci Ugo, bien vu! C’est corrigé.
Comme quoi parfois le copié collé peut avoir des ratés également.
🙂
Bonjour Emmanuel,
Super article !
J’ai juste une remarque sur les fichiers de configuration qui ne sont pas toujours dans ${PGDATA}. Sur la Ubuntu, par exemple, ils sont sous /etc/postgresql/12/main/. On n’a pas à les sauvegarder avant !
Merci
Bonjour Florence
merci pour votre remarque. Vous avez, en effet, tout à fait raison, dans le monde Debian/Ubuntu, les fichiers de conf sont dans “/etc/postgresql/”version”/main” par défaut.
Il est vrai que dans cet article, j’ai fait ma configuration sur RedHat/CentOS et donc c’est un peu différent.
Le monde Debian permet aussi de gérer son instance via des commandes comme “pg_lsclusters” ou tout autre bien pratiques.
Bonne journée à vous ! 🙂
Dans la procédure de failover, l’ancien serveur primaire devient le nouveau serveur standby.
Il faut donc créer un fichier standby.signal avant de le démarrer non ?
bon boulot
Merci beaucoup pour ce partage.
En RHEL8 avec postgresql 12.10, en nommant le fichier $HOME/.pgpass plutôt que $HOME/.passfile vous n\\\’aurez plus besoin de saisir le mot de passe a l\\\’étape pg_basebackup -h 192.168.2.43 -U repli -D $PGDATA -Fp -Xs -P -R, ni de remplacer le password par le passfile dans postgresql.auto.conf.
Hello
désolé pour ce retard, et merci Olivier pour cette remarque !
En effet, par défaut, c\\\’est bien le nom \\\”.pgpass\\\” qui est utilisé pour PostgreSQL.
Cordialement.
Bonjour,
Article très intéressant et simple à mettre en place. Grace à ça j\’ai pu lever beaucoup de zones d\’ombre.
Merci pour ce beau travail.