Die native Streaming-Replikation in PostgreSQL funktioniert nur zwischen Servern mit derselben Hauptversion. Wir haben in einem früheren Beitrag über die logische Replikation gesprochen. Wir haben gesehen, wie die logische Replikation dabei hilft, Daten von einer Version von PostgreSQL in eine andere zu verschieben. Die logische Replikation ist jedoch nur für unterstützte Versionen von PostgreSQL geeignet, z. B. PostgreSQL 9.4 und PostgreSQL 11. Was ist mit Versionen vor 9.4 zu tun? Verwenden Sie Slony-I .
Verwenden Sie die Replikation mit Slony-I, um Daten aus alten Datenbanken auf die neueste Version von PostgreSQL zu übertragen. Was ist Slony und wie funktioniert es?
Dies ist der vierte Beitrag in unserer Reihe Aktualisieren oder Migrieren älterer Versionen von PostgreSQL auf neue, in dem wir verschiedene Methoden zum Aktualisieren von PostgreSQL-Datenbanken kennenlernen.
Slony
Slony ist eine logische Replikationsimplementierung auf Anwendungsebene für PostgreSQL. Oder besser gesagt, es handelt sich um ein Replikationstool eines Drittanbieters, das eine separate Installation und Konfiguration erfordert. Slony gibt es schon lange. Die neueste Version unterstützt PostgreSQL von 8.4 bis 11.
Der Hauptzweck der Replikation besteht darin, Änderungen von einem Datenbankserver auf einen anderen zu übertragen. Schauen wir uns zum besseren Verständnis der Architektur die Begriffe Slon, Ereignisse und Slonik an.
Übrigens, Slony, wenn Sie es nicht erraten haben, sind dies "Elefanten". Und sie haben wirklich ein tolles Gedächtnis. Es ist kein Zufall, dass ein strenger, aber niedlicher Elefant auf dem PostgreSQL-Logo zur Schau gestellt wird.
Slon
Slon ist ein Daemon, der auf jedem PostgreSQL-Knoten in der Slony-I-Replikation ausgeführt wird. Diese Daemons werden verwendet, um Konfigurations- und Replikationsereignisse für jeden PostgreSQL-Server zu verarbeiten. Jeder PostgreSQL-Server wird als Host bezeichnet. Alle Knoten bilden zusammen einen Slony-Cluster.
Der Herausgeberknoten ist die Quelle der Änderungen, und der Abonnentenknoten empfängt die Änderungen vom Herausgeber und wendet sie an.
Um die Replikation zu konfigurieren, müssen Sie alle replizierten Tabellen oder eine Reihe von Replikationen angeben. Das Abonnement funktioniert für einen bestimmten Satz. Änderungen an replizierten Tabellen werden in SYNC kombiniert, einer Gruppe von Transaktionen, die zusammen auf Abonnenten angewendet werden.
Ereignisse
Änderungen werden vom Herausgeber als Ereignisse gemeldet. Wenn ein Ereignis vom Slon-Dämon auf dem Remote-Host verarbeitet wird, wird eine Bestätigung generiert. Und Ereignisse benachrichtigen die Knoten über Konfigurationsänderungen, z. B. das Hinzufügen oder Entfernen neuer Knoten, neuer Abonnements oder DDL-Änderungen.
Jedes Ereignis verfügt über eine eigene eindeutige Quellkennung, Seriennummer, Transaktionskennung für den Snapshot auf dem Ereignisknoten, mehrere Argumente und einen Zeitstempel mit einer Zeitzone.
In PL / pgSQL geschriebene Trigger protokollieren alle Änderungen an replizierten Tabellen. Leider gibt es keine zuverlässige Möglichkeit, Änderungen an Blobs, DDLs oder Änderungen an Benutzern und Rollen zu verarbeiten.
slonik
Dies ist ein Befehlszeilenprogramm mit einem Analysator und einem Interpreter, der Slonik-Skripte akzeptiert - eine einfache deklarative Sprache. Es soll die Einschränkungen einer prozeduralen Sprache überwinden. Mithilfe von slonik-Befehlen können Sie die Replikation in Slony konfigurieren oder ändern und sie können in Shell-Skripte eingebettet werden. Es akzeptiert Befehle von der Standardeingabe oder von Dateien. Das folgende Beispiel zeigt, wie das Slonik-Skript an Slonik übergeben und in Shell-Skripte eingebettet wird.
Das Skript, das die Erstkonfiguration für ein einfaches Master-Slave-Schema in unserer pgbench-Datenbank erstellt, sieht folgendermaßen aus:
#!/bin/sh slonik <<_EOF_ cluster name = percona_pg; node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user'; node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user'; #-- # Creates a _$(clustername), this example, _percona_pg schema #-- init cluster ( id=1, comment = 'Legacy PG Node'); #-- # Add a list of tables being replicated to a set. #-- create set (id=1, origin=1, comment='pgbench'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history'); #-- # Create the second node (the slave) tell the 2 nodes how to connect to # each other and how they should listen for events. #-- store node (id=2, comment = 'Target node', event node=1); store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user'); store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user'); _EOF_
Warum ist Slony für Migrationen geeignet?
Trotz der Vorteile der internen logischen Replikation müssen Sie für Versionen vor PostgreSQL 9.4 diese Drittanbieterlösung verwenden. Der Trigger-basierte Ansatz hängt von der Datenbank-API ab. Beide Versionen müssen kompatibel sein, um die PL / pgSQL- und SQL-Syntax verwenden zu können.
Wie kann ich die Datenbank für die Verwendung mit Slony anpassen?
- Tabellen müssen Primärschlüssel haben. Fügen Sie allen Tabellen ohne Primärschlüssel ein serielles Feld hinzu.
- Änderungen am OID-Blob werden nicht repliziert. Wenn Sie Spalten mit kurzen Werten haben, konvertieren Sie diese in BYTEA. Wenn die Objekte sehr groß sind, z. B. Bilder, ist es besser, Daten in einem externen Speicher zu speichern (z. B. S3 in der Amazon-Cloud). Wenn das Ändern der Anwendung zu kompliziert ist, wenden Sie die Blob-Änderungen im letzten Schritt der Migration an.
- ALTER TABLE und andere DDL-Operationen. Slony erkennt keine Änderungen der Tabellenstruktur. Verwenden Sie den Befehl slonik EXECUTE SCRIPT, um eine SQL-Datei mit SQL- oder DDL-Zeichenfolgen auf den gesamten Replikationscluster anzuwenden.
Online-Migration von früheren Versionen von PostgreSQL
- Erstellen Sie einen Replikationsbenutzer mit Superuser-Berechtigungen. Sie können die Rechte im Detail konfigurieren, dies ist jedoch viel komplizierter.
- Erstellen Sie eine Datenbank am Ziel mit TCP / IP-Zugriff.
- Kopieren Sie die Tabellendefinitionen vom Master auf die Slaves.
- Installieren Sie Slony-I. Auf Servern mit einer alten Version des Betriebssystems ist es einfacher, Slony-I aus dem Quellcode zu installieren.
- Definieren Sie den Cluster, den Tabellensatz und die Knotenverbindungsinformationen als Liste von Slonik-Befehlen.
- Führen Sie den slon-Daemon auf jedem PostgreSQL-Server aus. Überprüfen Sie die Standardausgabe- oder Protokolldateien auf Verbindungsfehler.
- Führen Sie die slonik-Abonnementbefehle aus, um die Synchronisierung zu starten.
- Testen Sie schreibgeschützte Anforderungen in der neuen Version von Postgres.
- Wenn alle Daten repliziert und synchronisiert sind, stoppen Sie die Anwendungen und leiten Sie sie an den neuen Postgres-Server weiter.
- Verwenden Sie den Deinstallationsknoten in der neuen Version von PostgreSQL, um alle Spuren der Slony-Replikation zu entfernen.
Übergang zu früheren Versionen
Gehen Sie genauso vor, um auf frühere Versionen zu aktualisieren. Mit Slony können Sie von jeder Version und auf jede Version von PosgreSQL replizieren, die von der Slony-Version unterstützt wird. Die mindestens unterstützte Version ist 8.4.
Zusammenfassung
Wir haben allgemein gesehen, wie Sie mit Slony mit minimalen Ausfallzeiten auf die neue Version aktualisieren können. Erfahren Sie mehr in unserem Webinar .