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:
- 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
- Switchback: Server A soll wieder Master werden und Server B wieder Slave. Bei Postgresql 9.0 machen wir das gerade in einem zweistufigen Prozess:
- Zuerst Server A zum Slave machen. Master ist Server B.
- Danach Server A wieder zum Master machen und Server B wieder zum Slave.
- 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:
- Renaming auf Server B: recovery.done -> recovery.conf
- Neustart von Server B als Slave
- 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