Re: [BUG] Archive recovery failure on 9.3+. - Mailing list pgsql-hackers
From | Christoph Berg |
---|---|
Subject | Re: [BUG] Archive recovery failure on 9.3+. |
Date | |
Msg-id | 20140213124245.GA25703@msgid.credativ.de Whole thread Raw |
In response to | Re: [BUG] Archive recovery failure on 9.3+. (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Responses |
Re: [BUG] Archive recovery failure on 9.3+.
|
List | pgsql-hackers |
Re: Heikki Linnakangas 2014-02-13 <52FC9468.4050602@vmware.com> > >With 9.1, it works, but 9.2 and 9.3 don't archive anything until I > >remove the "test ! -f" part. (An alternative fix would be to declare > >the behavior ok and adjust that example in the config.) > > Hmm, the behavior is the same in 9.1 and 9.2. Did you use a > different archive_command in 9.1, without the "test"? The behavior is different: 9.1 doesn't try to re-archive the last segment from the old timeline. (I've seen it always happen in training workshops, so that's always mostly idle machines. Possibly 9.1 will re-archive the last segment under load.) I've just reproduced it here with these settings (in Debian's /etc/postgresql-common/createcluster.conf syntax): archive_mode = on archive_command = 'test ! -f /tmp/pg-%v/%%f && cp %%p /tmp/pg-%v/%%f' wal_level = hot_standby max_wal_senders = 3 ... pg_basebackup ... recovery.conf: restore_command = 'cp /tmp/pg-9.3/%f %p' 9.1 slave log (in German, but it should be easy to figure out): LOG: konsistenter Wiederherstellungszustand erreicht bei 0/20000D8 cp: der Aufruf von stat für „/tmp/pg-9.1/000000010000000000000003“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden LOG: konnte Datei »pg_xlog/000000010000000000000003« nicht öffnen (Logdatei 0, Segment 3): Datei oder Verzeichnis nichtgefunden LOG: Redo fertig bei 0/20000D8 LOG: Logdatei »000000010000000000000002« aus Archiv wiederhergestellt cp: der Aufruf von stat für „/tmp/pg-9.1/00000002.history“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden LOG: gewählte neue Timeline-ID: 2 cp: der Aufruf von stat für „/tmp/pg-9.1/00000001.history“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden LOG: Wiederherstellung aus Archiv abgeschlossen LOG: unvollständiges Startpaket LOG: Autovacuum-Launcher startet LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen (eof) ls /tmp/pg-9.1 000000010000000000000001 000000010000000000000002.00000020.backup 000000020000000000000003 000000010000000000000002 000000020000000000000002 00000002.history 9.2 slave log: LOG: konsistenter Wiederherstellungszustand erreicht bei 0/20000E0 cp: der Aufruf von stat für „/tmp/pg-9.2/000000010000000000000003“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden LOG: konnte Datei »pg_xlog/000000010000000000000003« nicht öffnen (Logdatei 0, Segment 3): Datei oder Verzeichnis nichtgefunden LOG: Redo fertig bei 0/20000E0 LOG: Logdatei »000000010000000000000002« aus Archiv wiederhergestellt cp: der Aufruf von stat für „/tmp/pg-9.2/00000002.history“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden LOG: gewählte neue Timeline-ID: 2 cp: der Aufruf von stat für „/tmp/pg-9.2/00000001.history“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden LOG: Wiederherstellung aus Archiv abgeschlossen LOG: unvollständiges Startpaket LOG: Autovacuum-Launcher startet LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen LOG: Archivbefehl ist fehlgeschlagen mit Statuscode 1 DETAIL: Der fehlgeschlagene Archivbefehl war: test ! -f /tmp/pg-9.2/000000010000000000000002 && cp pg_xlog/000000010000000000000002/tmp/pg-9.2/000000010000000000000002 LOG: Archivbefehl ist fehlgeschlagen mit Statuscode 1 ... ls /tmp/pg-9.2 000000010000000000000001 000000010000000000000002 000000010000000000000002.00000020.backup The 9.3 log/ls looks the same. Mit freundlichen Grüßen, Christoph Berg -- Senior Berater, Tel.: +49 (0)21 61 / 46 43-187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE
pgsql-hackers by date: