"Recovering" des Master mit pg_basebackup

Hallo,

ich bereite gerade ein Upgrade unseres produktiven Postgresql 9.0 mit streaming replication, auf 9.1 vor und teste alle Möglichen Dinge. Eines davon ist kontrollierter switchover/switchback der Instanzen.

— Kurzer Überblick: —
Das Setup ist wie folgt.:

1 Master (A)
1 Slave (B)
Der Slave repliziert per streaming replication (WAL sending) asynchron vom Master. Der Slave befindet sich dafür im hot standby
Das ganze machen wir ohne WAL archiving. Benötigen wir momentan nicht. Wir machen einmal pro Nacht einen Dump der dann auf einem Backupserver landet. Aber das nur am Rande, zur Vorstellung.

Folgendes sind die Anforderungen bzw der pg9.0-Stand:

  1. Switchover: zum Slave - Bei einem Fehler auf dem Master. Dafür legen wir das trigger file an und nach ein paar Sekunden ist der Slave bereit für RW-Conenctions
  2. Switchback: Server A soll wieder Master werden und Server B wieder Slave. Bei Postgresql 9.0 machen wir das gerade in einem zweistufigen Prozess:
  3. Zuerst Server A zum Slave machen. Master ist Server B.
  4. Danach Server A wieder zum Master machen und Server B wieder zum Slave.
  5. Das ganze geht per weimaligem pg_start_backup, rsync, pg_stop_backup in jeweils die andere Richtung

In Postgres 9.1 gibt es ja nun pg_basebackup was u.a. empfohlen ist um eine Replikation aufzusetzen und auch sehr gut funktioniert.

Ich habe das switchback-Prozedere nun wie folgt angepasst:
Es findet kein doppelter rsync mehr statt sondern mache ein Backup des data directories von Server A und führe ein pg_backbackup mit der option -x (für die xlogs) aus um die Daten einmalig auf den Master zu syncen und kopiere die pg_hba.conf aus dem backup in das gesyncte data dir. Das geht ohne Fehler.
Dann mache ich fogendes:

  1. Renaming auf Server B: recovery.done -> recovery.conf
  2. Neustart von Server B als Slave
  3. Neustart von Server A (nun wieder als Master)

Das klappt alles wunderbar. Der Slave fängt an zu replizieren und alle auf dem Master geänderten Daten landen fast sofort auf dem Slave und sind dort lesbar.

Das log-file des Master sieht wie folgt aus:

2011-11-24 19:20:28 CET   LOG:  creating missing WAL directory "pg_xlog/archive_status"2011-11-24 19:20:28 CET   LOG:  database system was not properly shut down; automatic recovery in progress
2011-11-24 19:20:28 CET   LOG:  redo starts at 0/1C000020
2011-11-24 19:20:28 CET   LOG:  consistent recovery state reached at 0/1D000000
2011-11-24 19:20:28 CET   LOG:  could not open file "pg_xlog/00000004000000000000001D" (log file 0, segment 29): No such file or directory
2011-11-24 19:20:28 CET   LOG:  redo done at 0/1C0000D8
2011-11-24 19:20:28 CET postgres postgres FATAL:  the database system is starting up
2011-11-24 19:20:28 CET   LOG:  autovacuum launcher started
2011-11-24 19:20:28 CET   LOG:  database system is ready to accept connections

Und hier ist nun das “Problem”. Mich macht folgende Zeile nervös:

could not open file "pg_xlog/00000004000000000000001D" (log file 0, segment 29): No such file or directory

Ist das ein Fehler oder eine zu vernachlässigende Meldung? Habe ich evtl einen Schritt übersehen?
Beim pg_basebackup erzeugt er das vorhergehende xlog (im o.g. Fall: pg_xlog/00000004000000000000001C) und nach o.g. Meldung dann das fehlende File (pg_xlog/00000004000000000000001D)
Ich kann sonst weder im log von Server A, noch von Server B, irgendwelche Fehler finden.

Evtl habt Ihr ja eine idee und könnt mir da helfen?

Viele Grüße,
Stefan

Wieso kopierst du die xlogs mit?
Du willst doch Replikation haben und kein Backup, oder?

