Provide commands to check WAL archive destination is usable

[mikewallace1979]

Adds commands to barman and barman cloud which check that a barman server
or cloud location is safe to use as an archive destination for a new
PostgreSQL server.

A location is considered safe if either:

1. There are no WAL files at all in the archive.
2. All existing WAL files belong to an older timeline than that
   specified by the --timeline argument.

A file is considered a WAL file if it passes the is_any_xlog_file check
in barman/xlog.py so this applies to WAL files, history files, partial
WAL files and backup labels.

The commands added are:

• barman check-wal-archive
• barman-cloud-check-wal-archive

The motivation for this patch is to provide a way that external
orchestration tools can validate the WAL archive destination is safe for
a newly provisioned PostgreSQL cluster, given such a cluster may use the
exact same name as an old cluster.

In such scenarios, any WAL files on the same or higher timeline as the
WALs being written by the new cluster will cause any attempt to restore
from a backup to fail.

Reasons why external orchestration tooling may re-use the same cluster
name and archive destination include (but are not limited to):

• A new cluster is created via initdb with the same name as the old one.
  The sysid will be different but this does not affect the archive
  destination so any archived WALs relating to the older cluster will be
  present in the same location.
• A cluster is restored from a base backup and uses the same name as the
  old cluster. The cluster has the same sysid and starts with a segment
  ID > 1 and timeline > 1. The same archive destination used by the old
  cluster will be used for the restored cluster.
• A new cluster is started which happens to re-use the same name and
  archive destination.

All of these cases lead to the situation where WAL archiving and backup
is functioning normally but any attempts to restore from those backups
will fail. This is dangerous for anyone relying on the databases managed
by external orchestration/automation.

The commands provided by this patch do not solve the problem alone
because neither Barman nor PostgreSQL have the necessary context. The
commands can, however, be added to external automation in order to
catch archive safety issues at the provisioning stage.

Closes #432

[jthreefoot-edb]

Why does the argparse import need to be wrapped in a try-except?

[mikewallace1979]

This is a good question and I think the answer is "there is no longer any good reason".

The first commit to introduce this was 83e9979 where the barman-wal-restore.py script is added. This would have needed to support python 2.6 (and presumably older versions of 3.x) which didn't ship with argparse so there was a genuine possibility it could run without argparse being available, therefore providing a friendly error message was useful.

Now we only support python versions which include argparse I don't think there is a need to do this at all. I'll remove it from this PR and while we're at it I'll update the other scripts too.

[ringerc]

After a bit more thinking I think it's probably sufficient to be able to say "no archives or timeline history files on timeline X or any greater timeline".

Archives on the same timeline as end-of-recovery don't matter when we're doing a TLI increment. Pg does a TLI increment if restoring from backup (backup label exists) or if started up in archive recovery or streaming replication. It only skips a TLI increment if it thinks the startup is normal crash recovery. The only way I can see that happening here is if someone takes a disk or filesystem snapshot and starts a new Pg from it without any recovery configuration or starting up as a standby.

In either case what actually matters is the timeline and LSN at which Pg will write the first WAL seg after end-of-recovery, not the current timeline and LSN of the Pg instance.

(Will update soon, thinking about it some more)

[mikewallace1979]

@ringerc So we could maybe simplify this to just passing in a --current-timeline and not require a WAL segment at all?

[mikewallace1979]

(just rebased and updated now that the argh->argparse work has landed - everything else remains the same in the PR for now but I'll squash what needs to be squashed before merging)

[mikewallace1979]

@ringerc I've just pushed a commit which removes --current-wal-segment and changes the behaviour so if --timeline is provided then it passes only if all WAL files in the archive relate to an earlier timeline.

@jthreefoot-edb I know you've already reviewed this but could you please take another look now the options have changed?

[jthreefoot-edb]

@jthreefoot-edb I know you've already reviewed this but could you please take another look now the options have changed?

Looks good to me.

[edb-sonar-app]

SonarQube Quality Gate:

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

95.1% Coverage
1.8% Duplication