PostgreSQL - Warm-Standby Datenbank Recovery
Nachdem ich ja kürzlich beschrieben habe, wie man eine Warm-Standby Datenbank mit PostgreSQL einrichtet, hier nun der Teil wie man die Standby Datenbank in Betrieb nimmt, wenn die primäre Datenbank ausgefallen ist.
Gehen wir mal davon aus, das der Rechner mit der primären Datenbank ausgefallen ist und die Standby Datenbank soll übernehmen. Die Slave-DB (Standby) hängt der Master-DB 60 Sek. hinterher. Es fallen also auf jeden Fall alle Transaktionen unterm Tisch, die in den letzten 60 Sek. gelaufen und nicht abgeschlossen wurden!
Die Slave-DB befindet sich ja im Dauerrecoverymodus und spielt laufend die Transaktionslogs ein, die von der Master-DB rübergeschoben werden. Um die DB aus dem Recoverymodus zu bringen, wurde in /data/pgsql/data/$DBNAME/recovery.conf ein Trigger festgelegt im recovery_command und der sieht so aus: -t /tmp/pgsql.fin.$DBNAME ($DBNAME wie immer im vorhergehenden Artikel schon beschrieben durch den Instanznamen ersetzen).
D.h. wenn wir jetzt als User postgres(!) per touch /tmp/pgsql.fin.$DBNAME diesen Trigger anlegen, beendet das pg_standby Programm den Recovery-Modus und fährt die DB hoch. Das kann eine Weile dauern, bis die Transaktionslogs nachgefahren wurden. Am Besten beobachtet man dabei das Postgres-Logfile. Die Ausgabe sieht dann in etwa so aus:
LOG: could not open file "pg_xlog/000000010000003F000000A3"
(log file 63, segment 163): No such file or directory
LOG: redo done at 3F/A2007F80
LOG: last completed transaction was at log time 2009-03-03 14:23:30.134095+01
LOG: restored log file "000000010000003F000000A2" from archive
LOG: selected new timeline ID: 2
LOG: archive recovery complete
LOG: checkpoint starting: shutdown immediate
LOG: checkpoint complete: wrote 10 buffers (0.0%); 0 transaction log
file(s) added, 0 removed, 0 recycled; write=0.015 s, sync=0.001s, total=0.092 s
DEBUG: transaction ID wrap limit is 2147484026, limited by database "template1"
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
Die Meldung could not open file ... ist ok. Die Slave-DB hätte jetzt eigentlich das nächste Transaktionslog erwartet. Aber da die Master-DB das noch nicht geliefert hat, ist auch keines da und die DB macht einen Rollback auf das letzte Log 000000010000003F000000A2. Das Recovery selbst kann auch nochmal etwas dauern (ca. 1-2 Min.). Wenn database system is ready to accept connections im Log erscheint, ist die DB oben - aber noch nicht erreichbar über eine IP-Adresse.
Da in der Slave-DB in der postgresql.conf die listen_addresses vermutlich nur auf localhost stehen, kann man die DB auch nur vom DB-Rechner selbst aus erreichen. Man muss also nun erstmal ein Interface hochziehen, das die gleiche IP hat wie die Master-DB hatte (aber auch nur wenn der Master-Rechner wirklich nicht mehr am Netz hängt) und dann den Eintrag in der postgresql.conf entsprechend abändern. Dann die DB durchstarten und das war's dann eigentlich.
Sollte die DB auf dem Rechner bleiben, muss natürlich das Backup-Skript nachgezogen werden und was man sonst noch so Adimistratives braucht.
Nicht unerwähnt bleiben soll, das man diese Standby-Sache hier natürlich auch automatisieren kann und mittels Heartbeat dafür sorgen kann, das der Failover automatisch stattfindet, wenn die Master-DB ausfallen sollte. Aber das ist ein anderes Kapitel ;-)
Posted at 08:51vorm. März 10, 2009 by cetixx in Tipps | Kommentare [0]