Re: To Debian Bug Tracking System 2015-05-27 <[email protected]> > I've just upgraded two 9.1 clusters to 9.4.2. The new cluster > continued with the same archive_command as before, but until I did the > *second* new basebackup, barman would just discard all archived WAL > segments (including the .backup labels). My retention setting is 1, so > it might be that it simply started working once the last old backup > was expired. > > I'm not sure if it's related to the fact that 9.4.2 actually *restarts* > the timeline at 1 (see 4c5e060049a3714dd27b7f4732fe922090edea69 in PG > master), or if it's a general problem with pg_upgrade. (The WAL > position is preserved, but the timeline id 2 is now again 1.) > > A related bug is that I still had files in wals/00002..., while all my > base backups (well actually the single backup) only needed files in > wals/00001.... I've now manually removed these and rebuilt the wal db.
Hi,
here is a new instance of the same bug. The old master was running on
timeline 1, but the LSN in the new server is still behind the old one:
$ sudo barman backup candela-main
Starting backup for server candela-main in
/var/lib/barman/candela-main/base/20151129T124851
Backup start at xlog location: 0/60000028 (000000010000000000000060, 00000028)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup size: 121.3 MiB. Actual size on disk: 24.6 KiB (-99.98% deduplication
ratio).
Backup end at xlog location: 0/60000128 (000000010000000000000060, 00000128)
Backup completed
Processing xlog segments for candela-main
Older than first backup. Trashing file 00000001000000000000005F from
server candela-main
Older than first backup. Trashing file 000000010000000000000060 from
server candela-main
Older than first backup. Trashing file
000000010000000000000060.00000028.backup from server candela-main
$ sudo barman check candela-main
Server candela-main:
PostgreSQL: OK
archive_mode: OK
wal_level: OK
archive_command: OK
continuous archiving: OK
directories: OK
retention policy settings: OK
backup maximum age: OK (interval provided: 10 days, latest backup age:
4 minutes)
compression settings: OK
minimum redundancy requirements: OK (have 12 backups, expected at least
1)
ssh: OK (PostgreSQL server)
not in recovery: OK
I kind of understand that handling a jump-back in the LSN is arkward
for barman, but shouldn't at least "check" detect this and yell
loudly? Calling "select pg_current_xlog_location()" should be enough
to detect this.
Christoph
--
[email protected] | http://www.df7cb.de/
signature.asc
Description: Digital signature
