PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Ein Expertenleitfaden zur Slony-Replikation für PostgreSQL

Was ist Slony?

Slony-I (im Folgenden nur als „Slony“ bezeichnet) ist ein Replikationssystem eines Drittanbieters für PostgreSQL, das auf eine Zeit vor Version 8.0 zurückgeht, was es zu einer der älteren verfügbaren Replikationsmöglichkeiten macht. Es arbeitet als Trigger-basierte Replikationsmethode, die eine „Master-to-Multiple-Slaves“-Lösung ist.

Slony installiert Trigger auf jeder zu replizierenden Tabelle, sowohl auf dem Master als auch auf den Slaves, und jedes Mal, wenn die Tabelle ein INSERT, UPDATE oder DELETE erhält, protokolliert es, welcher Datensatz geändert wird und was die Änderung ist. Externe Prozesse, die als „Slon-Daemons“ bezeichnet werden, verbinden sich wie jeder andere Client mit den Datenbanken und rufen die Änderungen vom Master ab, um sie dann auf allen Slave-Knoten wiederzugeben, die beim Master angemeldet sind. In einer gut funktionierenden Replikationskonfiguration ist dies asynchron Es ist zu erwarten, dass die Replikation 1 bis 20 Sekunden hinter dem Master zurückbleibt.

Zum jetzigen Zeitpunkt ist die neueste Version von Slony Version 2.2.6 und unterstützt PostgreSQL 8.3 und höher. Der Support wird bis heute mit kleineren Updates fortgesetzt, aber wenn eine zukünftige Version von PostgreSQL grundlegende Funktionalitäten von Transaktionen, Funktionen, Triggern oder anderen Kernfunktionen ändert, kann das Slony-Projekt beschließen, große Updates einzustellen, um solch drastische neue Ansätze zu unterstützen.

Das Maskottchen von PostgreSQL ist ein Elefant namens „Slonik“, was auf Russisch „kleiner Elefant“ bedeutet. Da es bei diesem Replikationsprojekt darum geht, dass viele PostgreSQL-Datenbanken miteinander replizieren, wird das russische Wort für Elefanten (Plural) verwendet:Slony.

Konzepte

  • Cluster:Eine Instanz der Slony-Replikation.
  • Knoten:Eine bestimmte PostgreSQL-Datenbank als Slony-Replikationsknoten, der entweder als Master oder als Slave für einen Replikationssatz fungiert.
  • Replikationssatz:Eine Gruppe von Tabellen und/oder Sequenzen, die repliziert werden sollen.
  • Abonnenten:Ein Abonnent ist ein Knoten, der einen Replikationssatz abonniert hat und vom Master-Knoten Replikationsereignisse für alle Tabellen und Sequenzen innerhalb dieses Satzes empfängt.
  • Slony-Daemons:Die wichtigsten Worker, die die Replikation ausführen, ein Slony-Daemon wird für jeden Knoten im Replikationssatz gestartet und stellt verschiedene Verbindungen zu dem von ihm verwalteten Knoten sowie zum Master-Knoten her.

Wie es verwendet wird

Slony wird entweder aus der Quelle oder über die PGDG-Repositories (PostgreSQL Global Development Group) installiert, die für Red Hat- und Debian-basierte Linux-Distributionen verfügbar sind. Diese Binärdateien sollten auf allen Hosts installiert werden, die entweder einen Master- oder einen Slave-Knoten im Replikationssystem enthalten.

Nach der Installation wird ein Slony-Replikationscluster eingerichtet, indem einige Befehle mit der Binärdatei „slonik“ ausgegeben werden. „slonik“ ist ein Befehl mit einer einfachen, aber einzigartigen Syntax, um einen Slony-Cluster zu initialisieren und zu warten. Es ist die Hauptschnittstelle zum Ausgeben von Befehlen an den laufenden Slony-Cluster, der für die Replikation zuständig ist.

Die Verbindung mit Slony kann entweder durch Schreiben benutzerdefinierter Slonik-Befehle oder durch Kompilieren von Slony mit dem Flag --with-perltools hergestellt werden, das die „altperl“-Skripte bereitstellt, die beim Generieren dieser benötigten Slonik-Skripte helfen.

Erstellen eines Slony-Replikationsclusters

Ein „Replikationscluster“ ist eine Sammlung von Datenbanken, die Teil der Replikation sind. Beim Erstellen eines Replikationsclusters muss ein Init-Skript geschrieben werden, das Folgendes definiert:

  • Der Name des gewünschten Slony-Clusters
  • Die Verbindungsinformationen für jeden Knotenteil der Replikation, jeweils mit einer unveränderlichen Knotennummer.
  • Auflisten aller Tabellen und Sequenzen, die als Teil eines „Replikationssatzes“ repliziert werden sollen.

Ein Beispielskript finden Sie in der offiziellen Dokumentation von Slony.

