fix environment vars are empty but they are present bug

[maksimzaitsevV]

Pull request description

Fixes MySQL/MariaDB failover storage environment variables being treated as unknown (#1986).

Failover-related WALG_FAILOVER_STORAGES_* environment variables were present and parsed, but not marked as allowed for MySQL, which caused misleading “unknown variable” warnings.

Tests

Added unit tests covering MySQL failover storage configuration.

[ostinru]

It seems that failover storages doesn't supported for MySQL, so warnings in logs are expected.

wal-g backup-push:
internal.ConfigureSplitUploader()
 -> internal.ConfigureUploader()
    -> internal.ConfigureStorage()

 instead of
    -> internal.ConfigureMultiStorage()

Adding multistorage support make sense only when all mysql commands support multisotrage. And, it requires intensive testing of delete command. =/

[maksimzaitsevV]

Should I rework my solution, or is this issue considered not applicable
since failover storages are intentionally unsupported for MySQL?

[chipitsine]

any update on this ?

btw, I see that on SQL Server as well
for example

C:\i\wal-bin>.\wal-g-sql.exe --config .\wal-g-sql.yaml backup-push
WARNING: 2026/01/29 14:10:06.161980 WALG_FAILOVER_STORAGES_CACHE_LIFETIME is unknown
WARNING: 2026/01/29 14:10:06.161980 WALG_FAILOVER_STORAGES_CHECK_TIMEOUT is unknown
WARNING: 2026/01/29 14:10:06.161980 We found that some variables in your config file detected as 'Unknown'.
  If this is not right, please create issue https://github.com/wal-g/wal-g/issues/new
INFO: 2026/01/29 14:10:06.240819 running proxy at backup.local:443
INFO: 2026/01/29 14:10:06.481064 database [database] size is 5792256, required blob count 1
INFO: 2026/01/29 14:10:06.484365 starting backup database [database] to URL = 'https://backup.local/basebackups_005/base_20260129T131006Z/database/blob_000'
INFO: 2026/01/29 14:10:06.484869 database [AcumaticaDB] size is 2604205568, required blob count 1
INFO: 2026/01/29 14:10:06.486944 starting backup database [AcumaticaDB] to URL = 'https://backup.local/basebackups_005/base_20260129T131006Z/AcumaticaDB/blob_000'
INFO: 2026/01/29 14:10:06.789727 database [database] backup successfully finished
INFO: 2026/01/29 14:10:10.621072 database [AcumaticaDB] backup successfully finished
INFO: 2026/01/29 14:10:10.621072 uploading sentinel: {"Server":"LAPTOP-K2DOOLG0","Databases":["AcumaticaDB","database"],"StartLocalTime":"2026-01-29T14:10:06.469071+01:00","StopLocalTime":"2026-01-29T14:10:10.621073+01:00"}
INFO: 2026/01/29 14:10:10.623150 backup finished
INFO: 2026/01/29 14:10:10.623150 Removing sigmask. Shutting down
INFO: 2026/01/29 14:10:10.623673 stopping proxy

C:\i\wal-bin>.\wal-g-sql.exe --config .\wal-g-sql.yaml delete retain FULL 3 --confirm
WARNING: 2026/01/29 14:10:10.712059 WALG_FAILOVER_STORAGES_CHECK_TIMEOUT is unknown
WARNING: 2026/01/29 14:10:10.712621 WALG_FAILOVER_STORAGES_CACHE_LIFETIME is unknown
WARNING: 2026/01/29 14:10:10.712621 We found that some variables in your config file detected as 'Unknown'.
  If this is not right, please create issue https://github.com/wal-g/wal-g/issues/new
INFO: 2026/01/29 14:10:10.714256 No backup found for deletion
PS C:\i\wal-bin>

it's trying to tell me something important

WARNING: 2026/01/29 14:10:10.712059 WALG_FAILOVER_STORAGES_CHECK_TIMEOUT is unknown
WARNING: 2026/01/29 14:10:10.712621 WALG_FAILOVER_STORAGES_CACHE_LIFETIME is unknown

but I'm not getting what am I supposed to do

[ser]

The bug is still there.

[ostinru]

since failover storages are intentionally unsupported for MySQL?

The problem with failover storage is that it makes backup / restore way more complicated: different views on storage should be considered and tested.
In my experience, multistorage may be used as a way to gradually migrate data from one S3 to another without copying all data at once. However I think that multistorage is not tested enough to be used everyday.