Streaming-Replikation und Failover unter PostgreSQL

Ich mache einen Proof-of-Concept für die PostgreSQL-Replikation. Nach der Diskussion im Forum haben wir uns für die Streaming-Replikation entschieden, da die Leistung im Vergleich zu anderen Lösungen gut ist. PostgreSQL bietet kein automatisches Failover für die Streaming-Replikation. Wir können den Slave mit einer Trigger-Datei auf Master umstellen, aber es ist nicht verwaltbar. Ich hätte gerne eine Lösung mit automatischem Failover und hoher Verfügbarkeit.

Es stehen verschiedene Lösungen zur Verfügung:

1. Repmgr
2. Linux-Herzschlag
3. Pgpool-II (nur für automatisches Failover)
4. Jedes andere Werkzeug, falls Sie es benutzt haben.

Meine Frage ist, welche Lösung verwendet werden soll?

In unserem Shop haben wir statt pgpool repmgr und pgbouncer ausgewählt. repmgr verfügt über einige nützliche Tools zum Einrichten und Verwalten des Clusters replizierter Datenbankserver. In unserem Fall 1 Master und 2 Slaves (ein Failover- und ein Live-Read-Leistungstest, der zum Failover des neuen Masters werden kann). pgpool hat Probleme mit Änderungen in der Konfiguration. In den meisten Fällen müssen Sie den Dienst neu starten und haben daher einige Ausfallzeiten. Dies ist ein Problem, wenn Sie eine Verfügbarkeit von 24x7x365 benötigen.

repmgrd (der Deamon) hilft bei der Auswahl des neuen Masters nach einem Failover. Sie möchten wirklich keine Split-Brain-Situation. Wir haben eine virtuelle IP-Adresse für die Master-Datenbank, die Datenbank, die im Moment Master ist. Wenn ein anderer Server Master wird, ist dies der einzige Server, der diese Adresse verwendet. Jeder Datenbankserver hat auch eine eigene IP-Adresse für schreibgeschützte Abfragen.

repmgr wird von denselben Leuten gepflegt, die in erster Linie Streaming-Replikationen erstellt haben, damit sie wissen, worüber sie sprechen. Version 2.0 wird veröffentlicht.

Bereiten Sie sich auf die schlimmste Situation vor und führen Sie einige ernsthafte Tests durch, indem Sie Netz- und Netzwerkstecker ziehen! Wenn etwas schief geht, sind viele andere Dinge bereits schief gegangen und werden Sie in den Rücken beißen, wenn Sie es sich nicht leisten können.

Replikation ist eine Sache, ein funktionierendes Failover nach einigen schwerwiegenden Problemen ist eine andere Sache.

Wir verwenden zwei verschiedene Lösungen gleichzeitig in Kombination ...

Pgpool-II für die synchrone Replikation und Slony2 für die asynchrone (ausgelöste) Replikation.

Die Leistung ist ausgezeichnet