evolix/wiki
22
0
Fork 0
Code Releases Activity

précisions

Browse source
This commit is contained in:
Daniel Jakots 2017-11-12 12:04:07 -05:00
parent 6e35d60db5
commit c794c43529
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
HowtoPostgreSQL.md
View file

@ -819,6 +819,6 @@ pg_benchmark executed 30 tests in about 5 seconds
Plusieurs solutions de réplication plus ou moins avancées existent avec PostgreSQL :
* _PITR_, _Point In Time Recovery_ : copie des logs de transaction (_WAL_) sur un serveur distant pour archivage. Ils peuvent ensuite être rejoué jusqu'à un point précis en cas de perte de donnée par exemple.
* _Warm Standby_ : les _WAL_ sont copiés sur un second serveur sur lequel tourne un PostgreSQL en mode _recovery_ constant. Chaque segment reçu est rejoué par PostgreSQL. Il est alors prêt à prendre le relais en cas de panne sur le serveur maître.
* _Hot Standby_ : le principe est le même que pour le _Warm Standby_, mais le serveur esclave peut être interrogé en lecture.
* _Streaming Replication_ : ce ne sont plus les logs qui sont envoyés (qui nécessite un certain temps de propagation, car le fichier est transféré une fois plein), mais les données sont transféré immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le serveur esclave. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par esclave sur le maître pour faire tourner le processus _walsender_.
* _Warm Standby_ : les _WAL_ sont copiés sous forme d'archive sur un second serveur sur lequel tourne un PostgreSQL en mode _recovery_ constant. Chaque segment reçu est rejoué par PostgreSQL. Il est alors prêt à prendre le relais en cas de panne sur le serveur maître.
* _Hot Standby_ : le principe est le même que pour le _Warm Standby_, mais le serveur esclave peut être interrogé en lecture. Il y a néanmois une légère différence perpétuelle entre le master et le réplicat car le *WAL* est transféré seulement lorsque l'archive a fini d'être écrite.
* _Streaming Replication_ : les données sont transférées immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le serveur esclave. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par esclave sur le maître pour faire tourner le processus _walsender_. En général ce système est couplé à l'envoi des *WAL* car si le réplicat est trop en retard par rapport au master, il va lire les *WAL* jusqu'à avoir rattrapé son retard puis basculera tout seul sur la *streaming replication*