Bei der Ausführung stellt slonik eine Verbindung zu allen definierten Knoten her und erstellt auf jedem das Slony-Schema. Wenn die Slony-Daemons gestartet werden, löschen sie alle Daten in den replizierten Tabellen auf dem Slave (falls vorhanden) und kopieren alle Daten vom Master auf den/die Slave(s). Von diesem Zeitpunkt an replizieren die Daemons kontinuierlich die auf dem Master aufgezeichneten Änderungen an alle abonnierten Slaves.

Clevere Konfigurationen

Während Slony ursprünglich ein Master-to-Multiple-Slave-Replikationssystem ist und hauptsächlich auf diese Weise verwendet wurde, gibt es mehrere andere Funktionen und clevere Verwendungen, die Slony nützlicher als eine einfache Replikationslösung machen. Die hochgradig anpassbare Natur von Slony hält es für eine Vielzahl von Situationen für Administratoren relevant, die über den Tellerrand hinausschauen können.

Kaskadierende Replikation

Slony-Knoten können so eingerichtet werden, dass sie die Replikation über eine Kette verschiedener Knoten kaskadieren. Wenn bekannt ist, dass der Master-Knoten eine extrem hohe Last aufnimmt, erhöht jeder zusätzliche Slave diese Last leicht. Bei der kaskadierenden Replikation kann ein einzelner Slave-Knoten, der mit dem Master verbunden ist, als „Weiterleitungsknoten“ konfiguriert werden, der dann dafür verantwortlich ist, Replikationsereignisse an mehr Slaves zu senden, wodurch die Belastung des Master-Knotens auf einem Minimum gehalten wird.

Kaskadierende Replikation mit Slony

Datenverarbeitung auf einem Slave-Knoten

Im Gegensatz zur integrierten Replikation von PostgreSQL sind die Slave-Knoten nicht wirklich „schreibgeschützt“, nur die Tabellen, die repliziert werden, sind als „schreibgeschützt“ gesperrt. Das bedeutet, dass auf einem Slave-Knoten die Datenverarbeitung stattfinden kann, indem neue Tabellen erstellt werden, die nicht Teil der Replikation sind, um verarbeitete Daten aufzunehmen. Tabellen, die Teil der Replikation sind, können auch benutzerdefinierte Indizes haben, die abhängig von den Zugriffsmustern erstellt werden, die sich von Slave und Master unterscheiden können.

Nur-Lese-Tabellen auf den Slaves können weiterhin benutzerdefinierte Trigger-basierte Funktionen haben, die bei Datenänderungen ausgeführt werden, was eine stärkere Anpassung der Daten ermöglicht.

Datenverarbeitung auf einem Slony-Slave-Knoten

Upgrades mit minimaler Ausfallzeit

Das Upgrade von Hauptversionen von PostgreSQL kann extrem zeitaufwändig sein. Je nach Datengröße und Tabellenanzahl kann ein Upgrade einschließlich des „Analyze“-Prozesses nach dem Upgrade sogar mehrere Tage dauern. Da Slony Daten zwischen PostgreSQL-Clustern verschiedener Versionen replizieren kann, kann es verwendet werden, um eine Replikation zwischen einer älteren Version als Master und einer neueren Version als Slave einzurichten. Wenn das Upgrade stattfinden soll, führen Sie einfach eine „Umschaltung“ durch, wodurch der Slave zum neuen Master und der alte Master zum Slave wird. Wenn das Upgrade als erfolgreich markiert ist, nehmen Sie den Slony-Replikationscluster außer Betrieb und fahren Sie die alte Datenbank herunter.

Aktualisieren Sie PostgreSQL mit minimaler Ausfallzeit mit Slony

Hohe Verfügbarkeit mit häufiger Serverwartung

Wie die minimale Ausfallzeit für Upgrades kann die Serverwartung einfach und ohne Ausfallzeit durchgeführt werden, indem eine „Umschaltung“ zwischen zwei oder mehr Knoten durchgeführt wird, wodurch ein Slave mit Updates / anderen Wartungsarbeiten neu gestartet werden kann. Wenn der Slave wieder online geht, verbindet er sich erneut mit dem Replikationscluster und holt alle replizierten Daten nach. Bei Endbenutzern, die sich mit der Datenbank verbinden, können lange Transaktionen unterbrochen werden, aber die Ausfallzeit selbst würde Sekunden betragen, wenn die Umschaltung erfolgt, und nicht so lange, wie es dauert, den Host neu zu starten / zu aktualisieren.

Protokollversand

Obwohl dies wahrscheinlich keine beliebte Lösung ist, kann ein Slony-Slave als „Protokollversand“-Knoten eingerichtet werden, wo alle Daten, die er durch Replikation erhält, in SQL-Dateien geschrieben und versendet werden können. Dies kann aus verschiedenen Gründen verwendet werden, z. B. zum manuellen Schreiben auf ein externes Laufwerk und zum Transportieren zu einer Slave-Datenbank und nicht über ein Netzwerk, zum Komprimieren und Archivieren für zukünftige Sicherungen oder zum Analysieren der SQL-Dateien und sogar durch ein externes Programm den Inhalt ändern.

