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

So replizieren Sie PostgreSQL-Daten auf Remote-Sites

In einer ausgelasteten Datenbankumgebung mit größeren Datenbanken ist die Notwendigkeit einer Datenreplikation in Echtzeit ein häufiges Problem. Für Anwendungen ist es häufig erforderlich, dass die Produktionsdaten in Echtzeit an entfernte Standorte für Analysen und andere kritische Geschäftsanforderungen repliziert werden.

DBAs müssen außerdem sicherstellen, dass die Daten kontinuierlich an die entfernten Standorte repliziert werden, um verschiedene Anforderungen zu erfüllen. Diese Anforderungen bestehen jedoch möglicherweise nicht immer darin, die gesamte Datenbank zu replizieren; Es kann auch erforderlich sein, nur eine Teilmenge der Daten zu replizieren (z. B. eine Tabelle oder eine Reihe von Tabellen oder Daten aus mehreren Tabellen mit SQL für Analysen, Berichte usw.)

In diesem Blog konzentrieren wir uns darauf, wie Tabellen in Echtzeit in entfernte Datenbanken repliziert werden.

Was ist Replikation auf Tabellenebene?

Die Replikation auf Tabellenebene ist der Mechanismus zum Replizieren der Daten einer bestimmten Tabelle oder eines Satzes von Tabellen von einer Datenbank (Quelle) in eine andere Datenbank (Ziel), die remote in einer verteilten Umgebung gehostet wird. Die Replikation auf Tabellenebene stellt sicher, dass Tabellendaten kontinuierlich verteilt werden und über replizierte (Ziel-)Sites hinweg konsistent bleiben.

Warum Replikation auf Tabellenebene?

Die Replikation auf Tabellenebene ist eine wesentliche Anforderung in größeren, komplexen und stark verteilten Umgebungen. Meiner Erfahrung nach bestand immer die Notwendigkeit, eine Reihe von Tabellen zu Berichtszwecken aus einer Produktionsdatenbank in ein Data Warehousing zu replizieren. Die Daten müssen kontinuierlich repliziert werden, um sicherzustellen, dass Berichte die neuesten Daten erhalten. In kritischen Umgebungen kann eine Veralterung der Daten nicht toleriert werden, daher müssen die Datenänderungen, die in der Produktion auftreten, sofort auf den Zielstandort repliziert werden. Dies kann eine echte Herausforderung für DBAs sein, die verschiedene Faktoren prognostizieren müssen, um eine effiziente und reibungslose Tabellenreplikation sicherzustellen.

Sehen wir uns einige Anforderungen an, die die Replikation auf Tabellenebene löst:

  • Die Berichte können auf einer Datenbank in einer anderen Umgebung als der Produktionsumgebung ausgeführt werden, wie z. B. Data Warehousing
  • Eine verteilte Datenbankumgebung mit verteilten Anwendungen, die Daten von mehreren Standorten extrahieren. Bei verteilten Web- oder Mobilanwendungen sollte die Kopie derselben Daten an mehreren Standorten verfügbar sein, um verschiedene Anwendungsanforderungen zu erfüllen, für die Replikation auf Tabellenebene eine gute Lösung sein könnte
  • Gehaltsabrechnungsanwendungen, die die Daten aus verschiedenen Datenbanken benötigen, die sich in verschiedenen geografisch verteilten Rechenzentren oder Cloud-Instanzen befinden, um in einer zentralen Datenbank verfügbar zu sein

Verschiedene Faktoren, die sich auf die Replikation auf Tabellenebene auswirken – worauf Sie achten sollten

Wie oben erwähnt, müssen Datenbankadministratoren eine Vielzahl von Echtzeitkomponenten und -faktoren berücksichtigen, um ein effektives Replikationssystem auf Tabellenebene zu entwerfen und zu implementieren.

Tabellenstruktur

Die Art der Datentabelle, die angepasst wird, hat einen großen Einfluss auf die Replikationsleistung. Wenn die Tabelle eine BYTEA-Spalte mit größeren Binärdaten enthält, kann die Replikationsleistung darunter leiden. Die Auswirkungen der Replikation auf Netzwerk, CPU und Festplatte müssen sorgfältig bewertet werden.

