HowtoPostgreSQL: tfix
This commit is contained in:
parent
5ce50e4424
commit
59497af0d4
|
@ -230,7 +230,7 @@ Pour se connecter plus facilement à postgresql (avec `psql` mais aussi `pgdump`
|
||||||
hostname:port:database:username:password
|
hostname:port:database:username:password
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
> *Note* : Ce fichier doit avoir des droits en _600_ et on peux utilisé des wilcards '*' pour autorisés le ou les champs souhaitez.
|
> *Note* : Ce fichier doit avoir des droits en _600_ et on peux utiliser des wilcards '*' pour autoriser le ou les champs souhaités.
|
||||||
|
|
||||||
### Fichier .pg_service.conf
|
### Fichier .pg_service.conf
|
||||||
|
|
||||||
|
@ -1542,4 +1542,4 @@ Pour connaitre l'OID de chaque base on peux exécuter cette requête dans le she
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
postgres=# SELECT oid,* from pg_database;
|
postgres=# SELECT oid,* from pg_database;
|
||||||
~~~
|
~~~
|
||||||
|
|
|
@ -6,17 +6,17 @@ La réplication en flux (_Streaming Replication_) est disponible à partir de la
|
||||||
|
|
||||||
## Caractéristiques
|
## Caractéristiques
|
||||||
|
|
||||||
* Réplication de type asynchrone (le maître et le réplica peuvent ne pas être synchro à un instant _t_) ou synchrone (une transaction est commitée uniquement si elle a pu être écrite sur le maître et envoyé au réplicat) ;
|
* Réplication de type asynchrone (le maître et le réplica peuvent ne pas être synchro à un instant _t_) ou synchrone (une transaction est commitée uniquement si elle a pu être écrite sur le maître et envoyé au réplica) ;
|
||||||
* réplication basée sur les journaux binaires générés par PostgreSQL (WAL, pour _Write Ahead Log_) ;
|
* réplication basée sur les journaux binaires générés par PostgreSQL (WAL, pour _Write Ahead Log_) ;
|
||||||
* réplication de l'intégralité des données et structures (toutes les bases de données sont répliquées, avec leurs tables et leurs données, pas de granularité possible). Cette fonctionnalité commencera à être introduite à partir de la 9.3 ;
|
* réplication de l'intégralité des données et structures (toutes les bases de données sont répliquées, avec leurs tables et leurs données, pas de granularité possible). Cette fonctionnalité commencera à être introduite à partir de la 9.3 ;
|
||||||
* le serveur jouant le rôle de réplica ne peut être interrogé qu'en lecture ;
|
* le serveur jouant le rôle de réplica ne peut être interrogé qu'en lecture ;
|
||||||
* possibilité de mettre en cascade plusieurs réplicats.
|
* possibilité de mettre en cascade plusieurs réplicas.
|
||||||
|
|
||||||
Par rapport au mode de réplication _Hot Standby_, l'avantage avec la réplication en flux est qu'il n'est pas besoin d'attendre qu'un journal soit plein et fermé pour qu'il soit communiqué au serveur réplica. À l'inverse cela introduit une légère charge supplémentaire (au niveau CPU) puisqu'un (ou plusieurs) processus supplémentaire doit tourner sur le maître (wal_senders).
|
Par rapport au mode de réplication _Hot Standby_, l'avantage avec la réplication en flux est qu'il n'est pas besoin d'attendre qu'un journal soit plein et fermé pour qu'il soit communiqué au serveur réplica. À l'inverse cela introduit une légère charge supplémentaire (au niveau CPU) puisqu'un (ou plusieurs) processus supplémentaire doit tourner sur le maître (wal_senders).
|
||||||
|
|
||||||
## Pré-requis
|
## Pré-requis
|
||||||
|
|
||||||
Pré-requis pour pouvoir mettre en place une infra avec 1 maître et 1 réplicat :
|
Prérequis pour pouvoir mettre en place une infra avec 1 maître et 1 réplica :
|
||||||
|
|
||||||
* même architecture (32 ou 64 bits) sur les 2 serveurs ;
|
* même architecture (32 ou 64 bits) sur les 2 serveurs ;
|
||||||
* même version majeure de PostgreSQL sur les 2 serveurs (et même version mineure est conseillé) ;
|
* même version majeure de PostgreSQL sur les 2 serveurs (et même version mineure est conseillé) ;
|
||||||
|
@ -127,8 +127,8 @@ postgres$ psql -c "SELECT pg_stop_backup()"
|
||||||
|
|
||||||
* Arrêter PostgreSQL sur le réplica ;
|
* Arrêter PostgreSQL sur le réplica ;
|
||||||
* Supprimer le contenu de `/var/lib/postgresql/<version>/<cluster>/*`
|
* Supprimer le contenu de `/var/lib/postgresql/<version>/<cluster>/*`
|
||||||
* Autorisé la connexion SSH par clé, de l'utilisateur postgres depuis le master vers le réplica, et également depuis le réplica vers le master.
|
* Autoriser la connexion SSH par clé, de l'utilisateur postgres depuis le master vers le réplica, et également depuis le réplica vers le master.
|
||||||
* Créé le fichier .pgpass
|
* Créer le fichier .pgpass
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
postgres@$: echo "*:*:*:repl:mypass" > .pgpass
|
postgres@$: echo "*:*:*:repl:mypass" > .pgpass
|
||||||
|
@ -146,7 +146,7 @@ L'option `-R` s'occupe de créer le fichier recovery.conf (ou postgresql.auto.co
|
||||||
|
|
||||||
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_
|
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 peut 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 à synchroniser les données.
|
||||||
|
|
||||||
Si on veut forcer un checkpoint sur le primaire, on peut utiliser 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`
|
||||||
|
|
||||||
|
@ -178,7 +178,7 @@ Pour éviter qu'il y ait un décrochage entre le primaire et le secondaire, dans
|
||||||
postgres=# SELECT pg_create_physical_replication_slot('nom_du_secondaire');
|
postgres=# SELECT pg_create_physical_replication_slot('nom_du_secondaire');
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
Sur le secondaire, on rajoute la variable *primary_slot_name* dans le fichier recovery.conf (version <=11) ou postgresql.conf en v12 avec la mention du slot a utilisé :
|
Sur le secondaire, on rajoute la variable *primary_slot_name* dans le fichier recovery.conf (version <=11) ou postgresql.conf en v12 avec la mention du slot à utiliser :
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
primary_slot_name = 'nom_du_secondaire'
|
primary_slot_name = 'nom_du_secondaire'
|
||||||
|
@ -194,7 +194,7 @@ Pour supprimer un slot de réplication :
|
||||||
postgres=# SELECT pg_drop_replication_slot ('nom_du_secondaire');
|
postgres=# SELECT pg_drop_replication_slot ('nom_du_secondaire');
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
Il est donc impératif de supprimer un slot de réplication si le secondaire a été désactivé ou hors ligne un certain temps, quitte à devoir reconstruire le secondaire complétement.
|
Il est donc impératif de supprimer un slot de réplication si le secondaire a été désactivé ou hors ligne un certain temps, quitte à devoir reconstruire le secondaire complètement.
|
||||||
|
|
||||||
Pour listés tous les slots de réplication active sur un serveur, que ce soit des slots physique ou logique, on peux le faire avec la requête suivante :
|
Pour listés tous les slots de réplication active sur un serveur, que ce soit des slots physique ou logique, on peux le faire avec la requête suivante :
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue