[Question] Hard-Coding --host=127.0.01 in mysql_source.py

[ernstae]

• TwinDB Backup version: 2.18.1
• Operating System: CentOS Linux (7)

Description

I rely on a defaults file when using twindb-backup, but on hosts with DNS lookups disabled, I would prefer to run my xtrabackup processes against the local mysql socket, instead of via TCP. Because of the hard-coded line 177 in mysql_source.py, despite what I have placed in my defaults-file, the xtrabackup process gets executed by twindb-backup with the host hard-coded to the local loopback IP.

backup/twindb_backup/source/mysql_source.py

Line 177 in 2d3a2e9

"--host=127.0.0.1",

My question, is whether we can pull this line out of the source code? Xtrabackup, without any --host flag assumes localhost and in my case, that's the desired state for my environment, and uses the MySQL socket.

This is mostly to solicit thoughts on whether it makes sense to add a configuration file option that allows this value to be changed, instead of hard-coding the value here.

In my case, I've just removed line 177 to get the desired outcome, but am soliciting feedback before offering up a PR.

[akuzminsky]

I don't see why that line can't be removed. Indeed, it's better to give users more control how to connect to MySQL instance. However some users may have created backup account xxx@127.0.0.1 which will be denied if xtrabackup connects to localhost.

Potentially, we could bump the major version and declare this a backward incompatible change, but I think it's better to retry and connect to 127.0.0.1 if connecting to localhost gives "access denied".

Please send a PR if you feel like up for implementing this a in backward compatible way. Otherwise, I'll do it in the next release.

[ernstae]

I'm thinking the easiest way to handle it, would be to have an implicit default of 127.0.0.1, but allow an override in the configuration file. I've been dabbling in building the Azure Blob Storage support, and am feeling a bit more comfortable with the codebase, so will likely fire off a PR in the next few days for this particular small change.

[ernstae]

This looks to be resolved in #467 if the PR is merged.