PostgreSQL Failover und Replikation

Ich bewerte PostgreSQL 9.1 und habe einige Fragen zu Failover- und Replikationsdetails.

Ich habe einige Testszenarien. Erste mit einem Master-Server und wenigen Slaves. Für den Fall, dass der Master abstürzt, möchte ich, dass einer der Slaves ein Master wird. Nachdem der Master wieder in den Normalzustand zurückgekehrt ist, sollte er sich mit anderen Servern im Cluster synchronisieren (alle während des Ausfalls vorgenommenen Änderungen übernehmen) und die Master-Rolle zurückfordern oder Slave werden.

Die Probleme, die ich mit PostgreSQL und dem aktuellen Szenario sehe, sind die folgenden.

1) Ich sehe keine integrierten Tools zum Erkennen von Master-Server-Ausfällen. Ich habe gelesen, dass pgpool damit umgehen und eine Triggerdatei erstellen kann. Ich habe auch gelesen, dass Leute Linux Heartbeat oder ähnliche Tools dafür verwenden. Okay, ich kann Failover erkennen und einen neuen Master im Cluster zuweisen. Werden die anderen Slaves verstehen, dass es einen neuen Master gibt und sie sollten ihn jetzt sichern?

2) Ich verstehe das Failback-Verfahren nicht. Master- und Slave-Host-Konfigurationen sind unterschiedlich. Habe ich nach einem Absturz des Master-Failbacks zwei Master? Wie werden die Server wieder synchronisiert? Ich sah nur manuelle Lösungen wie "Datenordner auf Server übertragen und neu starten". Was ist hier also die Lösung oder die beste Vorgehensweise oder zumindest das wichtigste Prinzip?

3) Wie soll ich mit Serverausfällen auf der Clientseite umgehen? Wenn ich eine Verbindung herstelle, gebe ich explizit die Server-IP an. Sollte ich eine Art ConnectionManager entwickeln, der meine Master-Slave-Struktur kennt, Anforderungen nur an den Master senden und im Falle eines Verbindungsverlusts auf Sicherungsserver usw. wechseln? Ich habe gelesen, dass pgpool ein Einstiegspunkt für Anwendungen sein und Verbindungen korrekt verwalten kann. Ist pgpool hier die einzige Lösung? Behandelt es Failover und Failback gut?

4) Gibt es (auch kommerzielle) Lösungen, mit denen ich vermeiden könnte, die Daten manuell zu kopieren, PostgreSQL-Instanzen und andere Dinge, die von Hand gemacht werden sollten, neu zu konfigurieren? So eine Art Cluster-Konfiguration, wenn alle synchronisiert sind, ist es klar, wer Master ist und alles schaltet automatisch um, ohne dass der Bediener darauf achtet?

Nach diesen Themen und Artikeln

Streaming-Replikation und Failover unter PostgreSQL

Automatisieren des Failovers in PostgreSQL 9.1

http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html

Es gibt keine einzige vollautomatische Lösung, um diese Fragen zu lösen. Habe ich recht?

Vielen Dank!

1. Sklaven werden keinen neuen Meister verstehen. Sie sollten das manuell tun.

2. Ja, sie unterscheiden sich und Sie sollten neue für den alten Master erstellen. Der alte Standby-Modus funktioniert jedoch weiterhin als Master, aber Sie sollten max_wal_senders für diesen Knoten festlegen. Sie sollten auch pg_hba.conf des neuen Masters nach dem Failover festlegen. Nach dem Failover (wenn Knoten die Rollen Master -> Slave Slave -> Master wechseln) sollten Sie neue WAL-Dateien in ein neues Datenverzeichnis für Standby-Ordner übertragen, das Sie in der Datei recovery.conf festgelegt haben. oder einfach mit rsync.

3. Möglicherweise können Sie pgbouncer verwenden. auf diese weise änderst du einfach die pgbouncer server adres auf new master.

4. EnterpriseDB verfügt über einige kommerzielle Tools. Vielleicht können Sie sie überprüfen.

und schließlich hast du ja recht. Es gibt keine einzige vollautomatische Lösung, um diese Fragen zu lösen.