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

Unterschied zwischen Stream-Replikation und logischer Replikation

TL;DR :Die logische Replikation sendet zeilenweise Änderungen, die physische Replikation sendet Plattenblockänderungen. Logische Replikation ist für einige Aufgaben besser, physische Replikation für andere.

Beachten Sie, dass die logische Replikation in PostgreSQL 12 (aktuell zum Zeitpunkt der Aktualisierung) stabil und zuverlässig, aber ziemlich eingeschränkt ist. Verwenden Sie die physische Replikation, wenn Sie diese Frage stellen.

Streaming-Replikation kann sein logische Replikation. Es ist alles etwas kompliziert.

WAL-Versand vs. Streaming

Es gibt zwei Hauptwege, um Daten in PostgreSQL vom Master zum Replikat zu senden:

  • WAL-Versand oder kontinuierliche Archivierung , wo einzelne Write-Ahead-Log-Dateien aus pg_xlog kopiert werden durch den archive_command läuft auf dem Master an einen anderen Ort. Ein restore_command in der recovery.conf des Replikats konfiguriert wird auf dem Replikat ausgeführt, um die Archive abzurufen, damit das Replikat die WAL wiedergeben kann.

    Dies wird für die Replikation zu einem bestimmten Zeitpunkt verwendet (PITR), das als Methode der kontinuierlichen Sicherung verwendet wird.

    Es ist keine direkte Netzwerkverbindung zum Masterserver erforderlich. Die Replikation kann lange Verzögerungen haben, insbesondere ohne archive_timeout einstellen. Der WAL-Versand kann nicht für die synchrone Replikation verwendet werden.

  • Streaming-Replikation , wobei jede Änderung direkt über eine TCP/IP-Verbindung an einen oder mehrere Replikatserver gesendet wird, während sie stattfindet. Die Replikate müssen eine direkte Netzwerkverbindung haben, die der Master in ihrer recovery.conf konfiguriert hat 's primary_conninfo Option.

    Die Streaming-Replikation hat wenig oder keine Verzögerung, solange das Replikat schnell genug ist, um Schritt zu halten. Es kann für die synchrone Replikation verwendet werden . Sie können die Streaming-Replikation nicht für PITR verwenden, daher ist sie für kontinuierliche Sicherungen nicht sehr nützlich. Wenn Sie eine Tabelle auf dem Master löschen, oops, wird sie auch auf den Replikaten gelöscht.

Daher haben die beiden Methoden unterschiedliche Zwecke.

Asynchrones vs. synchrones Streaming

