typos
This commit is contained in:
jlecour
parent
4cf101fd37
commit
ba3576ebcf
|
|
@ -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/<version>/<cluster> -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/<version>/<cluster>/`
|
||||
|
||||
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 <https://www.postgresql.org/docs/current/static/monitoring-stats.html#PG-STAT-REPLICATION-VIEW> 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 :
|
||||
<https://github.com/OPMDG/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_*
|
||||
|
|
|
|||
Loading…
Reference in New Issue