problem in ubuntu 14.04

[bdshibly]

when i am going to execute

./check-barman.rb -a last_wal_received -s postgresdb -w 300 -c 600

i am getting error

/var/lib/gems/2.1.0/gems/mixlib-shellout-1.3.0/lib/mixlib/shellout.rb:253:in invalid!': Expected process to exit with [0], but received '1' (Mixlib::ShellOut::ShellCommandFailed) ---- Begin output of /usr/bin/barman list-files --target wal postgresdb 20150610T150001 ---- STDOUT: STDERR: EXCEPTION: 'NoneType' object has no attribute 'rfind' See log file for more details. ---- End output of /usr/bin/barman list-files --target wal postgresdb 20150610T150001 ---- Ran /usr/bin/barman list-files --target wal postgresdb 20150610T150001 returned 1 from /var/lib/gems/2.1.0/gems/mixlib-shellout-1.3.0/lib/mixlib/shellout.rb:239:inerror!'
from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/cli_command.rb:352:in run_barman_command' from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/cli_command.rb:118:inwal_files'
from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/cli_command.rb:71:in block in backups' from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/cli_command.rb:68:ineach'
from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/cli_command.rb:68:in backups' from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/cli_command.rb:54:inbackup'
from /var/lib/gems/2.1.0/gems/rbarman-0.0.14/lib/rbarman/backup.rb:298:in by_id' from ./check-barman.rb:82:incheck_last_wal_received'
from ./check-barman.rb:235:in `

'

I am using pgbarman version 1.4.1 in ubuntu 14.04.

[hamann]

Seems like there are some changes in barman 1.4.x.. I'll have to take a look at that

[bdshibly]

Have you upgraded the plugin ?

[hamann]

I'm on it, but I can't reproduce it

STDOUT: STDERR: EXCEPTION: 'NoneType' object has no attribute 'rfind' See log file for more details. ---- End output of /usr/bin/barman list-files --target wal postgresdb 20150610T150001

That looks like barman itself produces that error

Could you check if the following command is successful?

$ /usr/bin/barman list-files --target wal postgresdb 20150610T150001

[bdshibly]

The command executed successfully but no output.

/usr/bin/barman list-files --target wal postgresdb 20150610T150001
echo $?
0

[hamann]

Interesting, that should list at least a few wals from the base backup

Please paste the output of

$ barman show-backup postgresdb 20150610T150001

[bdshibly]

Backup 20150603T213001:
Server Name : postgresdb
Status : DONE
PostgreSQL Version : 90307
PGDATA directory : /var/lib/postgresql/9.3/main

Base backup information:
Disk usage : 300.7 MiB (300.7 MiB with WALs)
Incremental size : 300.7 MiB (-0.00%)
Timeline : 5
Begin WAL : 00000005000000000000007B
End WAL : 00000005000000000000007B
WAL number : 0
Begin time : 2015-06-04 01:30:01.122175+00:00
End time : 2015-06-04 01:30:23.963955+00:00
Begin Offset : 40
End Offset : 240
Begin XLOG : 0/7B000028
End XLOG : 0/7B0000F0

WAL information:
No of files : 0
Disk usage : 0 B
Last available : None

Catalog information:
Retention Policy : VALID
Previous Backup : 20150603T210001
Next Backup : 20150603T220002

[hamann]

ok, seems that there are no wal files associated to that backup
but at least barman doesn't crash when you call that list-files command.
could you try

./check-barman.rb -a last_wal_received -s postgresdb -w 300 -c 600

again, please?

[bdshibly]

/opt/check-barman/check-barman.rb -a last_wal_received -s postgresdb -w 300 -c 600

/opt/check-barman/check-barman.rb:93:in check_last_wal_received': undefined methodcreated' for nil:NilClass (NoMethodError)
from /opt/check-barman/check-barman.rb:235:in `

'

[hamann]

k, that's a different error, probably due to a newer backup.

$ barman show-backup postgresdb latest

[bdshibly]

barman show-backup postgresdb latest
Backup 20150616T110845:
Server Name : postgresdb
Status : DONE
PostgreSQL Version : 90307
PGDATA directory : /var/lib/postgresql/9.3/main

Base backup information:
Disk usage : 331.9 MiB (331.9 MiB with WALs)
Incremental size : 331.9 MiB (-0.00%)
Timeline : 6
Begin WAL : 00000006000000000000008E
End WAL : 00000006000000000000008E
WAL number : 0
Begin time : 2015-06-13 04:31:55.086158+00:00
End time : 2015-06-13 04:32:14.515017+00:00
Begin Offset : 40
End Offset : 240
Begin XLOG : 0/8E000028
End XLOG : 0/8E0000F0

WAL information:
No of files : 0
Disk usage : 0 B
Last available : None

Catalog information:
Retention Policy : VALID
Previous Backup : 20150616T110053
Next Backup : - (this is the latest base backup)

[hamann]

Thanks, I'll have a look
Btw, it seems that you don't archive wals

WAL information:
No of files : 0
Disk usage : 0 B
Last available : None

Is this intended? If yes (hopefully not!), that check isn't necessary

[bdshibly]

I have configured a cron job to take a backup in every 4 hours.

[hamann]

That means you'd lose 4 hours of data in case of a crash! I highly recommend to have a look at section "Continous Wal archiving" in http://docs.pgbarman.org/#getting_started, and take a base backup once a day or once a week if it's working, but it's your decision

[bdshibly]

We are going to configure postgresql cluster environment with pgpool and repmgr. here is the configuration in postgres.conf

listen_addresses='*'
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .' # we can also use exit 0, anything that
# just does nothing
max_wal_senders = 10
wal_keep_segments = 5000 # 80 GB required on pg_xlog
hot_standby = on
shared_preload_libraries = 'repmgr_funcs'

My primary intention with pgbarman is to take full backup in every 4 hours and archive wal files continuously. I have question on archive_command. which one is correct archive_command, is it "cd ." (according to repmgr documentation) or "rsync -a %p barman@pmapgbar01:/var/lib/barman/postgresdb/incoming/%f" (according to barman documentation). By the way, repmgr auto failover is working properly. with "cd ."

[hamann]

I don't think that repmgr is interested in wal archives, so adding a command for wal shipping to barman should be ok. But there could be issues when a failover is happening, because than the new master should ship the wals and you should take care about that (btw, that's another reason why we don't do automatic postgres failover ;) Instead of adding that rsync command directly, you could call a script which calls rsync etc, because than you're able to add some logic to it and you don't have to reload postgres if you want to change something