Datengröße

Wenn die zu migrierende Tabelle zu groß ist, würde die anfängliche Datenmigration Ressourcen und Zeit in Anspruch nehmen, DBAs müssen sicherstellen, dass die Produktionsdatenbank nicht beeinträchtigt wird.

Infrastrukturressourcen

Die Infrastruktur muss mit angemessenen Ressourcen ausgestattet sein, um sicherzustellen, dass ein zuverlässiges und stabil funktionierendes Replikationssystem aufgebaut werden kann. Welche Infrastrukturkomponenten müssen berücksichtigt werden?

CPUs

Die Datenreplikation ist stark von CPUs abhängig. Beim Replizieren aus der Produktion dürfen die CPUs nicht erschöpft werden, was die Produktionsleistung beeinträchtigen kann.

Netzwerk

Dies ist entscheidend für die Replikationsleistung. Die Netzwerklatenz zwischen Quell- und Zieldatenbank(en) muss durch Belastungstests bewertet werden, um sicherzustellen, dass genügend Bandbreite für eine schnellere Replikation vorhanden ist. Außerdem könnte dasselbe Netzwerk von anderen Prozessen oder Anwendungen aufgebraucht werden. Daher muss hier eine Kapazitätsplanung durchgeführt werden.

Erinnerung

Es muss ausreichend Arbeitsspeicher verfügbar sein, um sicherzustellen, dass genügend Daten für eine schnellere Replikation zwischengespeichert werden.

Quelltabellenaktualisierungen

Wenn die Datenänderungen in der Quelltabelle umfangreich sind, muss das Replikationssystem in der Lage sein, die Änderungen so schnell wie möglich mit der/den Remote-Site(s) zu synchronisieren. Die Replikation führt dazu, dass eine große Anzahl von Synchronisierungsanfragen an die Zieldatenbank gesendet wird, was ressourcenintensiv sein kann.

Die Art der Infrastruktur (Rechenzentren oder Cloud) kann sich ebenfalls auf die Replikationsleistung auswirken und Herausforderungen darstellen. Auch die Implementierung der Überwachung könnte eine Herausforderung darstellen. Wenn es eine Verzögerung gibt und bestimmte Daten in der Zieldatenbank fehlen, kann die Überwachung schwierig sein und nicht synchron sein

So implementieren Sie die Tabellenreplikation

Die Replikation auf Tabellenebene in PostgreSQL kann mit einer Vielzahl von externen Tools (kommerziell oder Open-Source) implementiert werden, die auf dem Markt erhältlich sind, oder durch die Verwendung von benutzerdefinierten Datenströmen.

Lassen Sie uns einen Blick auf einige dieser Tools, ihre Funktionen und Möglichkeiten werfen...

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

Slony

Slony ist eines der beliebtesten Tools zum asynchronen Replizieren bestimmter einzelner Tabellen oder Tabellen in Echtzeit von einer PostgreSQL-Datenbank in eine andere. Dies ist ein Perl-basiertes Tool, das eine Trigger-basierte Replikation von Datenänderungen einer Tabelle (oder eines Satzes von Tabellen) von einer Datenbank an einem Standort zu einem anderen durchführt. Es ist ziemlich zuverlässig und hat eine jahrelange Entwicklungsgeschichte. Da es sich um ein Trigger-basiertes Tool handelt, ist es zwar sehr zuverlässig, die Verwaltung der Replikationseinstellungen kann jedoch komplex werden.

Sehen wir uns einige Fähigkeiten von Slony an...

