Ist eine absichtlich verzögerte Replikation möglich?

Hallo,

ist es eigentlich möglich eine Replikation um eine bestimmte Zeit verzögert laufen zu lassen?
Also z. B. auf einen zweiten Rechner 6 Stunden in der Vergangenheit.

Liebe Grüße

Michael

So als kontinuierlicher Prozess IMHO nicht, aber PITR existiert.

Andreas

Im Prinzip ist es möglich, obwohl ich die Lösung vom Andreas über PITR bevorzugen würde.

Ansonsten kannst du das über das WAL-Shipping scripten.

Auf dem Master-Server kannst du den archive_command in der postgresql.conf definieren. Das kann auch ein beliebiges Script sein. Das Script bekommt dann von Postgresql den Pfad zu der letzten abgeschlossenen WAL-Datei übermittelt. Nun kannst du im Script überprüfen ob die WAL-Datei 6 Stunden alt ist. Wenn ja wird sie zum Slave verschickt und das Script beendet mit dem Returnwert 0. Das signalisiert Postgresql, dass alles ok ist und mit der nächsten WAL-Datei weiter gemacht werden kann. Ist die Datei jünger als 6 Stunden, müsste das Script mit dem Wert 1 beenden. Das sagt Postgresql dass die Datei nicht sicher Archiviert wird und Postgresql führt das Script erneut mit dem Pfad zu der Datei aus bis sie irgendwann nach spätestens 6 Stunden übermittelt werden kann.
Alle dazwichen anfallenden WAL-Dateien wird Postgresql aufheben.

Alternativ kann man das nach dem gleichen Prinzip auf dem Slave Server durchführen. Hier ist es jedoch der recovery_command der WAL-Dateien erst einspielen würde, wenn sie 6 stunden alt sind. Der Vorteil hier wäre, dass der Master die WAL-Dateien immer los wird und die Dateien sich dann auf dem Slave ansammeln würden.

Schau dir mal die Beispiele für das WAL-Shipping in der Postgresql Doku an.

Grüße,

Max

Du möchtest auf gar keinen Fall im Master das “archive_command” verzögern.
Wenn du das tust, bleiben die WAL im xlog-Verzeichnis liegen und das wächst und wächst und wächst.
Außerdem gibt das häßliche Meldungen im Logfile.

Desweiteren sollte man “archive_command” und das Kopieren auf den Slave trennen.
Was passiert, wenn dein Slave offline ist, Timeouts hat oder ähnliches? Genau - der Master wartet auf “archive_command”!

Nun ja, es ist keine kontinuierliche Verzögerung die den pg_xlog Ordner ins unermessliche anwachsen lassen würde. Beim ersten mal wartet Postgres zwar 6 Stunden da drauf bis er die Datei verschicken kann. Die darauf folgende Datei ist aber bereits fast 6 Stunden alt und Postgres wartet nur noch das Intervall ab in dem neue WAL-Dateien angelegt werden (in der regel also nur wenige Minuten). Der pg_xlog Ordner sollte also nicht wachsen und wachsen und wachsen :slight_smile:
Anders natürlich wenn der Slave nicht erreichbar ist, aber dann ist es ja auch gewollt, dass Postgres die WAL-Dateien aufhebt.
Deswegen sehe ich das nicht als sehr problematisch, abgesehen von den Meldungen im Logfile.

@ads Ich verstehe auch nicht wie du archive_command und das Kopieren auf den Slave trennen möchtest?

Aber in der tat wäre es vielleicht sinnvoller die Dateien regulär auf den Slave Server zu replizieren und dort um X-Stunden verzögert einzuspielen. Der Slave Server prüft ja ohnehin ständig nach neuen WAL-Dateien.

Das waren natürlich nur Ideen von mir wie es funktionieren könnte. Getestet habe ich es natürlich nicht, da ich eher auf PITR setzen würde.

Das schaffe ich, indem ich die Dateien erst mal lokal auf den Master irgendwohin kopiere und dann asynchron von dort auf den Slave.
Hat den Vorteil, das man diesen Bereich gesondert überwachen - und ggf. löschen - kann.
Wenn dein Slave nicht erreichbar ist, wächst die Menge der Logfiles in deinem “xlog” Verzeichnis sonst unendlich an und irgendwann ist dein Speicherplatz alle.

Ein nicht erreichbarer Slave sollte nie und nimmer dazu führen, das dein Master auch irgendwann die Arbeit einstellen muss!

@ads
Aber macht Postgres nicht genau das mit dem pg_xlog Ordner schon? Da sorgt bereits ein Mechanismus dafür, dass der Ordner bereinigt wird und ggf. WAL-Dateien aufgehoben werden wenn der Slave nicht erreichbar ist. Wenn dieser Ordner voll laufen sollte, besteht immer noch die Möglichkeit alte WAL-Dateien zu löschen. Da wird man nicht drum rum kommen den Speicher der Partition auf dem System zu überwachen. Ganz egal wie man den archive_command handhabt.

Ja, das macht PostgreSQL so.
Als Admin des Servers bist du jedoch dafür verantwortlich, das die Datenbank und der ganze Server sauber funktioniert.

PostgreSQL macht an der Stelle das, was es am besten kann: für die Sicherheit deiner Daten sorgen.
Es wird also so lange wie möglich die Logfiles aufheben.

Du wiederum sollst dafür sorgen, das der nicht vorhandene Slave nicht dazu führt, das der Master auch irgendwann seine Arbeit einstellen muss.


Wenn man die Logdateien für den Slave auf eine gesonderte Partition oder in ein gesondertes Verzeichnis kopiert, kann PostgreSQL sauber weiter arbeiten und muss sich nicht um diese Dateien kümmern. Sollte der Slave für längere Zeit nicht wieder online kommen, kann man das Verzeichnis oder die Partition löschen und der Master hat wieder Platz zum Schreiben.
Das ist in dem Fall eine Interessenabwägung: der Speicherplatz reicht nicht aus, um alle Logfiles für den Slave aufzuheben - was also machen?
Entweder man lässt das so weiterlaufen und der Master verabschiedet sich als nächstes. Oder man löscht nur die Logfiles für den Slave und der Master läuft weiter.

:slight_smile: gut eigentlich ist das ein separates Thema. Ich habe nur die Erfahrung gemacht, dass man die WAL-Dateien genauso gut auch aus dem pg_xlog Ordner löschen kann wenn es eng wird und ein gesonderter Ordner gar nicht notwendig ist damit PostgreSQL sauber weiter arbeiten kann.

Das möchtest du nicht tun. Glaub mir, das möchtest du nicht wirklich tun.
Lösche niemals etwas auf dem Datenverzeichnis außer du weisst sehr genau, was du tust. Das schließt “pg_xlog” mit ein.