Dazu kommt noch synchron und asynchron Streaming-Replikation:

  • In asynchroner Streaming-Replikation die Replik(en) dürfen zeitlich hinter den Master zurückfallen, wenn der Master schneller/beschäftigter ist. Wenn der Master abstürzt, können Sie Daten verlieren, die noch nicht repliziert wurden.

    Wenn das asynchrone Replikat zu weit hinter dem Master zurückbleibt, wirft der Master möglicherweise Informationen weg, die das Replikat benötigt, wenn max_wal_size (früher wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal(was pg_xlog) könnte voll werden und den Master daran hindern zu arbeiten, bis Speicherplatz freigegeben wird, wenn max_wal_size zu hoch ist oder ein Steckplatz verwendet wird.

  • In synchroner Replikation Der Master beendet die Übergabe erst, wenn ein Replikat bestätigt hat, dass es die Transaktion erhalten hat. Sie verlieren niemals Daten, wenn der Master abstürzt und Sie auf ein Replikat umschalten müssen. Der Master wird niemals Daten wegwerfen, die das Replikat benötigt, oder sein xlog füllen und aufgrund von Replikationsverzögerungen keinen Speicherplatz mehr haben. Im Gegenzug kann es dazu führen, dass der Master langsamer wird oder sogar aufhört zu arbeiten, wenn Replikate Probleme haben, und es hat immer eine gewisse Leistungsbeeinträchtigung auf dem Master aufgrund von Netzwerklatenz.

    Wenn mehrere Replikate vorhanden sind, ist jeweils nur eines synchron. Siehe synchronous_standby_names .

Sie können keinen synchronen Protokollversand haben.

Sie können den Protokollversand und die asynchrone Replikation tatsächlich kombinieren, um sich davor zu schützen, ein Replikat neu erstellen zu müssen, wenn es zu weit zurückliegt, ohne das Risiko einzugehen, dass der Master beeinträchtigt wird. Dies ist eine ideale Konfiguration für viele Bereitstellungen, kombiniert mit der Überwachung, wie weit sich das Replikat hinter dem Master befindet, um sicherzustellen, dass es innerhalb akzeptabler Notfallwiederherstellungsgrenzen liegt.

Logisch vs. physisch

Darüber hinaus das wir haben logisch vs. physisch Streaming-Replikation, wie in PostgreSQL 9.4 eingeführt:

  • In physischer Streaming-Replikation Änderungen werden fast auf Plattenblockebene gesendet, wie "at offset 14 of disk page 18 of relation 12311, wrote tuple with hex value 0x2342beef1222....".

    Die physische Replikation sendet alles :der Inhalt jeder Datenbank in der PostgreSQL-Installation, alle Tabellen in jeder Datenbank. Es sendet Indexeinträge, es sendet die gesamten neuen Tabellendaten, wenn Sie VACUUM FULL , es sendet Daten für Transaktionen, die zurückgesetzt wurden usw. Es erzeugt also viel "Rauschen" und sendet viele überschüssige Daten. Es erfordert auch, dass das Replikat vollständig identisch ist, sodass Sie nichts tun können, was eine Transaktion erfordern würde, wie das Erstellen von temporären oder nicht protokollierten Tabellen. Das Abfragen des Replikats verzögert die Replikation, sodass lange Abfragen des Replikats abgebrochen werden müssen.

Im Gegenzug ist es einfach und effizient, die Änderungen auf das Replikat anzuwenden, und das Replikat ist zuverlässig genau dasselbe wie das Master. DDL wird wie alles andere transparent repliziert, sodass keine besondere Behandlung erforderlich ist. Es kann auch große Transaktionen streamen, während sie passieren, sodass selbst bei großen Änderungen nur eine geringe Verzögerung zwischen dem Commit auf dem Master und dem Commit auf dem Replikat auftritt.

Die physische Replikation ist ausgereift, gut getestet und weit verbreitet.

  • logische Streaming-Replikation , neu in 9.4, sendet Änderungen auf einer höheren Ebene und viel selektiver.

Es repliziert jeweils nur eine Datenbank. Es sendet nur Zeilenänderungen und nur für festgeschriebene Transaktionen, und es muss keine Vakuumdaten, Indexänderungen usw. senden. Es kann selektiv Daten nur für einige Tabellen innerhalb einer Datenbank senden. Dies macht die logische Replikation viel bandbreiteneffizienter.

Der Betrieb auf einer höheren Ebene bedeutet auch, dass Sie Transaktionen auf den Replikatdatenbanken durchführen können. Sie können temporäre und nicht protokollierte Tabellen erstellen. Sogar normale Tische, wenn Sie möchten. Sie können fremde Datenwrapper verwenden, Ansichten erstellen, Funktionen erstellen, was immer Sie möchten. Es besteht auch keine Notwendigkeit, Abfragen abzubrechen, wenn sie zu lange laufen.

Die logische Replikation kann auch verwendet werden, um eine Multi-Master-Replikation in PostgreSQL aufzubauen, was mit der physischen Replikation nicht möglich ist.

Im Gegenzug kann es jedoch (derzeit) keine großen Transaktionen streamen, während sie stattfinden. Es muss warten, bis sie sich verpflichten. Es kann also eine lange Verzögerung zwischen dem Festschreiben einer großen Transaktion auf dem Master und der Anwendung auf das Replikat geben.

Transaktionen werden strikt in der Commit-Reihenfolge wiedergegeben, sodass kleine schnelle Transaktionen hinter einer großen Transaktion stecken bleiben und eine ganze Weile verzögert werden können.

DDL wird nicht automatisch gehandhabt. Sie müssen die Tabellendefinitionen zwischen Master und Replikat selbst synchron halten, oder die Anwendung, die die logische Replikation verwendet, muss dazu über eigene Einrichtungen verfügen. Es kann kompliziert sein, dies richtig zu machen.

Der Anwendungsprozess selbst ist komplizierter als "einige Bytes schreiben, wo ich dazu aufgefordert werde". Es benötigt auch mehr Ressourcen auf dem Replikat als die physische Replikation.

Aktuelle logische Replikationsimplementierungen sind nicht ausgereift oder weit verbreitet oder besonders einfach zu verwenden.

Zu viele Optionen, sagen Sie mir, was ich tun soll

Puh. Kompliziert, oder? Und ich bin noch nicht einmal auf die Details der verzögerten Replikation, Slots, max_wal_size eingegangen , Zeitachsen, Funktionsweise der Werbung, Postgres-XL, BDR und Multimaster usw.

Also, was sollten Sie tun ?

Es gibt nicht die eine richtige Antwort. Andernfalls würde PostgreSQL nur diesen einen Weg unterstützen. Aber es gibt ein paar gängige Anwendungsfälle:

Für Sicherung und Notfallwiederherstellung Verwenden Sie pgbarman um Basissicherungen zu erstellen und WAL für Sie aufzubewahren, was eine einfach zu verwaltende kontinuierliche Sicherung ermöglicht. Sie sollten trotzdem regelmäßig pg_dump durchführen Backups als zusätzliche Versicherung.

Für Hochverfügbarkeit ohne Datenverlustrisiko Verwenden Sie die synchrone Streaming-Replikation.

Für hohe Verfügbarkeit mit geringem Datenverlustrisiko und besserer Leistung Sie sollten die asynchrone Streaming-Replikation verwenden. Aktivieren Sie entweder die WAL-Archivierung als Fallback oder verwenden Sie einen Replikationsslot. Überwachen Sie mit externen Tools wie Icinga, wie weit das Replikat hinter dem Master zurückliegt.

Referenzen