Du meinst beim switchback auf server A sodas er wieder der Master ist? Oder wo meinst Du? Im Falle des switchbacks kopiere ich mit der Option -x weil sonst der server nicht standalone startet. Zumindest ist es das was ich beobachtet habe

“switchback”? Also das war zuerst der Master, dann der Slave, dann wieder der Master?
Kopierst du die WAL Dateien in beide Richtungen?

Hallo,

also das Szenario ist wie folgt:

Server A (Master) , Server B (Slave)

  1. Normalfall: B repliziert von A per streaming.
  2. Fehlerfall: A fällt aus und B ist standalone (also keine replikation)
  3. Switchback: A wird wieder verfügbar gemacht und soll wieder Master werden. Schritte um das zu erreichen:
  4. pg_basebackup -x um von B die Daten nach A zu senden damit Beide den gleichen Stand haben
  5. Start von A als Master
  6. Start von B als Slave

“A” war also nie Slave und soll es auch nie werden.

O.g Switchback funktioniert wunderbar. Bis auf die Meldung im Log aus dem ersten Posting.

Ein seperates kopieren der WAL geschieht bisher nicht. Bzw nur über das was per “-x” mitkommt und das ist lt Doku:

Includes the required transaction log files (WAL files) in the backup. This will include all transaction logs generated during the backup. If this option is specified, it is possible to start a postmaster directly in the extracted directory without the need to consult the log archive, thus making this a completely standalone backup.

Wir haben bisher keine Anforderungen an ein PITR ausser das wir den Stand vor dem switch wieder herstellen müssen und dazu machen wir unmittelbar vorher einen Dump von B. Darum reicht das was per “-x” mitkommt eigentlich vollkommen aus.

Ich habe aber gerade noch einmal einen switchback versucht und nach dem pg_basebackup alle xlogs per rsync zusätzlich kopiert. Da kommt die gleiche Meldung und das xlog was er bemängelt gibt es auch auf Server B vorher nicht (von dem die xlogs kommen).

Mir geht es eben darum ob die Meldung vernachlässigbar ist (die Datei wir nach der Meldung angelegt und das System läuft ansonsten fehlerfrei, inklusive Replikation und Erzeugen der xlogs) oder ob es zu längerfristigen Problemen kommen könnte? Zumindest das Testsystem auf dem ich die Replikation teste läuft seit 1 1/2 Wochen ohne Fehler.

Grüsse,
Stefan

Du bist dir schon darüber im Klaren, das du zwischen dem pg_basebackup und dem Umschalten eine gewisse Menge Transaktionen verlierst?
Du solltest A zuerst als Slave aufsetzen und dann irgendwann umschalten.

Nein, darum frage ich ja :wink:

Kannst Du mir auch erklären warum ich Transaktionen verliere? Denn zum Zeitpunkt des switches zurück ist sicher gestellt das weder Transaktionen stattfinden, noch irgendjemand au�er mir zur DB verbunden ist. Es sei denn Postgresql macht komische Sachen das es zwar sagt das keine Transaktionen stattfinden aber da noch irgendwas l�uft oder doch nicht persistiert ist.

Also was läuft anders wenn ich in einer “isolierten” Umgebung wo im Moment keinerlei Transaktionen laufen können erst A zum Slave mache und dann den Spieß umdrehe und wieder B zum Slave mache, als wenn ich B nach A synce und A aber sofort Master ist und B wieder Slave? Wie gesagt, es finden definitiv keine Transaktionen zum Zeitpunkt des syncs statt.
Es sei denn Du meinst mit Transaktionen irgendwas anderes oder wie gesagt PG macht intern komische Dinge?

Das genau habe ich noch in keiner Doku gefunden und bisher konnte mir das auch keiner beantworten. Ich werde auf jeden Fall mal noch etwas herumspielen aber vllt weißt Du ja eine Antwort oder eine Stelle wo genau das erklärt ist?

Cheers

Ah ok, ich habe nirgendwo gesehen, das du Änderungen verbietest. Ansonsten würdest du Transaktionen verlieren.
Aber das wäre eigentlich nicht notwendig - das ließe sich auch ohne dieses Verbot hinbekommen.
Btw, Prozesse wie z. B. Vacuum ändern die Datenbank trotzdem noch, aber das ändert keine Daten, nur interne Strukturen.

