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
|
||||
~~~
|
||||
|
||||
> *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;
|
||||
~~~
|
||||
~~~
|
||||
|
|
|
@ -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 :
|
||||
|
||||
|
|
Loading…
Reference in a new issue