Barman WAL Archive failed for server - please make sure WAL shipping is setup.

7,144 views
Skip to first unread message

Armandt van Zyl

unread,
Jan 8, 2017, 11:39:57 AM1/8/17
to Barman, Backup and Recovery Manager for PostgreSQL
Hi all!

Would someone be able to provide me with assistance regarding this matter? 

Some context: 
I have recently setup a new backup server running CentOS 7 with the intent of backing up one PostgreSQL database (version 9.2). I would later be backing up roughly about three more databases running possibly different versions of Postgres. 

However, I am struggling to get the log shipping setup correctly. 

I have, to my knowledge, correctly configured the postgresql.conf, pg_hba.conf and the barman.conf files.

When running barman check <server> I am receiving the following error: 
WAL archive: FAILED (please make sure WAL shipping is setup) 

The rest of the output reads as follows: 
PostgreSQL: OK
superuser: OK
wal_level: OK
directories: OK
retention policy settings: OK
backup maximum age: FAILED (interval provided: 1 day, latest backup age: No available backups)
compression settings: OK
failed backups: OK (there are 0 failed backups)
minimum redundancy requirements: OK (have 0 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
archive_mode: OK
archive_command: OK
archiver errors: OK

I have tried running "barman switch-xlog --force <server>" which proves that there is a problem in my configuration. 

What could be the cause of this? Also, is there anything else I can post to help with the answer? 

Thank you in advance!

Giulio Calacoci

unread,
Jan 8, 2017, 9:45:37 PM1/8/17
to pgbarman
Hi Armandt,

Is Barman's cron running?
Have you tried to issue the barman cron command manually?

Looks like that you PostgreSQL server archive_command is not copying
WAL files where barman expects them to be.
You can discover where barman expects the WAL files to be using the
barman show-server command.

Otherwise, could you please provide the output of the barman diagnose command?

Regards
Giulio
> --
> --
> You received this message because you are subscribed to the "Barman for
> PostgreSQL" group.
> To post to this group, send email to pgba...@googlegroups.com
> To unsubscribe from this group, send email to
> pgbarman+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/pgbarman?hl=en?hl=en-GB
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Barman, Backup and Recovery Manager for PostgreSQL" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pgbarman+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Giulio Calacoci - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
giulio....@2ndQuadrant.it | www.2ndQuadrant.it

Armandt van Zyl

unread,
Jan 9, 2017, 2:33:10 PM1/9/17
to Barman, Backup and Recovery Manager for PostgreSQL
Hi Giulio, 

Sorry, I've only been able to get back to this now. 

Firstly, thanks for the response!

I will check that which you have mentioned and will then post a reply as soon as I can. 

Kind regards, 
Armandt

Venky

unread,
Oct 6, 2017, 4:02:02 AM10/6/17
to Barman, Backup and Recovery Manager for PostgreSQL







Hi Giulio Calacoci,

I too have the same problem. Getting WAL archive : FAILED (please make sure WAL shipping is setup) error.

I verified that wal files are coping into wal directory by rsync command. but still i am getting above error. Manually executed barman cron command, but no luck. posting diagnose output. Please check and could you please suggest something. 




[barman@localhost wals]$ barman diagnose

{

    "global": {

        "config": {

            "barman_home": "/var/lib/barman",

            "barman_user": "barman",

            "compression": "gzip",

            "errors_list": [],

            "log_file": "/var/log/barman/barman.log",

            "minimum_redundancy": "4",

            "retention_policy": "RECOVERY WINDOW OF 4 WEEKS",

            "reuse_backup": "link"

        },

        "system_info": {

            "barman_ver": "2.3",

            "kernel_ver": "Linux localhost.localdomain 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux",

            "python_ver": "",

            "release": "RedHat Linux Red Hat Enterprise Linux Server release 7.3 (Maipo)",

            "rsync_ver": "rsync  version 3.0.9  protocol version 30",

            "ssh_ver": ""

        }

    },

    "servers": {

        "data": {

            "backups": {},

            "config": {

                "active": true,

                "archiver": true,

                "archiver_batch_size": 0,

                "backup_directory": "/var/lib/barman/data",

                "backup_method": "rsync",

                "backup_options": "exclusive_backup",

                "bandwidth_limit": null,

                "barman_home": "/var/lib/barman",

                "barman_lock_directory": "/var/lib/barman",

                "basebackup_retry_sleep": 30,

                "basebackup_retry_times": 0,

                "basebackups_directory": "/var/lib/barman/data/base",

                "check_timeout": 30,

                "compression": "gzip",

                "conninfo": "host=localhost user=postgres",

                "custom_compression_filter": null,

                "custom_decompression_filter": null,

                "description": "Essilor Production Databases",

                "disabled": false,

                "errors_directory": "/var/lib/barman/data/errors",

                "immediate_checkpoint": false,

                "incoming_wals_directory": "/var/lib/barman/data/incoming",

                "last_backup_maximum_age": null,

                "max_incoming_wals_queue": null,

                "minimum_redundancy": 4,

                "msg_list": [],

                "name": "data",

                "network_compression": false,

                "parallel_jobs": 1,

                "path_prefix": null,

                "post_archive_retry_script": null,

                "post_archive_script": null,

                "post_backup_retry_script": null,

                "post_backup_script": null,

                "pre_archive_retry_script": null,

                "pre_archive_script": null,

                "pre_backup_retry_script": null,

                "pre_backup_script": null,

                "recovery_options": "",

                "retention_policy": "window 4 w",

                "retention_policy_mode": "auto",

                "reuse_backup": "link",

                "slot_name": null,

                "ssh_command": "ssh postgres@localhost -q",

                "streaming_archiver": false,

                "streaming_archiver_batch_size": 0,

                "streaming_archiver_name": "barman_receive_wal",

                "streaming_backup_name": "barman_streaming_backup",

                "streaming_conninfo": "host=localhost user=postgres",

               "streaming_wals_directory": "/var/lib/barman/data/streaming",

                "tablespace_bandwidth_limit": null,

                "wal_retention_policy": "simple-wal 4 w",

                "wals_directory": "/var/lib/barman/data/wals"

            },

            "status": {

                "archive_command": "rsync -a %p barman@localhost:/var/lib/barman/data/wals/%f",

                "archive_mode": "on",

                "archived_count": 15,

                "config_file": "/data1/pgsql_data/postgresql.conf",

                "current_archived_wals_per_second": 2.16315154996823e-05,

                "current_size": 37708788.0,

                "current_xlog": "000000010000000000000011",

                "data_directory": "/data1/pgsql_data",

                "failed_count": 0,

                "hba_file": "/data1/pgsql_data/pg_hba.conf",

                "ident_file": "/data1/pgsql_data/pg_ident.conf",

                "included_files": [

                    "/data1/pgsql_data/postgresql.auto.conf"

                ],

                "is_archiving": true,

                "is_in_recovery": false,

                "is_superuser": true,

                "last_archived_time": "Fri Oct  6 13:13:35 2017",

                "last_archived_wal": "000000010000000000000011",

                "last_failed_time": null,

                "last_failed_wal": null,

                "pgespresso_installed": false,

                "replication_slot": null,

                "replication_slot_support": true,

                "server_txt_version": "9.5.8",

                "stats_reset": "Thu Sep 28 12:38:10 2017",

                "synchronous_standby_names": [

                    ""

                ],

                "wal_level": "archive"

            },

            "system_info": {

                "kernel_ver": "Linux localhost.localdomain 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux",

                "python_ver": "",

                "release": "RedHat Linux Red Hat Enterprise Linux Server release 7.3 (Maipo)",

                "rsync_ver": "rsync  version 3.0.9  protocol version 30",

                "ssh_ver": ""

            },

            "wals": {

                "last_archived_wal_per_timeline": null

            }

        }

    }

}





Thanks for your help in advance. 



 giulio.calacoci@2ndQuadrant.it | www.2ndQuadrant.it

Edson Richter

unread,
Oct 13, 2017, 2:33:20 PM10/13/17
to Barman, Backup and Recovery Manager for PostgreSQL
I've this error with one database only. All the others that are setup exactly same way doesn't show this error.
Investigating further, I've discovered that this database is almost read only. So I rarely have a WAL archive copied into "incoming" folder.
And then, Barman "think" wal archive is not correctly setup.
If I force "select * from pg_switch_xlog()" in master server, after few seconds, the error is gone, and I'm able to backup normally again.

Therefore, what I did was to add

archive_timeout=3600

in postgresql.conf, so I'll have at least one WAL generated every hour. Not sure if it would apply to your case.

Regards,

Edson Richter
Reply all
Reply to author
Forward
0 new messages