Slony und PGPool für Failover

Das ist anekdotisch, also nehmen Sie es mit einem Körnchen Salz.

Die PGPool- und Streaming-WAL-Replikation (mit Hot Standby oder nicht) funktioniert so, wie es bei der Datenbankreplikation der Fall ist. Ihre Anwendung muss nichts über die Replikation wissen, oder ob sie Teil eines Clusters ist oder nicht, sie kommuniziert nur mit der Datenbank wie mit jeder anderen. Die Streaming-Replikation ist robust und kann bei Ausfall des Streamings auf den WAL-Versand zurückfallen. PGPool vereinfacht die Verwaltung dieses Prozesses und liefert gute Herzschläge und Überwachungsinformationen.

Slony dagegen ist ein administratives Tar-Pit, das Ihrer Datenbank Triggerfunktionen und zahlreiche andere Objekte hinzufügen muss, um zu funktionieren. Darüber hinaus unterstützt Slony (einfach) nicht die Fähigkeit, Schemaänderungen (DDL) zu replizieren, genauso wie es gewöhnliche Operationen zum Einfügen / Aktualisieren / Löschen (DML) repliziert. Insgesamt bedeutet dies, dass Ihre Anwendung in vielen Fällen spezielle Fälle benötigt, um mit Slony's Exzentrizitäten umgehen zu können. Meiner Meinung nach ist das schlecht: Die Anwendung sollte sich nicht bewusst sein / Änderungen vornehmen müssen, um mit der Datenbankreplikationslösung, auf der sie ausgeführt wird, umgehen zu können. Ich verbrachte die meiste Zeit eines Jahres damit, Slony zu hacken, um als stabile Replikationslösung zu arbeiten, und kam schließlich zu dem Schluss, dass es eine schlechte Idee / schlechte Replikationsmechanik auf stumpfer, unleserlicher Weise ist, die alles andere als stabil oder unternehmensbereit ist . BEARBEITEN: Ab PostgreSQL 9.3 können Sie Trigger (mit denen Slony Änderungen erkennt) auf DDL-Objekten installieren, wodurch Slony möglicherweise mehr Aspekte einer Datenbank repliziert.

Das heißt, Slony tut zwei Dinge besser als Streaming-Replikation (über PGPool oder nicht verwaltet):

• Slony ermöglicht die Replikation pro Tabelle oder pro Datenbank. Die Streaming-Replikation ermöglicht nur die Replikation einer gesamten Postgres-Instanz. Wenn diese Granularität für Sie wichtig ist, möchten Sie vielleicht Slony.
• Slony ermöglicht die Kaskadierung (Master - & gt; Slave - & gt; Slave) Replikation. Streaming-Replikation ermöglicht nur eine Ebene. BEARBEITEN: Dies wird jetzt in PostgreSQL nativ unterstützt Streaming-Replikation ab Postgres Version 9.2.

Im wahrsten Sinne des Wortes ist Streaming-Replikation besser und stabiler.

Aber Sie fragen nicht nur nach Streaming-Replikation: PGPool leistet noch viel mehr. Es ermöglicht das Ausgleichen von Lese- und Schreiblasten zwischen schreibgeschützten Slave-Datenbanken und Mastern und die Implementierung von Backup-Plänen sowie eine ganze Reihe anderer Dinge. Besonders im Vergleich zu Slony's arkanen Befehlssyntax und gottlosen Verwaltungsskripten gewinnt PGPool in fast jeder Instanz.

Speziell im Hinblick auf Failover verfügt PGPool über Heartbeat-Monitore und die Möglichkeit, den Datenverkehr in einem Cluster automatisch zu routen. Slony hat nur einen Befehl "Fail over to slave now" und überlässt Ihnen den gesamten Monitoring- und App-Side-Routing-Prozess.

TL; DR: PGPool gut. Slony schlecht.