Wal-g 3.x made brotli compression an optional build flag, see https://github.com/wal-g/wal-g/pull/1379. Upgrading to v3.x broke assumptions in some clusters relying on brotli compression and explicitly setting backup creation to use wal-g. Restoration would have equally failed, but in those cases no backups could be created in the first place.
Proposed solution
The proposed fix is to use pre-built wal-g binaries from the source repository itself instead of compiling in Spilo, which at this moment seem to include brotli compression (https://github.com/zalando/spilo/pull/1006)
To prevent any regressions, we should run automated tests to verify that all expected compression algorithms are still working for each Spilo build as expressed in this comment https://github.com/zalando/spilo/pull/1006#issuecomment-2244915865, because lz4 or lzma might be dropped (or made optional) at one time in future as well.
This would help detecting issues with creating or restoring from backups early.
for algo in lz4 lzma brotli; do
# ... verify backups can be created and restored from $algo
done
Why?
Wal-g 3.x made
brotlicompression an optional build flag, see https://github.com/wal-g/wal-g/pull/1379. Upgrading to v3.x broke assumptions in some clusters relying on brotli compression and explicitly setting backup creation to use wal-g. Restoration would have equally failed, but in those cases no backups could be created in the first place.Proposed solution
brotlicompression (https://github.com/zalando/spilo/pull/1006)To prevent any regressions, we should run automated tests to verify that all expected compression algorithms are still working for each Spilo build as expressed in this comment https://github.com/zalando/spilo/pull/1006#issuecomment-2244915865, because
lz4orlzmamight be dropped (or made optional) at one time in future as well.This would help detecting issues with creating or restoring from backups early.