evolix/wiki
22
0
Fork 0
Code Releases Activity

HowtoPostgreSQL: tfix

Browse source
This commit is contained in:
David Prevot 2024-02-20 15:20:30 +01:00
parent 5ce50e4424
commit 59497af0d4
2 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
HowtoPostgreSQL.md
View file

@ -230,7 +230,7 @@ Pour se connecter plus facilement à postgresql (avec `psql` mais aussi `pgdump`
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
@ -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;
~~~
~~~

16
HowtoPostgreSQL/ReplicationPhysique.md
View file

@ -6,17 +6,17 @@ La réplication en flux (_Streaming Replication_) est disponible à partir de la
## 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 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 ;
* 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).
## 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 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 ;
* 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.
* Créé le fichier .pgpass
* 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éer le fichier .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_
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`
@ -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');
~~~
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'
@ -194,7 +194,7 @@ Pour supprimer un slot de réplication :
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 :