Upgrade 4.1.9 to 4.1.12 breaks due to non-existant flag --disable-ssl for mysqladmin

[ToshY]

Summary

After upgrading from 4.1.9 to 4.1.12 I've noticed I no longer was getting backups.

mysql-backup-1  | 2025-01-19T09:24:54.435241466Z 2025-01-19.10:24:54 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369025 seconds so far)
mysql-backup-1  | 2025-01-19T09:24:59.458481950Z 2025-01-19.10:24:59 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369030 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:04.476567389Z 2025-01-19.10:25:04 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369035 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:09.498171665Z 2025-01-19.10:25:09 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369040 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:14.521217389Z 2025-01-19.10:25:14 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369045 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:19.538366501Z 2025-01-19.10:25:19 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369050 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:24.556779037Z 2025-01-19.10:25:24 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369055 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:29.575533288Z 2025-01-19.10:25:29 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369060 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:34.593674390Z 2025-01-19.10:25:34 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369065 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:39.611285786Z 2025-01-19.10:25:39 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369070 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:44.628691341Z 2025-01-19.10:25:44 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369075 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:49.647127798Z 2025-01-19.10:25:49 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369080 seconds so far)
mysql-backup-1  | 2025-01-19T09:25:54.662851684Z 2025-01-19.10:25:54 [WARN] ** [01-mysql__redacted] MySQL/MariaDB Server 'mysql' is not accessible, retrying.. (369085 seconds so far)

The logs shown are obfuscating the underlying problem, which is that --disable-ssl is not a valid argument for mysqladmin.

/ # /opt/mysql/bin/mysqladmin -u<redacted> -P3306 -hmysql status
Uptime: 395081  Threads: 3  Questions: 1082677  Slow queries: 23130  Opens: 1807  Flush tables: 3  Open tables: 1741  Queries per second avg: 2.740
/ # /opt/mysql/bin/mysqladmin -u<redacted> -P3306 -hmysql --disable-ssl status
mysqladmin: [ERROR] unknown option '--disable-ssl'.

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

• Image version / tag: 4.1.12
• Host OS: Ubuntu 22.04

Any logs | docker-compose.yml

Possible fixes

Cause:

docker-db-backup/install/assets/functions/10-db-backup

Line 450 in 244e411

mysql_tls_args="--disable-ssl"

Fix:
Remove ${mysql_tls_args} from the mysqladmin status check

docker-db-backup/install/assets/functions/10-db-backup

Line 975 in 244e411

while ! (run_as_user ${_mysql_prefix}${_mysql_bin_prefix}admin -u"${backup_job_db_user}" -P"${backup_job_db_port}" -h"${backup_job_db_host}" ${mysql_tls_args} status > /dev/null 2>&1) ; do

Related

Similar to #208 / #209

[tiredofit]

Hi, thanks for the investigation..

A quick look at the MySQL settings show that the arguments have deviated from MariaDB and MySQL, to which MySQL uses -ssl-mode=disabled.

I think as opposed to pulling it out entirely we'll have to rework it to support those different command line options as that argument would also break any backups when they executed as well..

As a side note this is being addressed in a different fashion in an upcoming version of the base images, although they are still TBA when they will be in use. I still think the image work is useful.

[ToshY]

Hey @tiredofit

A quick look at the MySQL settings show that the arguments have deviated from MariaDB and MySQL, to which MySQL uses -ssl-mode=disabled.

I think as opposed to pulling it out entirely we'll have to rework it to support those different command line options as that argument would also break any backups when they executed as well..

Ah okay, didn't think to look there 👍 So instead of entirely removing ${mysql_tls_args} it would've been better to change it to --ssl-mode=DISABLED then.

As a side note this is being addressed in a different fashion in an upcoming version of the base images, although they are still TBA when they will be in use. I still think the image work is useful.

Okay, could you tell me in more concrete terms what would you suggest to do with the PR for now? I'm fine with updating the PR with your suggestion, or close it in favor for the (future) base images.

For now I'm still able to use 4.1.9 without any problems in my stacks.

[tiredofit]

Will be back in ~48hr with some thoughts when I can sit down and look at this in detail for a way forward...

[tiredofit]

4.1.3 splits some of the TLS differences with MysQL and MariaDB - Let me know if this indeed works for you?

[ToshY]

4.1.3 splits some of the TLS differences with MysQL and MariaDB - Let me know if this indeed works for you?

I can confirm that 4.1.13 creates the backup, however the bump of AWS CLI to 1.37.2 breaks my own post execution script which performs a aws s3 sync (I do not directly use the db-backup provided S3 upload).

An error occurred (InvalidArgument) when calling the CreateMultipartUpload operation: Unsupported header 'x-amz-checksum-algorithm' received for this API call.

This fails in particular when using Backblaze for object storage.

As of 1.37.0 they started validate response checksums for all S3 operations that support it, and Backblaze being incompatible with some, now breaks with certain upload actions, like s3 sync, but also like s3 cp (that you seem to use in your script). They denote setting environment variables like AWS_REQUEST_CHECKSUM_CALCULATION or AWS_RESPONSE_CHECKSUM_VALIDATION, but these are currently not respected according to boto/s3transfer#328.

aws/aws-cli#9214

That's just a heads-up, as it's very likely that other users that use Backblaze and use db-backup for S3 upload, it might fail as well.

---

Until that seems fixed in the AWS CLI, I will still be using 4.1.9 for now.

[tiredofit]

Oh dear. So close. Let's just downgrade that to 1.36.40 for AWS CLI for time being while they work out their issues. I see there is some discussions in their issue tracker and the change happened within the past week. Not sure we need to stay so bleeding edge on this component.

4.1.14 downgrades and has this change

[ToshY]

Oh dear. So close. Let's just downgrade that to 1.36.40 for AWS CLI for time being while they work out their issues. I see there is some discussions in their issue tracker and the change happened within the past week. Not sure we need to stay so bleeding edge on this component.

4.1.14 downgrades and has this change

Great 👍 I'll check it when it's done building.

[ToshY]

@tiredofit 4.1.14 works, both database backup and s3 upload. Thank you for the quick fix 🦸