Frage PostgreSQL-Replikation


Wir schlagen das ständig im Büro herum, und die Frage geht weiter. Wie gehen Sie mit der PostgreSQL-Replikation um? Ich rede nicht unbedingt von fortgeschrittenen Clustern, ich halte es einfach mit Master-Slave, Master-MultiSlave und Master-Master. Ich finde, dass es für MySQL ziemlich einfach ist, es einzurichten. Failover ist einfach, wenn nicht perfekt, besonders für die einfache Konfiguration. Wir haben mit Slony gespielt, aber es ist ein wenig zu hands-on (Schemaänderungen erfordern Intervention, neue Datenbanken erfordern Intervention usw.). PGPool2 war ziemlich nett, bis ein Knoten unterging und wir keinen vernünftigen Weg finden konnten (außer, alles herunter zu bringen und den gefallenen Knoten neu zu säen), um die Replikation wieder synchron zu bekommen. Im Grunde ist das, wonach ich normalerweise suche:

  • Einfache Einrichtung (Ich werde mich für eine schwierige Einrichtung entscheiden, aber einfach zu erweitern)
  • Einfaches Failover
  • Das Zurückbringen eines gefallenen Knotens erfordert nur Zeit (d. H. Wie bei mysql. Der Server geht herunter, du bringst ihn hoch und wartest darauf, dass die Replikation aufholt)
  • Schemaänderungen unterbrechen die Replikation nicht
  • Das Hinzufügen einer neuen Datenbank zum Server ist nahtlos (d. H. Wie bei mysql können Sie einen ganzen DB-Server replizieren, so dass eine neue Datenbank auf dem Master erstellt wird, die automatisch an den Slave weitergegeben wird)

MySQL behandelt die meisten davon ziemlich gut, aber ich habe eine gewisse Vorliebe für PostgreSQL. Außerdem haben wir einige Situationen, in denen dies unsere einzige Option ist, und wir möchten die Mischung um Replikation erweitern. Was nimmst du derzeit und wie denkst du über deine Lösung? Dies ist kein MySQL-versus PostgreSQL-Post, das verspreche ich, denn das ist nicht das, was ich versuche zu starten. :)


45
2018-05-22 06:22


Ursprung


Ich bin an der Antwort darauf interessiert. Aus einem MySQL-Hintergrund kommend, sind die Replikationsoptionen für PSQL zumindest geläufig. - Dave Cheney
Ja, bisher hat jede Option, mit der ich gespielt habe, erhebliche Nachteile gehabt. Ich hoffe, ich vermisse etwas Offensichtliches ... aber ich glaube nicht, dass ich es bin - f4nt
Ich vermute, es gibt nichts anderes, aber ich bin gespannt auf jemanden, der mir das Gegenteil beweisen kann - Vinko Vrsalovic
BTW, haben Sie pgsql-general@postgresql.org versucht? - Vinko Vrsalovic


Antworten:


Kurze Antwort - für PostgreSQL gibt es noch keine solche Lösung, wenn Sie Online-Readonly-Slaves benötigen.

Derzeit laufen in diesem Bereich zwei große Entwicklungsprojekte, die in PostgreSQL 9.0 (Frühjahr / Sommer 2010) enthalten sind:

  • Synchrone Replikation:

http://wiki.postgresql.org/wiki/NTT_Development_Projects

  • Nur Hot-Standby-Slaves lesen:

http://wiki.postgresql.org/wiki/Hot_Standby

Diese Kombination zielt darauf ab, die Benutzerfreundlichkeit der MySQL-artigen Replikation zu erreichen, abzüglich der Bugs / Probleme, die MySQL hat, und der Zuverlässigkeit, die Benutzer von PostgreSQL kennen.

All dies wurde 2008 durch ein Manifest des PostgreSQL Core Teams ausgelöst:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

Die PostgreSQL-Replikationslösungen bis heute mit der größten Benutzerbasis sind Slony-I (teurer für Schreibvorgänge, macht Schemaänderungen fiddly), WAL-Versand / walmgr (Slaves können nicht online verwendet werden) und pgQ / londiste von Skype / Skytools ( mehr Werkzeuge / Bausteine ​​als eine fertige Lösung).

Ich habe ein paar Dinge über Log Shipping geschrieben, Walmgr und Slony-I, siehe

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 für mehr Informationen.


9
2018-05-29 15:47



Synchrone Replikation + Hot Standby sind jetzt verfügbar - siehe wiki.postgresql.org/wiki/... für eine gute Zusammenfassung der verfügbaren Techniken - David Fraser


Und eine andere Lösung in den Ring zu werfen: Rubyrep.

Um mit Ihren Anforderungen zu vergleichen:

  • Einfache Einstellung
    Ja, das ist eigentlich der Hauptfokus von Rubyrep.
  • Einfaches Failover
    Ja. In der Tat macht Rubyrep Master-Master-Replikation - um auszufallen, ist überhaupt keine Aktion notwendig. Starten Sie einfach die andere Datenbank.
  • Schemaänderungen unterbrechen die Replikation nicht
    Ja.
    Bei Änderungen ohne Primärschlüssel muss die Replikation nicht einmal gestoppt werden (stellen Sie jedoch sicher, dass das Schema auf beiden Seiten gleichzeitig geändert wird).
    Um Tabellen hinzuzufügen / zu entfernen, starten Sie den Replikationsdämon einfach neu. Nur die Änderung der Primärschlüsselspalte einer Tabelle erfordert ein wenig Aufwand.
  • Das Hinzufügen einer neuen Datenbank zum Server ist nahtlos (d. H. Wie bei mysql können Sie einen ganzen DB-Server replizieren, so dass eine neue Datenbank auf dem Master erstellt wird, die automatisch an den Slave weitergegeben wird)
    Dies wird nur begrenzt unterstützt: Jedes Rubyrep-Setup repliziert jeweils nur eine Datenbank. (Es ist jedoch sehr einfach, die Replikation für mehr als eine Datenbank einzurichten.)