Vorteile der Verwendung von Slony

  • Unterstützt Master-to-Slave- oder mehrere Slave-Replikationsmethoden, die zur Verbesserung der horizontalen Leseskalierbarkeit beitragen. Mit anderen Worten, Slaves sind nicht beschreibbar
  • Das Konfigurieren mehrerer Slaves für einen einzigen Master ist möglich und unterstützt auch die kaskadierende Replikationsmethode
  • Unterstützt Switchover- und Failover-Mechanismen
  • Eine große Anzahl von Tabellen kann in Gruppen parallel repliziert werden
  • Wir können zwischen verschiedenen Hauptversionen von PostgreSQL-Instanzen replizieren, was Slony zu einer großartigen Option für Datenbank-Upgrades macht
  • Einfach zu installieren

Nachteile der Verwendung von Slony

  • Unterstützt keine DDL-Replikation
  • Bestimmte Schemaänderungen können die Replikation unterbrechen
  • Replikationsereignisse werden innerhalb der Datenbank in Slony-spezifischen Protokolltabellen protokolliert, was einen Wartungsaufwand bedeuten kann.
  • Wenn eine große Anzahl von Tabellen mit großen Datensätzen repliziert werden soll, können Leistung und Wartung ernsthafte Herausforderungen darstellen
  • Da es sich um eine Trigger-basierte Replikation handelt, kann die Leistung beeinträchtigt werden

Bucardo

Bucardo ist ein weiteres Perl-basiertes Open-Source-Replikationssystem für PostgreSQL, das die asynchrone Replikation bestimmter Tabellendaten zwischen zwei oder mehr PostgreSQL-Instanzen unterstützt. Was Bucardo von Slony unterscheidet, ist, dass es auch Multi-Master-Replikation unterstützt.

Lassen Sie uns einen Blick auf verschiedene Arten von Replikationsmechanismen werfen, die bucardo bei der Implementierung unterstützt...

  • Multi-Master-Replikation:Tabellen können in beide Richtungen zwischen zwei oder mehr PostgreSQL-Instanzen repliziert werden und die Transaktionsdaten werden bidirektional synchronisiert
  • Master-Slave:Die Daten aus den Tabellen im Master werden asynchron zum Slave repliziert und der Slave steht für Lesevorgänge zur Verfügung
  • Vollständiger Kopiermodus (Master-Slave):Bucardo -/repliziert die gesamten Daten vom Master zum Slave-Knoten, indem alle Daten vom Slave gelöscht werden

Vorteile der Verwendung von Bucardo

  • Einfach zu installieren
  • Unterstützt die Replikationsmodi Multi-Master, Master-Slave und vollständige Kopie
  • Es kann verwendet werden, um Datenbanken zu aktualisieren
  • Die Replikation kann zwischen verschiedenen PostgreSQL-Versionen erfolgen

Nachteile der Verwendung von Bucardo

  • Da es sich um eine Trigger-basierte Replikation handelt, kann die Leistung eine Herausforderung darstellen
  • Schemaänderungen wie DDLs können die Replikation unterbrechen
  • Das Replizieren einer großen Anzahl von Tabellen kann einen Wartungsaufwand verursachen
  • Die Infrastrukturressourcen müssen für eine gut funktionierende Replikation optimiert werden, andernfalls kann die Konsistenz nicht erreicht werden.

Logische PostgreSQL-Replikation

Die logische Replikation ist eine revolutionäre integrierte Funktion von PostgreSQL, die hilft, einzelne Tabellen über WAL-Einträge zu replizieren. Als WAL-basierte Replikation (ähnlich der Streaming-Replikation) hebt sich pg logical von anderen Tools zur Tabellenreplikation ab. Das Replizieren von Daten über WAL-Einträge ist immer der zuverlässigste und leistungsfähigste Weg, um Daten im Netzwerk zu replizieren. Fast alle Tools auf dem Markt bieten Trigger-basierte Replikation mit Ausnahme der logischen Replikation.

Vorteile der Verwendung der logischen PostgreSQL-Replikation

  • Die beste Option, wenn Sie eine einzelne Tabelle oder einen Satz von Tabellen replizieren möchten
  • Es ist eine gute Option, wenn bestimmte Tabellen aus verschiedenen Datenbanken zu einer einzigen Datenbank (wie Data Warehousing oder Berichtsdatenbanken) für Berichts- oder Analysezwecke migriert werden müssen
  • Kein Ärger mit Triggern

