Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 13

Thema: "Recovering" des Master mit pg_basebackup

  1. #1
    mrmarbury ist offline Neuer Benutzer
    Registriert seit
    29.11.2011
    Beiträge
    7

    Frage "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:
      1. Zuerst Server A zum Slave machen. Master ist Server B.
      2. Danach Server A wieder zum Master machen und Server B wieder zum Slave.
      3. 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:

    Code:
    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:
    Code:
    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

  2. #2
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    Wieso kopierst du die xlogs mit?
    Du willst doch Replikation haben und kein Backup, oder?
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  3. #3
    mrmarbury ist offline Neuer Benutzer
    Registriert seit
    29.11.2011
    Beiträge
    7

    Standard

    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

  4. #4
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    "switchback"? Also das war zuerst der Master, dann der Slave, dann wieder der Master?
    Kopierst du die WAL Dateien in beide Richtungen?
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  5. #5
    mrmarbury ist offline Neuer Benutzer
    Registriert seit
    29.11.2011
    Beiträge
    7

    Standard

    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:
      1. pg_basebackup -x um von B die Daten nach A zu senden damit Beide den gleichen Stand haben
      2. Start von A als Master
      3. 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
    Geändert von mrmarbury (01.12.2011 um 13:28 Uhr) Grund: Alle Umlaute kaputt

  6. #6
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  7. #7
    mrmarbury ist offline Neuer Benutzer
    Registriert seit
    29.11.2011
    Beiträge
    7

    Standard

    Nein, darum frage ich ja

    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

  8. #8
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    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.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

  9. #9
    mrmarbury ist offline Neuer Benutzer
    Registriert seit
    29.11.2011
    Beiträge
    7

    Standard

    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

    Cheers,
    Stefan
    Geändert von mrmarbury (01.12.2011 um 16:36 Uhr)

  10. #10
    ads
    ads ist offline Super-Moderator
    Registriert seit
    08.02.2006
    Ort
    MD
    Beiträge
    4.056

    Standard

    "Invalid Record length" bedeutet, das du höchstwahrscheinlich veraltete Logfiles verwendest.
    Wie ich sagte: überdenke bitte den gesamten Prozess noch mal.
    Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören

    Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler

    PostgreSQL Service & Support

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Antworten: 7
    Letzter Beitrag: 03.02.2012, 09:58
  2. Problem "breche Verbindung ab wegen Absturz eines anderen Serverprozesses"
    Von vogelpohl im Forum Allgemeines
    Antworten: 43
    Letzter Beitrag: 12.06.2010, 15:36
  3. Problem Function geht nicht "invalid input syntax for integer: (0,t,)"
    Von cfi im Forum Trigger und Funktionen
    Antworten: 2
    Letzter Beitrag: 05.09.2008, 08:10
  4. "Group-by" und "max" Funktionen verknüpfen
    Von superguddy777 im Forum SQL
    Antworten: 1
    Letzter Beitrag: 22.08.2007, 08:35
  5. OLD.sum(...) ->record "old" has no field "sum"
    Von Mster im Forum Trigger und Funktionen
    Antworten: 5
    Letzter Beitrag: 18.01.2007, 15:00

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Links: Tobias Bauer - IT- und Funkdienstleistungen   -   Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen   -   Funkforum