a wild sjw appears
This commit is contained in:
Daniel Jakots
parent
c3a35cf7df
commit
f76c0be404
|
|
@ -9,17 +9,17 @@ Néanmoins, tout ce qui suit se rapporte à la version 9.2 (dernière en date),
|
|||
|
||||
### Caractéristiques
|
||||
|
||||
* Réplication de type asynchrone (le maître et l'esclave 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é à l'esclave) ;
|
||||
* Réplication de type asynchrone (le maître et le réplicat 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 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 d'esclave ne peut être interrogé qu'en lecture ;
|
||||
* possibilité de mettre en cascade plusieurs esclaves.
|
||||
* le serveur jouant le rôle de réplicat ne peut être interrogé qu'en lecture ;
|
||||
* possibilité de mettre en cascade plusieurs réplicats.
|
||||
|
||||
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 communiquer au serveur esclave. À 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 communiquer au serveur réplicat. À 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 esclave :
|
||||
Pré-requis pour pouvoir mettre en place une infra avec 1 maître et 1 réplicat :
|
||||
|
||||
* même architecture (32 bits/64 bits) sur les 2 serveur ;
|
||||
* même version majeure de PostgreSQL sur les 2 serveur (même version mineure est conseillé) ;
|
||||
|
|
@ -42,22 +42,22 @@ Les paquets sont maintenus par les mêmes développeurs que sur Debian et Ubuntu
|
|||
|
||||
### Configuration du serveur maître
|
||||
|
||||
_Cette configuration est relative au serveur maître, mais elle doit également être reprise à l'identique sur le serveur esclave, dans le cas où les rôles doivent être échangés (suite à un failover/switchover)._
|
||||
_Cette configuration est relative au serveur maître, mais elle doit également être reprise à l'identique sur le serveur réplicat, dans le cas où les rôles doivent être échangés (suite à un failover/switchover)._
|
||||
|
||||
Décommenter ou ajouter les directives suivantes dans le fichier _/etc/postgresql/9.2/main/postgresql.conf_ :
|
||||
|
||||
~~~
|
||||
# Nécessaire pour que l'esclave puisse se connecter.
|
||||
# Nécessaire pour que le réplicat puisse se connecter.
|
||||
listen_addresses = '*'
|
||||
|
||||
# Nombre maximum de processus walsender à lancer (mettre au moins le même
|
||||
# nombre que de serveur esclave qui se connecteront dessus + 1 (reconnexions,
|
||||
# nombre que de serveur réplicat qui se connecteront dessus + 1 (reconnexions,
|
||||
# maintenance...).
|
||||
# (1 processus = 1 connexion)
|
||||
max_wal_senders = 2
|
||||
|
||||
# « niveau de verbosité » des journaux PostgreSQL. Le niveau maximum est
|
||||
# nécessaire (hot_standby) pour que l'esclave soit accessible en lecture.
|
||||
# nécessaire (hot_standby) pour que le réplicat soit accessible en lecture.
|
||||
wal_level = hot_standby
|
||||
|
||||
# Activation de l'archivage des WAL. Nécessaire pour pouvoir remettre en
|
||||
|
|
@ -72,20 +72,20 @@ Créer un utilisateur dédié pour la réplication :
|
|||
postgres=# CREATE ROLE repl WITH LOGIN REPLICATION PASSWORD 'xxxxxxxx';
|
||||
~~~
|
||||
|
||||
Autoriser le serveur esclave à se connecter au maître :
|
||||
Autoriser le serveur réplicat à se connecter au maître :
|
||||
|
||||
~~~
|
||||
hostssl replication repl 192.0.2.2/32 md5
|
||||
~~~
|
||||
|
||||
### Configuration du serveur esclave
|
||||
### Configuration du serveur réplicat
|
||||
|
||||
_Cette configuration est relative au serveur esclave, 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._
|
||||
_Cette configuration est relative au serveur réplicat, 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._
|
||||
|
||||
Décommenter ou ajouter les directives suivantes dans le fichier _/etc/postgresql/9.2/main/postgresql.conf_ :
|
||||
|
||||
~~~
|
||||
# Le serveur est en mode esclave en lecture seule
|
||||
# Le serveur est en mode réplicat en lecture seule
|
||||
hot_standby = on
|
||||
~~~
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ Créer un fichier _recovery.conf_ avec les info suivantes :
|
|||
> recovery_target_timeline = 'latest'" >~postgres/9.2/main/recovery.conf
|
||||
~~~
|
||||
|
||||
Il est nécessaire que ce fichier appartiennent à l'utilisateur _postgres_, notamment pour le [#Passerunserveuresclaveenmaître failover] :
|
||||
Il est nécessaire que ce fichier appartiennent à l'utilisateur _postgres_, notamment pour le [#Passerunserveurréplicatenmaître failover] :
|
||||
|
||||
~~~
|
||||
# chown postgres:postgres ~postgres/9.2/main/recovery.conf
|
||||
|
|
@ -106,14 +106,14 @@ Il est nécessaire que ce fichier appartiennent à l'utilisateur _postgres_, not
|
|||
|
||||
### Synchronisation initiale des données
|
||||
|
||||
* Arrêter PostgreSQL sur l'esclave ;
|
||||
* Arrêter PostgreSQL sur le réplicat ;
|
||||
* sur le maître, indiquer à PostgreSQL qu'on commence une sauvegarde. Il va notamment faire un checkpoint dans son WAL courant et retourner sa position :
|
||||
|
||||
~~~
|
||||
postgres$ psql -c "SELECT pg_start_backup('synchro initiale')"
|
||||
~~~
|
||||
|
||||
* lancer le rsync du datadir vers l'esclave :
|
||||
* lancer le rsync du datadir vers le réplicat :
|
||||
|
||||
~~~
|
||||
# rsync -avz --delete --exclude /pg_xlog/* --exclude /postmaster.* --exclude /recovery.* ~postgres/9.2/main/ 192.0.2.2:~postgres/9.2/main/
|
||||
|
|
@ -125,7 +125,7 @@ postgres$ psql -c "SELECT pg_start_backup('synchro initiale')"
|
|||
postgres$ psql -c "SELECT pg_stop_backup()"
|
||||
~~~
|
||||
|
||||
* redémarrer PostgreSQL sur l'esclave.
|
||||
* redémarrer PostgreSQL sur le réplicat.
|
||||
|
||||
### Administration
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ postgres$ psql -c "SELECT pg_stop_backup()"
|
|||
|
||||
Plusieurs possibilité pour surveiller la réplication :
|
||||
|
||||
* Voir la position courante dans les logs sur le maître et l'esclave (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éplicat (on peut en déduire si ils sont synchro ou pas) :
|
||||
|
||||
~~~
|
||||
# pgrep -lf "wal (sender|receiver) process"
|
||||
|
|
@ -171,9 +171,9 @@ $ check_postgres --action=hot_standby_delay --dbhost=localhost --dbport=5432 --
|
|||
POSTGRES_HOT_STANDBY_DELAY OK: DB "template1" (host:192.0.2.2) 0 | time=0.09s replay_delay=12568;500000;1000000 receive-delay=8192;500000;1000000
|
||||
~~~
|
||||
|
||||
Où localhost est le maître et 192.0.2.2 l'esclave. Les valeurs de _replay_delay_ et _receive-delay_ sont *à priori* exprimées en octets de WAL à rejouer.
|
||||
Où localhost est le maître et 192.0.2.2 le réplicat. Les valeurs de _replay_delay_ et _receive-delay_ sont *à priori* exprimées en octets de WAL à rejouer.
|
||||
|
||||
#### Passer un serveur esclave en maître
|
||||
#### Passer un serveur réplicat en maître
|
||||
|
||||
Si le maître est toujours joignable, éteindre PostgreSQL en forçant la déconnexion des clients :
|
||||
|
||||
|
|
@ -181,13 +181,13 @@ Si le maître est toujours joignable, éteindre PostgreSQL en forçant la décon
|
|||
# pg_ctlcluster 9.2 main stop -- -m fast
|
||||
~~~
|
||||
|
||||
Sur l'esclave, faire en sorte que PostgreSQL accepte les connexions en écriture :
|
||||
Sur le réplicat, faire en sorte que PostgreSQL accepte les connexions en écriture :
|
||||
|
||||
~~~
|
||||
# pg_ctlcluster 9.2 main promote
|
||||
~~~
|
||||
|
||||
L'esclave va d'abord rattraper son éventuel retard dans le traitement des logs de réplication, puis une fois prêt se mettra à accepter les requêtes en écritures.
|
||||
Le réplicat va d'abord rattraper son éventuel retard dans le traitement des logs de réplication, puis une fois prêt se mettra à accepter les requêtes en écritures.
|
||||
|
||||
Le fichier _recovery.conf_ est renommé en _recovery.done_ pour qu'il ne soit pas lu en cas de redémarrage de PostgreSQL.
|
||||
|
||||
|
|
@ -203,17 +203,17 @@ Messages de PostgreSQL lors du passage en maître :
|
|||
2013-04-23 05:54:15 EDT LOG: autovacuum launcher started
|
||||
~~~
|
||||
|
||||
*ATTENTION : à partir du moment où l'esclave cesse de lire les journaux du maître, toutes les écritures qui continuent de se faire sur le maître seront perdues. Il faut donc être certain que le maître soit réellement inaccessible avant de faire la bascule.*
|
||||
*ATTENTION : à partir du moment où le réplicat cesse de lire les journaux du maître, toutes les écritures qui continuent de se faire sur le maître seront perdues. Il faut donc être certain que le maître soit réellement inaccessible avant de faire la bascule.*
|
||||
|
||||
#### Rétablissement de la réplication après un failover
|
||||
|
||||
État courant : le serveur esclave accepte les écritures suite à la procédure de failover, et le serveur maître contient des données obsolètes car pas mises à jour.
|
||||
État courant : le serveur réplicat accepte les écritures suite à la procédure de failover, et le serveur maître contient des données obsolètes car pas mises à jour.
|
||||
|
||||
Il faut alors mettre en place le _recovery.conf_ sur l'ancien master et démarrer PostgreSQL. Il va alors rejouer les WAL pour rattraper le retard accumulé, puis se mettre en mettre en mode _streaming replication_.
|
||||
|
||||
#### Arrêter la réplication
|
||||
|
||||
* Arrêter/reprendre le "replay" des WAL sur l'esclave :
|
||||
* Arrêter/reprendre le "replay" des WAL sur le réplicat :
|
||||
|
||||
~~~
|
||||
postgres=# SELECT pg_xlog_replay_pause();
|
||||
|
|
@ -229,6 +229,6 @@ postgres=# SELECT pg_xlog_replay_resume();
|
|||
|
||||
### Diverses notes/spécificités de la réplication
|
||||
|
||||
* Si une requête sur le serveur esclave bloque la réplication (par exemple un `SELECT` qui bloque un `DROP TABLE`) pendant un temps trop long, la requête sur l'esclave sera tuée (ici le SELECT). Ce temps est définit par la directive `max_standby_streaming_delay` sur la configuration de l'esclave.
|
||||
* Si une requête sur le serveur réplicat bloque la réplication (par exemple un `SELECT` qui bloque un `DROP TABLE`) pendant un temps trop long, la requête sur le réplicat sera tuée (ici le SELECT). Ce temps est définit par la directive `max_standby_streaming_delay` sur la configuration du réplicat.
|
||||
|
||||
Ce comportement peut-être désactivé grâce à la directive `hot_standby_feedback`, qui fait en sorte que l'esclave communique l'état des requêtes au maître, mais cela à un impact sur le maître.
|
||||
Ce comportement peut-être désactivé grâce à la directive `hot_standby_feedback`, qui fait en sorte que le réplicat communique l'état des requêtes au maître, mais cela à un impact sur le maître.
|
||||
|
|
|
|||
Loading…
Reference in a new issue