Nachteile der Verwendung der logischen PostgreSQL-Replikation

  • Fehlverwaltung von WAL-Dateien/WAL-Archivdateien kann Herausforderungen für die logische Replikation darstellen
  • Wir können keine Tabellen ohne primäre oder eindeutige Schlüssel replizieren
  • DDLs und TRUNCATE werden nicht repliziert
  • Die Replikationsverzögerung könnte zunehmen, wenn die WALs entfernt werden. Das bedeutet, dass die Replikation und die WAL-Verwaltung einander ergänzen müssen, um sicherzustellen, dass die Replikation nicht unterbrochen wird
  • Große Objekte können nicht repliziert werden

Hier sind einige weitere Ressourcen, die Ihnen helfen, die logische PostgreSQL-Replikation und die Unterschiede zwischen ihr und der Streaming-Replikation besser zu verstehen.

Fremddaten-Wrapper

Während Foreign Data Wrapper die Daten nicht wirklich replizieren, wollte ich diese Funktion von PostgreSQL hervorheben, da sie DBAs dabei helfen kann, etwas Ähnliches wie die Replikation zu erreichen, ohne die Daten tatsächlich zu replizieren. Das bedeutet, dass die Daten nicht von der Quelle zum Ziel repliziert werden und Anwendungen von der Zieldatenbank aus auf die Daten zugreifen können. Die Zieldatenbank hat nur eine Tabellenstruktur mit einem Link, der Host- und Datenbankdetails der Quelltabelle enthält, und wenn die Anwendung die Zieltabelle abfragt, werden die Daten ähnlich wie bei Datenbanklinks von der Quelldatenbank in die Zieldatenbank gezogen. Wenn FDWs helfen können, können Sie den Aufwand für die Replikation der Daten über das Netzwerk vollständig vermeiden. Oft geraten wir in eine Situation, in der Berichte auf einer entfernten Zieldatenbank ausgeführt werden können, ohne dass die Daten physisch vorhanden sein müssen.

FDWs sind in den folgenden Situationen eine großartige Option -

  • Wenn Sie kleine und statische Tabellen in der Quelldatenbank haben, dann lohnt es sich nicht wirklich, die Daten darüber zu replizieren
  • Kann sehr vorteilhaft sein, wenn Sie sehr große Tabellen in der Quelldatenbank haben und aggregierte Abfragen in der Zieldatenbank ausführen.

Vorteile der Verwendung von Foreign Data Wrappern

  • Das Replizieren von Daten kann vollständig vermieden werden, was Zeit und Ressourcen sparen kann
  • Einfach zu implementieren
  • Die übertragenen Daten sind immer die neuesten
  • Kein Wartungsaufwand

Nachteile der Verwendung fremder Data Wrapper

  • Strukturelle Änderungen an der Quelltabelle können sich auf die Anwendungsfunktionalität in der Zieldatenbank auswirken
  • Hängt stark vom Netzwerk ab und kann je nach Art der ausgeführten Berichte einen erheblichen Netzwerk-Overhead verursachen
  • Es wird ein Leistungsaufwand erwartet, wenn die Abfragen mehrmals ausgeführt werden, da die Daten bei jeder Ausführung der Abfrage über das Netzwerk aus der Quelldatenbank gezogen werden müssen und auch einen Leistungsaufwand für die Quelldatenbank darstellen können
  • Jede Belastung der Quelle kann die Leistung von Anwendungen in der Zieldatenbank beeinträchtigen

Schlussfolgerung

  • Das Replizieren von Tabellen kann verschiedenen kritischen geschäftlichen Zwecken dienen
  • Kann verteilte parallele Abfragen in verteilten Umgebungen unterstützen
  • Eine synchrone Implementierung ist nahezu unmöglich
  • Infrastruktur muss ausreichend ausgestattet sein, was mit Kosten verbunden ist
  • Eine großartige Option zum Aufbau einer integrierten zentralisierten Datenbank für Berichterstellungs- und Analysezwecke