Closed gnullme closed 2 years ago
Hi,
It's indeed a known issue but I've never really figured out what would be best to fix it.
It is easy to spread multiple db ids across multiple repositories and it then becomes very hard to determine which would be the oldest and the latest wal archive to check. Here's a pretty complicated json output which enlighten the issue:
{
"archive":[
{
"database":{
"id":2,
"repo-key":1
},
"id":"14-2",
"max":"000000020000000000000024",
"min":"000000010000000000000020"
},
{
"database":{
"id":3,
"repo-key":1
},
"id":"14-3",
"max":"000000010000000000000003",
"min":"000000010000000000000001"
},
{
"database":{
"id":1,
"repo-key":2
},
"id":"14-1",
"max":"000000020000000000000024",
"min":"000000010000000000000010"
},
{
"database":{
"id":2,
"repo-key":2
},
"id":"14-2",
"max":"000000010000000000000003",
"min":"000000010000000000000001"
}
],
"db":[
{
"id":1,
"repo-key":1,
"system-id":7041541491266333513,
"version":"14"
},
{
"id":2,
"repo-key":1,
"system-id":7041547033868927426,
"version":"14"
},
{
"id":3,
"repo-key":1,
"system-id":7041553778656897495,
"version":"14"
},
{
"id":1,
"repo-key":2,
"system-id":7041547033868927426,
"version":"14"
},
{
"id":2,
"repo-key":2,
"system-id":7041553778656897495,
"version":"14"
}
]
}
I've pushed this little change to only look at the current db system/version and ignore the prior one (which is the easiest fix). Grouping each system-id/version and loop threw all of them to then check across each repo would add some code (and perf) overhead, so I wasn't sure it would worth it.
What do you think? Is checking only the "current" db system/version enough for you ? If yes, could you try this patch ?
Thanks in advance for your feedback, Kind Regards
Hi,
thank you for your super fast response :)
Checking only the current db version is totally fine for me, so your change is absolutely sufficient. I also do not think that more complex checks for each version are generally necessary, as after an upgrade i normally only want to know if my current database archiving works.
I tried it and it works as intended (no more critical as before the stanza upgrade):
check_pgbackrest --service archives --stanza XXXX --debug --extended-check
DEBUG: pgBackRest info command was : 'pgbackrest info --stanza=XXXX--output=json --log-level-console=error'
DEBUG: !> pgBackRest info took 0s
DEBUG: ignoring archives for db id 1 in repo 1
DEBUG: min_wal changed to 000000010000036700000092
DEBUG: Get all the WAL archives and history files...
DEBUG: repo1, archives_dir: archive/XXXX/13-2
DEBUG: pgBackRest version command was : 'pgbackrest version'
DEBUG: pgBackRest ls command was : 'pgbackrest repo-ls --stanza=XXXX archive/XXXX/13-2 --output=json --log-level-console=error --repo=1 --recurse'
DEBUG: !> Get all the WAL archives and history files took 0s
DEBUG: Get all the needed WAL archives...
DEBUG: !> Get all the needed WAL archives took 0s
DEBUG: !> Go through needed WAL list and check took 0s
DEBUG: Get all the needed WAL archives for 20211214-011759F...
DEBUG: Get all the needed WAL archives for 20211214-022544F...
DEBUG: !> Go through each backup, get the needed WAL and check took 0s
WAL_ARCHIVES WARNING - min WAL is not the oldest archive | latest_archive_age=150s num_unique_archives=4005
Thanks again for your fast response and fix, really appreciate it
Kind regards Hendrik
Hi there,
after a stanza upgrade and new full backup the archive check returns the following critical:
WAL_ARCHIVES CRITICAL - min WAL not found
The check seems to look up the oldest wal file from both the old and new postgres versions. But it only searches the archive folder of the new postgres version, resulting in the critical.
I am using version 2.1 but it is also happening with the latest version.
check_pgbackrest --service archives --stanza XXXX --debug --extended-check
pgbackrest --stanza=XXXX info
Kind regards, Hendrik