From fd28dcb88bf4ec751bdf2864317608ea6909fb13 Mon Sep 17 00:00:00 2001 From: Daniel Jakots Date: Sun, 12 Nov 2017 12:07:38 -0500 Subject: [PATCH] =?UTF-8?q?postgresql=20a=20le=20bon=20gout=20de=20ne=20pa?= =?UTF-8?q?s=20utiliser=20le=20terminologie=20'esclave'=20mais=20r=C3=A9pl?= =?UTF-8?q?icat?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- HowtoPostgreSQL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/HowtoPostgreSQL.md b/HowtoPostgreSQL.md index 765ad15e..d0675a25 100644 --- a/HowtoPostgreSQL.md +++ b/HowtoPostgreSQL.md @@ -820,7 +820,7 @@ Plusieurs solutions de réplication plus ou moins avancées existent avec Postgr * _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 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* +* _Hot Standby_ : le principe est le même que pour le _Warm Standby_, mais le réplicat 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 réplicat. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par réplicat 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* Pour plus de détails, voir ce post sur [dba.stackexange.com](https://dba.stackexchange.com/questions/73812/postgresql-streaming-versus-file-based-replication-in-terms-of-server-behavior)