titre plus gros pour fix link
This commit is contained in:
Daniel Jakots
parent
183f4127e6
commit
7c8bb00726
|
|
@ -1,8 +1,8 @@
|
|||
## _Streaming Replication_ avec PostgreSQL
|
||||
# _Streaming Replication_ avec PostgreSQL
|
||||
|
||||
La réplication en flux (_Streaming Replication_) est disponible à partir de la version 9.0 de PostgreSQL. Celle-ci est différente de la réplication logique apparue dans la version 10.
|
||||
|
||||
### Caractéristiques
|
||||
## Caractéristiques
|
||||
|
||||
* 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_) ;
|
||||
|
|
@ -12,18 +12,18 @@ La réplication en flux (_Streaming Replication_) est disponible à partir de la
|
|||
|
||||
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
|
||||
|
||||
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 (et même version mineure est conseillé) ;
|
||||
|
||||
### Installation de PostgreSQL
|
||||
## Installation de PostgreSQL
|
||||
|
||||
Voir la documentation présente sur la page principale <https://wiki.evolix.org/HowtoPostgreSQL#installation>
|
||||
|
||||
### Configuration du serveur maître
|
||||
## Configuration du serveur maître
|
||||
|
||||
_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)._
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ Autoriser le serveur réplicat à se connecter au maître :
|
|||
hostssl replication repl 192.0.2.2/32 md5
|
||||
~~~
|
||||
|
||||
### Configuration du serveur réplicat
|
||||
## Configuration du serveur réplicat
|
||||
|
||||
_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._
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ Il est nécessaire que ce fichier appartiennent à l'utilisateur _postgres_, not
|
|||
# chown postgres:postgres ~postgres/9.X/main/recovery.conf
|
||||
~~~
|
||||
|
||||
### Synchronisation initiale des données
|
||||
## Synchronisation initiale des données
|
||||
|
||||
* 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 :
|
||||
|
|
@ -110,9 +110,9 @@ postgres$ psql -c "SELECT pg_stop_backup()"
|
|||
|
||||
* redémarrer PostgreSQL sur le réplicat.
|
||||
|
||||
### Administration
|
||||
## Administration
|
||||
|
||||
#### Monitoring
|
||||
### Monitoring
|
||||
|
||||
Plusieurs possibilité pour surveiller la réplication :
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ 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éplicat. Les valeurs de _replay_delay_ et _receive-delay_ sont *à priori* exprimées en octets de WAL à rejouer.
|
||||
|
||||
#### Passer un serveur réplicat 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 :
|
||||
|
||||
|
|
@ -188,13 +188,13 @@ Messages de PostgreSQL lors du passage en maître :
|
|||
|
||||
*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
|
||||
### Rétablissement de la réplication après un failover
|
||||
|
||||
É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 la réplication
|
||||
|
||||
* Arrêter/reprendre le "replay" des WAL sur le réplicat :
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ postgres=# SELECT pg_xlog_replay_resume();
|
|||
# iptables -D INPUT 1
|
||||
~~~
|
||||
|
||||
### Diverses notes/spécificités de la réplication
|
||||
## Diverses notes/spécificités de la réplication
|
||||
|
||||
* 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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue