Hochverfügbarkeit für postgresql

Ich bin neu in der PostgreSQL-Datenbank. Vor kurzem musste unser Entwickler einige Upgrades in unseren Systemen durchführen.

Aus diesem Grund planen wir die Implementierung einer Methode zur Implementierung eines Datenbank-Failovers.

Basierend auf meiner Lektüre aus dem Postgresql-Wiki hier versuchen wir, entweder Warm Standby oder Hot Standby zu implementieren. Meine Fragen sind also:

Was sind die Hauptunterschiede zwischen ihnen?
Welches ist besser?
Gibt es eine andere Methode, die wir in Betracht ziehen können, um eine hohe Verfügbarkeit in unseren Postgres-Datenbanken zu erreichen?

postgresql linux high-availability

— user119720
quelle

Ein korrektes Heartbeat + STONITH-Setup ist der Schlüssel, wenn Sie ein automatisches Failover verwenden möchten. Ein automatisiertes Failover mit manuellem Auslöser ist möglicherweise sicherer. Siehe auch wiki.postgresql.org/wiki/High_Availability

— Craig Ringer

@CraigRinger danke. Ich werde das untersuchen. Aber was ist eigentlich der warme und heiße Standby? Kannst du ein paar Details geben?

— user119720

Antworten:

1a. Warm Standby ist eine inkrementelle "Live" -Sicherung mit vollständigen Änderungsblöcken (Wal-Segmente) von jeweils 16 MB, die nach dem Befüllen an den Standby-Knoten gesendet werden. Sie können keinen warmen Standby-Knoten abfragen. 16 MB Änderungen (standardmäßig) können viele Transaktionen bedeuten. Sollte der Master ausfallen, gehen sie verloren.

1b. Hot Standby . (auch eine inkrementelle "Live" -Sicherung). Kleine Änderungen werden an den Slave gesendet (Wal-Datensätze, die winzige Teile eines Wal-Segments sind). Sie können den Hot-Standby-Knoten abfragen (schreibgeschützt). Das Fenster für verlorene Transaktionen, falls der Master ausfällt, ist sehr klein. Es gibt synchrone und asynchrone Hot-Standby-Knoten. Ein synchroner Knoten zwingt den Master, darauf zu warten, dass er die Anwendung von Änderungen bestätigt, und der Master schreibt die Transaktion fest. Bei der asynchronen Replikation sendet der Master die Wal-Datensätze und wartet nicht auf die Bestätigung . Ersteres erfordert eine sehr zuverlässige und schnelle Verbindung zwischen dem Master und dem Slave, erhöht auch den Overhead für den Master, garantiert jedoch keinen Datenverlust.

Inkrementelle Sicherungen: 1. Sie erstellen eine Basiskopie Ihrer gesamten Datenbankinstallation. 2. Versende es an den Slave. 3. Konfigurieren Sie es so, dass Änderungen nachgeholt werden.

Streaming Replication (Hot Standby) ist hier der Gewinner. Ich persönlich bevorzuge die asynchrone Replikation, da dies den Master nicht erheblich belastet und die Replikationsverzögerung sehr gering ist (in vielen Fällen einige Sekunden).

Eine Ergänzung zu diesem Setup ist pg-pool. Es fungiert als Proxy zwischen der Anwendung und den Servern, die an einer Replikationskonfiguration wie der oben beschriebenen teilnehmen. Es verfügt über Funktionen zum Lastenausgleich und zur parallelen Abfrage. Es ist auch in der Lage, ein automatisches Failover bereitzustellen. http://www.pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— Rene Romero Benavides
quelle

Ich freue mich sehr über Ihre schnelle Antwort, die für meine Anforderungen sehr hilfreich ist. Können Sie mir bitte auch die richtigen Links empfehlen, um dieses Setup zu erreichen?

— user119720

Schauen Sie doch mal hier vorbei: [link] pgpool.net/pgpool-web/contrib_docs/simple_sr_setting/index.html

— Rene Romero Benavides

Gern geschehen. Die Lernkurve in diesen Angelegenheiten ist ziemlich steil, seien Sie einfach geduldig. Gute Nacht (Tag oder was auch immer) Grüße aus Mexiko-Stadt.

— Rene Romero Benavides

Ich habe einige Recherchen basierend auf Ihren Links durchgeführt und es gibt Fragen, die mir in den Sinn gekommen sind. 1. Kann Warm Standby für die Streaming-Replikation konfiguriert werden? 2. Kann pg-pool für Warm Standby konfiguriert werden? 3. Wenn wir unseren Apps-Server-Point während des Failovers auf unsere Primärdatenbank konfiguriert haben, müssen wir die Datenbankkonfiguration des Apps-Servers in die Slave-Datenbank ändern, oder fungiert der PG-Pool selbst als Proxy für den Slave? Entschuldigung für die Mühe. Hoffentlich macht es Ihnen nichts aus.

— user119720

Die Antwort, die Sie bereits erhalten haben, ist nützlich, aber hier etwas verwirrend. Alle integrierten Replikationslösungen verwenden denselben grundlegenden Mechanismus: Kopieren von Write-Ahead-Protokolldaten auf einen Standby-Server.

Sie können diese WAL-Daten für die Replikation entweder um jeweils 16 MB mithilfe der Funktion archive_command oder mithilfe der Streaming Replication (SR) verschieben. Wenn Sie SR verwenden, sollten Sie auch die Archivierung einrichten, und der Server wechselt entsprechend zwischen ihnen.

Sie können einen warmen Standby-Server haben, der keine Anfragen beantworten kann. Oder Sie haben einen Hot-Standby-Server, der schreibgeschützte beantworten kann. Dies hängt nicht damit zusammen, wie die Daten in den Standby-Modus gelangen.

Jede dieser beiden Optionen wird mit den anderen kombiniert, und Sie können alle vier Kombinationen verwenden. Sie können einen Hot Standby haben, der Anfragen beantwortet, während Sie gleichzeitig mit einer Datei mit WAL-Segmenten versorgt werden. Sie können einen Streaming-Replikationsserver haben, auf dem Hot Standby nicht aktiviert ist, sodass keine Anfragen beantwortet werden. Es ist nur so, dass der häufigste Fall heutzutage sowohl Streaming-Replikation als auch Hot Standby ist. Das ist der volle Funktionsumfang. Ignorieren Sie auch hier nicht den alten archive_command-Mechanismus, nur weil es jetzt möglich ist, ihn zu vermeiden. Es kann Sie dennoch vor Streaming-Fehlern bewahren, die ansonsten schwer zu beheben sind.

— Greg Smith
quelle