Die Fehlermeldung ist übrigens kein Problem - solange die fehlende Datei wirklich eine ist, die auf dem Master nicht vorhanden ist.
Sobald keine Logdatei mehr vorhanden ist, stoppt das Recovery und die DB fährt hoch.

Aber an der Stelle würde ich dir trotzdem empfehlen, dich mit dem Thema näher zu beschäftigen. Sieht mir alles wie ein Hack aus.
Es gibt diverse Literatur, die die Replikation gut erklärt. Planet PostgreSQL hat auch einige gute Postings dafür.

sorry, also der Tomcat ist herunter gefahren und damit die einzige mögliche Verbindung zur DB gekappt. Habe übrigends festgestellt das wenn ich alle xlogs zusätzlich zum pg_basebackup von B nach A rsynce bekomme ich ein ganz anderes Problem.
(Server A und Server B starten und Server B fängt an zu replizieren. Nach ein paar Minuten bricht Server B aber die Replikation ab und schreibt das log file mit "Invalid Record length at … " voll.) Lässt sich mit einem ordentlichen hin und her syncen verhindern. Das möchte ich aber aus verschiedenen Gründen verhindern. Ich bin leider nur der der das Szenario skriptet, ausgeführt wird es vom Support. Und für die Leute will ich es besser so einfach wie möglich halten.

pg_basebackup hat bisher diese Probleme nicht bereitet.

Ich habe zu PG9.0-Zeiten mal im IRC-Channel zu dem Thema eine Frage gehabt und da hieß es das mit 9.1 das Thema Recovery des “alten” Masters (also Server A) und damit mein Szenario besser gehandhabt werden soll. Bisher sieht es danach aus . Aber evtl werd ich direkt im Channel nochmal nachfragen.

Nun ist aber meine Frage ja beantwortet. Vielen Dank f�r Deine Nerven mit mir :wink:

Cheers,
Stefan

“Invalid Record length” bedeutet, das du höchstwahrscheinlich veraltete Logfiles verwendest.
Wie ich sagte: überdenke bitte den gesamten Prozess noch mal.

Ja wie gesagt, ich habe wohl mittlerweile alle Möglichkeiten einen switchback zu machen ausprobiert. Teilweise einfach nur um festzustellen wie sich PG verhällt. Habe bisher allerdings keine negativen Unterschiede zw “Master erst Slave machen und dann Master” und "Master gleich zum Master machen (per pg_basebackup -x) finden können (also solange man auf die WALs verzichten kann und alles andere aus ist natürlich). Wie gesagt hier geht es nicht um beliebiges PITR sondern um die maximal letzten 5 Minuten bzw den Stand direkt vor dem switchback. Und der ist per Dump garantiert.

Es wird sowieso noch ein paar Tage dauern bis das upgrade statt findet. Evtl bis nach Weihnachten. Bis dahin werde ich verschiedene weitere Tests fahren. Falls mir noch was auffällt schreibe ich nochmal. Solltest Du aber auf wichtige Details stoßen, darfst Du natürlich auch antworten :wink:

Cheers,
Stefan

Okay, mache es jetzt über doch über den traditionellen Weg. Ist glaube ich besser. :wink: Aber danke für die Diskussion. So konnte ich wenigstens ein paar Fragen ausräumen.

Hallo Stefan,

ich hab die Diskussion zu dem Switchback zugegeben nur kurz überflogen, aber noch eine kleine Anregung gehabt.
Ich stand mal vor einem ähnlichen Problem das Switchback-Verfahren zu Scripten um einen Master/Standby Cluster umzusetzen.
Ich habe mich damals dafür entschieden ganz auf ein explizites Switchback zu verzichten.
Beide Server A und B waren identisch ausgestattet und konfiguriert.
B repliziert vom Master A
Fällt A aus, so wird B über den Trigger zum Master umgeschaltet (B bleibt ab diesen Moment für immer der Master, bis er mal ausfallen sollte)
Nun wird A einfach zum Slave deklariert, führt ein basebackup durch und fängt mit der Streaming-Replication an.

Damit spart man sich eine erneute Ausfallzeit beim Switchback. Vorausgesetzt beide Server sind ähnlich ausgestattet und können die Last tragen.

Grüße Max