diff --git a/HowtoPostgreSQL/ReplicationPhysique.md b/HowtoPostgreSQL/ReplicationPhysique.md index 98bea369..5b01a71b 100644 --- a/HowtoPostgreSQL/ReplicationPhysique.md +++ b/HowtoPostgreSQL/ReplicationPhysique.md @@ -59,7 +59,7 @@ Créer un utilisateur dédié pour la réplication : postgres=# CREATE ROLE repl WITH LOGIN REPLICATION PASSWORD 'PASSWORD'; ~~~ -On peux le faire aussi comme ceci, avec l'utilisateur Unix postgres : +On peut le faire aussi comme ceci, avec l'utilisateur Unix postgres : ~~~ postgres@hostname:~$ createuser --no-superuser --no-createrole --no-createdb --replication -P repl @@ -74,7 +74,7 @@ hostssl replication repl 192.0.2.2/32 md5 ## Configuration du serveur réplica -> *Note* 1 : A partir de Postgresql 10 il n'est plus necessaire de modifié la variable hot_standby, ni de créer au préalable le fichier recovery.conf, voir directement la section **Synchronisation initiale des données (Méthode courante)** +> *Note* 1 : A partir de Postgresql 10 il n'est plus necessaire de modifier la variable hot_standby, ni de créer au préalable le fichier recovery.conf, voir directement la section **Synchronisation initiale des données (Méthode courante)** > *Note* 2 : Cette configuration est relative au serveur réplica, mais elle doit également être reprise à l'identique sur le serveur maître, en renommant le fichier `recovery.conf` pour qu'il ne soit pas pris en compte. @@ -140,17 +140,17 @@ postgres@$: echo "*:*:*:repl:mypass" > .pgpass # sudo -u postgres pg_basebackup -h IP_PRIMAIRE -D /var/lib/postgresql// -P -R -v -U repl ~~~ -L'option -D indique le PGDATA du secondaire, dans lequel on veux copié les données. +L'option -D indique le PGDATA du secondaire, dans lequel on veut copier les données. L'option `-R` s'occupe de créer le fichier recovery.conf (ou postgresql.auto.conf si version suppérieure à 11) dans `/var/lib/postgresql///` pg_basebackup s'occupe de faire un checkpoint du WAL courant (pg_start_backup) de transférer les fichiers des bases puis d'exécuter la fonction SQL _pg_stop_backup_ -Pendant le transfert des fichiers, la base a pu subir des modifications. C'est pourquoi pg_basebackup attend que le primaire et fait un checkpoint dans sont WAL avant de tranférés les données, par défaut un checkpoint est fait toutes les 5 minutes, donc la commande pg_basebackup peux prendre 5 minutes avant de commencer a synchronisé les données. +Pendant le transfert des fichiers, la base a pu subir des modifications. C'est pourquoi pg_basebackup attend que le primaire et fait un checkpoint dans sont WAL avant de tranférés les données, par défaut un checkpoint est fait toutes les 5 minutes, donc la commande pg_basebackup peut prendre 5 minutes avant de commencer a synchronisé les données. -Si on veux forcer un checkpoint sur le primaire, on peux utilisé la commande pg_basebackup avec l'option `-c fast` +Si on veut forcer un checkpoint sur le primaire, on peut utiliser la commande pg_basebackup avec l'option `-c fast` -* Créer un fichier `recovery.conf` situé dans le datadir avec les info suivantes (si version inférieure a PG12)  : +* Créer un fichier `recovery.conf` situé dans le datadir avec les infos suivantes (si version inférieure a PG12)  : ~~~ standby_mode = 'on' @@ -163,7 +163,7 @@ recovery_target_timeline = 'latest' Il est nécessaire que ce fichier appartienne à l'utilisateur _postgres_, notamment en cas de promotion en master (car PostgreSQL va renommer le fichier en `recovery.done`) : -* Si version Postgresql supérieure à 11, le `recovery.conf` n'existe plus, il est remplacer par le fichier postgresql.auto.conf, et le fichier `standby.signal` +* Si version Postgresql supérieure à 11, le `recovery.conf` n'existe plus, il est remplacé par le fichier postgresql.auto.conf, et le fichier `standby.signal` * redémarrer PostgreSQL sur le réplica. @@ -200,7 +200,7 @@ Il est donc impératif de supprimer un slot de réplication si le secondaire a Plusieurs possibilités pour surveiller la réplication : -* Voir la position courante dans les logs sur le maître et le réplica (on peut en déduire si ils sont synchro ou pas) : +* Voir la position courante dans les logs sur le maître et le réplica (on peut en déduire s’ils sont synchro ou pas) : ~~~ # pgrep -lf "wal (sender|receiver) process" @@ -231,7 +231,7 @@ sync_state | async * Les données à surveiller sont notamment les `*_location`, qui indique la position courante dans les WAL à différentes étapes de la réplication. Voir pour le détails des champs. -* Pour pouvoir quantifié le retard de réplication, on peut utiliser la commande [check_postgres](http://bucardo.org/check_postgres/check_postgres.pl.html) avec l'option _hot_standby_delay_ : +* Pour pouvoir quantifier le retard de réplication, on peut utiliser la commande [check_postgres](http://bucardo.org/check_postgres/check_postgres.pl.html) avec l'option _hot_standby_delay_ : ~~~ $ check_postgres --action=hot_standby_delay --dbhost=localhost --dbport=5432 --dbname=template1 --dbuser=nrpe --dbpass=PASSWORD --dbhost=192.0.2.2 --dbport=5432 --warning=500000 --critical=1000000 @@ -241,28 +241,28 @@ POSTGRES_HOT_STANDBY_DELAY OK: DB "template1" (host:192.0.2.2) 0 | time=0.09s re Où localhost est le maître et 192.0.2.2 le réplica. Les valeurs de _replay_delay_ et _receive-delay_ sont *à priori* exprimées en octets de WAL à rejouer. ### check_pgactivity -On peux surveilé la streaming réplication également avec le check_pgactivity : +On peut surveiller la streaming réplication également avec le check_pgactivity : En Debian 10, on installe le paquet *check-pgactivity* On surveille la streaming réplication avec le service *streaming_delta* qui surveile le delta de données entre le primaire et le secondaire. -Le check peut prendre le nom qu'on a donnée à la variable application_name sur le secondaire dans le fichier recovery.conf +Le check peut prendre le nom qu'on a donné à la variable application_name sur le secondaire dans le fichier recovery.conf -Si on a seulement un secondaire à surveillé on peux le faire comme ceci : +Si on a seulement un secondaire à surveiller on peut le faire comme ceci : ~~~ postgres@serv:~$ /usr/lib/nagios/plugins/check_pgactivity -s streaming_delta --slave 'slave1 192.168.0.2' ~~~ -Si on a deux secondaire à surveillé : +Si on a deux secondaires à surveiller : ~~~ postgres@serv:~$ /usr/lib/nagios/plugins/check_pgactivity -s streaming_delta --slave 'slave1 192.168.0.2','slave2 192.168.0.3' ~~~ -Si sur le primaire on a aussi des slot de réplication logique, on peux les exclures du check *streaming_delta* avec l'option --exclude qui supporte les regex, dans l'exemple on part du principe que les slots de réplication logique sont nommées mysub_* : +Si sur le primaire on a aussi des slot de réplication logique, on peut les exclure du check *streaming_delta* avec l'option --exclude qui supporte les regex, dans l'exemple on part du principe que les slots de réplication logique sont nommées mysub_* : ~~~ postgres@serv:~$ /usr/lib/nagios/plugins/check_pgactivity -s streaming_delta --slave 'slave1 192.168.0.2','slave2 192.168.0.3' --exclude mysub_*