**Cette page a été importée automatiquement de notre ancien wiki mais n'a pas encore été révisée.**
## _Streaming Replication_ avec PostgreSQL
La réplication en flux (_Streaming Replication_) est disponible à partir de la version 9.0 de PostgreSQL.
Néanmoins, tout ce qui suit se rapporte à la version 9.2 (dernière en date), qui apporte plusieurs améliorations sur la réplication.
### 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 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.
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).
### Pré-requis
Pré-requis pour pouvoir mettre en place une infra avec 1 maître et 1 esclave:
* même architecture (32bits/64bits) sur les 2 serveur;
* même version majeure de PostgreSQL sur les 2 serveur (même version mineure est conseillé);
### Installation de PostgreSQL 9.2
Sous Debian Wheezy, installation depuis le dépôt Debian de PostgreSQL:
Les paquets sont maintenus par les mêmes développeurs que sur Debian et Ubuntu, et les mises à jours de sécurité/corrections de bugs y sont faites régulièrement. La raison pour laquelle le dépôt est distinct du projet Debian est dû au fait qu'il a pour but de fournir plusieurs version de PostgreSQL pour une même version de Debian.
### 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)._
Décommenter ou ajouter les directives suivantes dans le fichier _/etc/postgresql/9.2/main/postgresql.conf_:
_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._
Décommenter ou ajouter les directives suivantes dans le fichier _/etc/postgresql/9.2/main/postgresql.conf_ :
* 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:
Les données à surveiller sont notamment les _*_location_, qui indique la position courante dans les WAL à différentes étapes de la réplication.
Voir <http://www.postgresql.org/docs/9.2/static/monitoring-stats.html#PG-STAT-REPLICATION-VIEW> pour le détails des champs.
* Pour pouvoir quantifié le retard de réplication, on peut utiliser la commande [check_postgres](http://bucardo.org/check_postgres/check_postgres.pl.html) avec l'option _hot_standby_delay_:
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.
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 fichier _recovery.conf_ est renommé en _recovery.done_ pour qu'il ne soit pas lu en cas de redémarrage de PostgreSQL.
2013-04-23 05:54:15 EDT LOG: database system is ready to accept connections
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.*
#### 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.
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/reprendre le flux des WAL depuis le maître. Il ne semble pas y avoir de solution autre que de couper le flux au niveau réseau. Sur le maître:
* 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.
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.