5
2017-07-01 06:41





Sie haben nicht erwähnt, dass Sie einen Hot-Read-Slave als Voraussetzung haben, deshalb werde ich Heartbeat entweder mit gemeinsam genutztem Speicher oder DRBD vorschlagen. Es macht einfach das Richtige und die Verwaltung ist ein Kinderspiel. Es ist das Linux-Äquivalent von älteren Microsoft SQL Server-Clustering. Ein Knoten ist aktiv und der andere Knoten ist passiv, während die Daten zwischen den beiden geteilt werden. Sie müssen sich keine Gedanken über die SQL-basierte Replikation machen, da diese auf Blockebene weiter unten behandelt wird.

Im Ernst, es ist bei weitem die beste Lösung, wenn Sie keine Leseslaves benötigen. Der WAL-Archivkram war bestenfalls hokey und Sie müssen alles wieder einrichten, wenn Sie den Versandprozess für einen Serverneustart stören. Slony und Londiste schneiden den Senf nicht ab. Wenn Sie im Hauptquellenbaum bleiben und nicht kommerziell werden möchten, ist Heartbeat die beste Wahl.


4
2018-05-27 18:02





Von Ihren Anforderungen scheint es, dass PITR der einfachste Weg ist, Ihr Problem zu lösen:

Online-Backup und Point-in-Time-Recovery (PITR)

Sie haben nicht gesagt, dass Sie den Slave-Server abfragen müssen, also könnte PITR genau richtig sein.

Es ist Standard-Teil von PostgreSQL ab Version 8.0, also haben Sie wahrscheinlich bereits alles, was Sie benötigen, um es zu starten.

Wenn Sie Anweisungen zu ausführlich finden, werfen Sie einen Blick auf SkyTools WalMgr Dadurch wird der Vorgang des Erstellens / Failovers zu einer einzelnen Befehlsaufgabe für Hot-Standby-Daten durchgeführt.

Für komplexere Replikationsszenarien hatte ich gute Erfahrungen mit Slony-1, aber PostgreSQL bietet viele gute Replikations- / HA-Optionen.


2
2018-05-22 13:25



und diese Optionen sind ...? - Dave Cheney
... im Blogbeitrag aufgelistet blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html in einer der Antworten referenziert ... - dpavlin


Wenn Sie eine asynchrone Master / Slave-Replikation wünschen, betrachten Sie Londiste (Teil des skytools-Pakets von Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Es ist einfach zu installieren, das Hinzufügen einer neuen Datenbank ist einfach, die Replikation "holt" einfach auf.

Failover ist jedoch nicht integriert. Sie müssen Ihre Anwendungsverbindungszeichenfolgen ändern oder die DB-Verbindung hinter einer anderen Softwareschicht verdecken.

Einige Schemaänderungen sind einfach. Andere sind schwieriger. Es hängt von Ihrer Anwendung ab. Die nächste Version von skytools (Version 3.0) soll mit DDL umgehen und Funktionen enthalten, die das Failover erleichtern.

Wir zogen nach Londiste, nachdem wir Slony zu schmerzhaft fanden.


2
2018-05-27 17:53





Sehen Sie hier eine Diskussion, vielleicht kann das helfen:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

und

Konkurrenten zu Bucardo Version One, unten auf der Seite gefunden:

http://www.planetpostgresql.org/


1
2018-05-22 09:09





Es gibt wirklich keine freien / Open-Source-Möglichkeiten, um das zu bieten, wonach Sie suchen. Wenn Sie etwas, das so schlüsselfertig ist, möchten, sehen Sie sich verschiedene kommerzielle Replikationslösungen von Drittanbietern an.

Nun, es ist Es ist möglich, Ihre eigene Replikation mit Postgres unter Verwendung des WAL-Versands (Write-Head Log) zu sortieren:

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

Hier können Sie im Prinzip einen sekundären Knoten in den kontinuierlichen Wiederherstellungsmodus versetzen und Transaktionsprotokolle alle {kleinen Intervalle} darin importieren. Die Postgres-Konfiguration verfügt über "Stubs", damit Sie bestimmte Dinge tun können, wenn ein Postgres bei Abschluss einer WAL und so, nein, und das ist, was diese Einstellung vorausgesetzt wird - mit diesen "Stubs".

Dies erlaubt Ihnen jedoch nicht, Master-Master und / oder zirkuläre Replikation zu tun.

In jedem Fall funktioniert es definitiv für die Dauerhaftigkeit, aber ich würde es nicht "einfaches Setup", "vereinfachendes Failover", "nahtloses" oder ähnliches nennen.


1
2018-05-27 10:10



Diese Antwort ist ein Duplikat des PITR-Vorschlags, da PITR WAL verwendet :-) - dpavlin