On Sat, Jun 6, 2015 at 11:43 PM, sinasaharkhiz <sinas1991@xxxxxxxxx> wrote:
Yeah I just set the archive_timeout to 5 minutes. But I thought that would
make postgresql to generate more wal files than before. Because the wal
files would be switched before getting completely full. So that would make
more 16MB wal files with less than 16MB data, and that will increase the
size of my backup.
But after I changed archive_timeout and restarted the barman backup, it has
not increased. So I wonder if I'm thinking wrong about it or I have done
something wrong. Do you have any idea about this?
--
View this message in context: http://postgresql.nabble.com/Decreasing-the-data-loss-after-failover-tp5852659p5852817.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Check the archive_command destination folder and ensure a new files is being created there every 5 minutes. If not, check your postgres logs (or barman logs, not sure if they log that as well) to ensure your archive command is running properly. Looking at the docs, I don't see that barman itself supports having the archive_command compress the WAL files. But it's got instructions for copying them to a secondary location that is compressed.
I would highly recommend getting a streaming slave system setup. This would allow you to have a system that is only seconds (or less) behind the master system at all times in case of issues like this. Which sounds like is what your end goal is, and what a backup will not be able to provide you.
