Also, um es mal zu erklären:
Es gibt 2 Arten, Backups zu machen. Fangen wir mit der trivialen Art an: pg_dump und pg_dumpall. Diese Programme erstellen einen Dump, wir reden auch von einem logischen Backup. Diesen Dump erstellt die Datenbank (es wird also alles durch die Datenbank gezogen) und es kommt ein ASCII-File raus, den man u.U. auch auf einer anderen DB mit einer anderen Version einspielen kann, den ich editieren kann, aus dem ich nur eine spezielle Tabelle rausziehen kann etc. (gut, der Dump kann auch als binäres Format oder Verzeichnisformat rauskommen, das sind spezielle Möglichleiten, die ich hier mal weglasse). Vor- und Nachteile:
- menschlich lesbar
- mehr oder weniger DB- und versionsabhängig
- Restore einzelner Objekte mehr oder weniger einfach möglich
- hohe Belastung der DB durch IO, aber auch durch Sperren in der DB und damit negative Seiteneffekte (z.B. auf VACUUM oder DDL-Befehle)
Die andere Möglichkeit sind physische Backups. Hier kopiert man einfach im laufenden Betrieb der Datenbank das Datenverzeichniss weg. Z.B. mit tar oder rsync oder so, rein auf Betriebssystemebene.
Nun kann das natürlich bei Datenbanken im TB-Bereich auch mal Stunden dauern, und die DB ist weiter aktiv und schreibt während dieser Zeit munter weiter in das Datenverzeichniss. Die Folge ist leicht verständlich: das Backup ist nicht konsistent!
Wie löst man das Problem?
Man informiert die DB über den Start einer solchen Aktion, dazu gibt es pg_start_backup(). Das macht im wesentlichen eines: einen Vermerkt im Transaktionslog, daß ein physisches Backup läuft. Dann kopiert man das Filesystem weg - egal wie lange das dauert. Wenn man fertig ist, ruft man pg_stop_backup() auf, das vermerkt das Ende des Backups im Transaktionslog.
Um nun z.B. auf einem frisch installierten Server das Backup einzuspielen, kopiert man einfach das erstellte Abbild in das Datenverzeichnis. Dieses ist natürlich nicht konsistent. Was passiert bei einem Start der DB? Sie erkennt, daß das Abbild nicht konsistent ist - und sucht nach den angefallenen Transaktionsdateien. Findet es diese, findet die DB auch den Start des Backups. Ab diesem Punkt wird nun das Transaktionslog (welches binär ist und Befehle a la 'schreibe in Datei X and Offset Y Byte Z rein') abgespielt. So lange, bis es die Ende-Markierung des Backups findet. Zu exakt diesem Zeitpunkt enthält das Datenverzeichniss nun eine exakte Kopie der gesicherten Servers ZM ZEITPUNKT DES ENDES das Backups. Das ist der frühest mögliche konsistente Wiederherstellungszeitpunkt.
Man kann jetzt weiter das Transaktionslog abspielen, entweder bis zu einem bestimmten Zeitpunkt (dann habe ein Point-In-Time-Recovery gemacht) oder ich füttere weiter Transaktionsdateien nach, die auf dem Master anfallen - dann habe ich eine Replikation.
Was ist nun falsch am Tutorial? Der angegebene Wiederherstellungszeitpunkt war VOR Ende des Base-backups, aber zu diesem Zeitpunkt ist das erstellte Backup inkonsistent.
Bei unserem Kunden sah das dann so aus:
Code:
2017-09-28 11:40:08 UTC [7356-1] postgres@postgres FATAL: the database system is starting up
2017-09-28 11:40:08 UTC [7352-3] LOG: starting point-in-time recovery to 2017-09-27 14:43:08.740875+00
2017-09-28 11:40:08 UTC [7352-4] LOG: restored log file "00000001000001B2000000B5" from archive
2017-09-28 11:40:08 UTC [7352-5] LOG: redo starts at 1B2/B5000098
2017-09-28 11:40:08 UTC [7352-6] LOG: recovery stopping before commit of transaction 172580, time 2017-09-27 14:58:35.994506+00
2017-09-28 11:40:08 UTC [7352-7] FATAL: requested recovery stop point is before consistent recovery point
2017-09-28 11:40:08 UTC [7351-1] LOG: startup process (PID 7352) exited with exit code 1
2017-09-28 11:40:08 UTC [7351-2] LOG: terminating any other active server processes
Also: bei einem Dump sehe ich nach einem Restore den Zustand der DB zum Startzeitpunkt des Dumps - egal wie lange der Dump dauert. Bei einem physischen Backup sehe ich frühestens zum Ende des Backups einen konsistenten Zustand der Datenbank - oder später. Ich brauche dazu IMMER das kopierte Datenverzeichniss PLUS alle seit dem Start der Kopieraktion angefallenen Transaktionsdateien, und es muß IMMER mindestens der Teil des Transaktionslogs abgespielt werden, der während des Erstellens des physischen Backups angefallen ist. Nur so ist das Backup konsistent. Im Tutorial wird aber gesagt, daß als Recovery-Zeitpunkt der Startzeitpunkt angegeben werden soll bzw. kann - das ist schlicht falsch.