Mehrere gemeinsame Nutzung von Datenbankdaten

Da eine beliebige Anzahl von Tabellen nach Belieben repliziert werden kann, können Slony-Replikationssätze eingerichtet werden, um bestimmte Tabellen zwischen Datenbanken gemeinsam zu nutzen. Während ein ähnlicher Zugriff durch Foreign Data Wrapper erreicht werden kann (die in den letzten PostgreSQL-Versionen verbessert wurden), kann es je nach Verwendung eine bessere Lösung sein, Slony zu verwenden. Wenn eine große Datenmenge von einem Host zum anderen abgerufen werden muss, bedeutet die Replikation dieser Daten durch Slony, dass die erforderlichen Daten bereits auf dem anfordernden Knoten vorhanden sind, wodurch lange Übertragungszeiten entfallen.

Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter

Verzögerte Replikation

Normalerweise soll die Replikation so schnell wie möglich erfolgen, aber es kann einige Szenarien geben, in denen eine Verzögerung erwünscht ist. Der slon-Daemon für einen Slave-Knoten kann mit einem lag_interval konfiguriert werden, was bedeutet, dass er keine Replikationsdaten empfängt, bis die Daten wie angegeben alt sind. Dies kann für den schnellen Zugriff auf verlorene Daten nützlich sein, wenn etwas schief geht. Wenn beispielsweise eine Zeile gelöscht wird, bleibt sie für eine schnelle Wiederherstellung 1 Stunde lang auf dem Slave bestehen.

Wissenswertes:

  • Alle DDL-Änderungen an Tabellen, die Teil der Replikation sind, müssen mit dem Befehl slonik execute ausgeführt werden.
  • Jede zu replizierende Tabelle muss entweder einen Primärschlüssel oder einen UNIQUE-Index ohne Nullable-Spalten haben.
  • Daten, die vom Master-Knoten repliziert werden, werden repliziert, nachdem alle Daten möglicherweise funktional generiert wurden. Das heißt, wenn Daten mit etwas wie „random()“ generiert wurden, wird die resultierende Zahl gespeichert und auf den Slaves repliziert, anstatt „random()“ erneut auf dem Slave auszuführen und ein anderes Ergebnis zurückzugeben.
  • Das Hinzufügen von Slony-Replikation erhöht die Serverlast leicht. Obwohl effizient geschrieben, verfügt jede Tabelle über einen Trigger, der jedes INSERT, UPDATE und DELETE in einer Slony-Tabelle protokolliert. Erwarten Sie je nach Datenbankgröße und Arbeitslast eine Erhöhung der Serverlast um etwa 2-10 %.

Tipps und Tricks:

  • Slony-Daemons können auf jedem Host laufen, der Zugriff auf alle anderen Hosts hat, aber die leistungsstärkste Konfiguration besteht darin, die Daemons auf den Knoten laufen zu lassen, die sie verwalten. Zum Beispiel der Master-Daemon, der auf dem Master-Knoten läuft, der Slave-Daemon, der auf dem Slave-Knoten läuft.
  • Wenn Sie einen Replikationscluster mit einer sehr großen Datenmenge einrichten, kann die anfängliche Kopie ziemlich lange dauern, was bedeutet, dass alle Änderungen, die vom Kickoff bis zum Abschluss der Kopie vorgenommen werden, noch länger dauern können, um aufzuholen und synchron zu sein . Dies kann gelöst werden, indem entweder ein paar Tabellen gleichzeitig zur Replikation hinzugefügt werden (sehr zeitaufwändig) oder indem eine Datenverzeichniskopie der Master-Datenbank auf dem Slave erstellt wird und dann ein 'subscribe set' mit der auf OMIT COPY gesetzten Option durchgeführt wird WAHR. Mit dieser Option geht Slony davon aus, dass die Slave-Tabelle zu 100 % identisch mit der Master-Tabelle ist, und löscht sie nicht und kopiert die Daten nicht hinüber.
  • Das beste Szenario dafür besteht darin, mithilfe der integrierten Tools für PostgreSQL einen Hot Standby zu erstellen und während eines Wartungsfensters ohne Verbindungen, die Daten ändern, den Standby als Master online zu schalten, Datenübereinstimmungen zwischen den beiden zu validieren und die zu initiieren slony-Replikationscluster mit OMIT COPY =true, und aktivieren Sie schließlich die Client-Verbindungen erneut. Die Einrichtung für Hot Standby kann einige Zeit in Anspruch nehmen, aber der Vorgang wird keine großen negativen Auswirkungen auf die Clients haben.

Community und Dokumentation

Die Community für Slony ist in den Mailinglisten unter http://lists.slony.info/mailman/listinfo/slony1-general zu finden, die auch Archive enthalten.

Die Dokumentation ist auf der offiziellen Website http://slony.info/documentation/ verfügbar und bietet Hilfe bei der Protokollanalyse und Syntaxspezifikation für die Schnittstelle mit slony.