Wir schlagen das ständig im Büro durch, und die Frage taucht immer wieder auf. Wie gehen Sie mit der PostgreSQL-Replikation um? Ich spreche nicht unbedingt von fortgeschrittenen Clustern, sondern halte es einfach mit Master-Slave, Master-MultiSlave und Master-Master. Ich finde, dass das Einrichten für MySQL normalerweise ziemlich einfach ist. Ein Failover ist unkompliziert, wenn nicht sogar perfekt, insbesondere, wie einfach es zu konfigurieren ist. Wir haben mit Slony gespielt, aber es ist etwas zu praktisch (Schemaänderungen erfordern Eingriffe, neue Datenbanken erfordern Eingriffe usw.). PGPool2 war ziemlich nett, bis ein Knoten ausfiel und wir keinen passenden Weg fanden (außer alles herunterzufahren und den ausgefallenen Knoten neu zu säen), um die Replikation wieder synchron zu machen. Grundsätzlich ist hier, was ich normalerweise suche:
- Einfaches Setup (ich werde mich mit einem schwierigen Setup zufrieden geben, aber es ist einfach zu erweitern)
- Einfacher Failover
- Das Wiederherstellen eines ausgefallenen Knotens in nur wenigen Sekunden dauert (dh wie bei mysql. Geht der Server aus, Sie rufen ihn auf und warten, bis die Replikation aufholt).
- Schemaänderungen unterbrechen die Replikation nicht
- Das Hinzufügen einer neuen Datenbank zum Server ist nahtlos (dh Sie können wie bei MySQL einen gesamten DB-Server replizieren, sodass auf dem Master eine neue Datenbank erstellt wird, die automatisch an den Slave weitergegeben wird).
MySQL handhabt 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 der Mischung Replikation hinzufügen. Was verwenden Sie derzeit und wie stehen Sie zu Ihrer Lösung? Ich verspreche, dass dies kein MySQL versus PostgreSQL-Post ist, denn ich versuche nicht, damit anzufangen. :)
quelle
Antworten:
Kurze Antwort - Es gibt noch keine solche Lösung für PostgreSQL, wenn Sie online schreibgeschützte Slaves benötigen.
Derzeit laufen in diesem Bereich zwei wichtige Entwicklungsprojekte, die in PostgreSQL 9.0 (Frühjahr / Sommer 2010) enthalten sind:
http://wiki.postgresql.org/wiki/NTT's_Development_Projects
http://wiki.postgresql.org/wiki/Hot_Standby
Die Kombination zielt darauf ab, die Benutzerfreundlichkeit der Replikation im MySQL-Stil abzüglich der Fehler / Probleme, die MySQL hat, und der Zuverlässigkeit, die Benutzer von PostgreSQL kennen, zu erreichen.
All dies wurde 2008 durch ein Manifest des PostgreSQL-Kernteams eingeleitet:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php
Die PostgreSQL-Replikationslösungen mit der größten Benutzerbasis sind bis heute Slony-I (teurer für Schreibvorgänge, Änderungen des Schemas sind umständlich), 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
Weitere Informationen finden Sie unter http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 .
quelle
Und um eine andere Lösung in den Ring zu werfen: Rubyrep.
Um mit Ihren Anforderungen zu vergleichen:
Ja, das ist eigentlich der Hauptfokus von Rubyrep.
Ja. Tatsächlich führt rubyrep eine Master-Master-Replikation durch - für ein Failover ist überhaupt keine Aktion erforderlich. Starten Sie einfach die andere Datenbank.
Ja.
Bei Änderungen an Nicht-Primärschlüsseln muss die Replikation nicht gestoppt werden (stellen Sie jedoch sicher, dass das Schema gleichzeitig auf beiden Seiten geändert wird).
Starten Sie den Replikationsdämon einfach neu, um Tabellen hinzuzufügen / zu entfernen. Nur das Ändern der Primärschlüsselspalte einer Tabelle ist mit einigem Aufwand verbunden.
Dies wird nur eingeschränkt unterstützt: jeder Rubyrep Setup repliziert jeweils nur eine Datenbank. (Es ist jedoch sehr einfach, die Replikation für mehrere Datenbanken einzurichten.)
quelle
Sie haben nicht erwähnt, dass ein Hot-Read-Slave erforderlich ist. Daher werde ich vorschlagen, Heartbeat mit gemeinsamem Speicher oder DRBD zu verwenden. Es macht einfach das Richtige und die Administration ist ein Kinderspiel. Es ist das Linux-Äquivalent zum ä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 alles auf der Blockebene weiter unten behandelt wird.
Im Ernst, es ist bei weitem die beste Lösung, wenn Sie keine Lesesklaven benötigen. Das WAL-Archiv-Zeug war bestenfalls hokey und Sie müssen alles neu einrichten, wenn Sie jemals den Versandprozess für einen Neustart des Servers stören. Slony und Londiste schneiden nicht den Senf. Wenn Sie im Hauptquellbaum bleiben und keine Werbung machen möchten, ist Heartbeat die beste Wahl.
quelle
Aufgrund Ihrer Anforderungen scheint PITR der einfachste Weg zu sein, um 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, sodass PITR möglicherweise genau richtig ist.
Es ist ein Standardbestandteil von PostgreSQL ab Version 8.0, sodass Sie wahrscheinlich bereits alles haben, was Sie benötigen, um es zum Laufen zu bringen.
Wenn Sie Anweisungen zu ausführlich finden, werfen Sie einen Blick auf SkyTools WalMgr , mit dem ein einzelner Befehl zum Erstellen / Failover von Hot-Standby-Daten ausgeführt wird.
Für komplexere Replikationsszenarien hatte ich gute Erfahrungen mit Slony-1, aber PostgreSQL bietet viele gute Replikations- / HA-Optionen.
quelle
Wenn Sie eine asynchrone Master / Slave-Replikation wünschen, ziehen Sie Londiste (Teil des skytools-Pakets von Skype) in Betracht. Wiki.postgresql.org/wiki/Londiste_Tutorial
Die Installation ist einfach, das Hinzufügen einer neuen Datenbank ist einfach, die Replikation holt nur auf.
Failover ist jedoch nicht integriert. Sie müssen Ihre Anwendungsverbindungszeichenfolgen ändern oder die DB-Verbindung hinter einer anderen Softwareschicht verschleiern.
Einige Schemaänderungen sind einfach. Andere sind schwieriger. Das hängt von Ihrer Anwendung ab. Die nächste Version von skytools (Version 3.0) soll DDL verarbeiten und Funktionen zur Erleichterung des Failovers enthalten.
Wir sind nach Londiste gezogen, nachdem wir festgestellt hatten, dass Slony zu schmerzhaft ist, um sie zu benutzen.
quelle
Sehen Sie sich hier eine Diskussion an, vielleicht kann das helfen:
http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html
und
Konkurrenten von Bucardo Version One, weiter unten auf der Seite zu finden:
http://www.planetpostgresql.org/
quelle
Es gibt wirklich keine kostenlosen / Open-Source-Möglichkeiten, um das zu liefern, wonach Sie suchen. Wenn Sie etwas so Schlüsselfertiges möchten, schauen Sie sich verschiedene kommerzielle Replikationslösungen von Drittanbietern an.
Nun, es ist möglich , von Roll Ihre eigenen Replikation mit Postgres zu sortieren mit Schreibkopf - Protokoll (WAL) Versand:
Im Grunde genommen können Sie hier einen sekundären Knoten in den kontinuierlichen Wiederherstellungsmodus versetzen und alle {kleinen Intervalle} Transaktionsprotokolle in diesen Knoten importieren. Die Postgres-Konfiguration verfügt über "Stubs", mit denen Sie bestimmte Aktionen ausführen können, wenn ein Postgres nach Abschluss einer WAL ausgeführt wird.
Damit können Sie jedoch keine Master-Master- und / oder Zirkelreplikation durchführen.
Auf jeden Fall funktioniert es auf jeden Fall, aber ich würde es nicht als "einfaches Setup", "vereinfachtes Failover", "nahtlos" oder ähnliches bezeichnen.
quelle
Mit Ausnahme von "Hinzufügen einer neuen Datenbank" können Sie Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ) ausprobieren . Es ist Open Source, einfach einzurichten und unterstützt Failover. Die Hauptbeschränkungen sind eine einzelne Datenbank und die Unfähigkeit, DDL-Änderungen zu replizieren. Beide befinden sich in der TODO-Liste.
quelle
Postgres-R sah vielversprechend aus, aber ich weiß nicht, ob das Projekt noch läuft.
quelle
Ich schaue gerade auf Wolfram-Replikator, ich bin noch weit weg von einer definitiven Schlussfolgerung, aber wahrscheinlich einen Blick wert.
www.continuent.com
quelle