Config supports MySQL replication credentials

[shlomi-noach]

Fixes https://github.com/github/orchestrator/issues/323

This PR introduces three new configuration variables:

• MySQLReplicationUser
• MySQLReplicationPassword
• MySQLReplicationCredentialsConfigFile (alternative to the above two)

These variables will be used by orchestrator to CHANGE MASTER TO ... MASTER_USER=... MASTER_PASSWORD=..., on a server that didn't have credentials (a Master), in these operations:

• Setting up co-masters
• Graceful master takeover

You will not need these variables if you use master_info_repository = TABLE in your MySQL servers.

[cezmunsta]

@shlomi-noach this would not allow per-cluster replication credentials, which the slave_master_info table would do, although it does allow you at least to work with orchestrator when the credentials are not available in the mysql schema :1st_place_medal:

Are you planning to add support for a helper query too, which would allow per-cluster credentials?

[shlomi-noach]

Whoops.

[shlomi-noach]

Not going to use this PR. Replaced by #603

[m00dawg]

I noticed this has been open for a while - is there still a plan to integrate this feature? I'm trying to minimize changes in a MySQL env where the master.info is still being written to a file and having the ability to tell Orchestrator what the UN/PW are would be a nice to have. Not a need to have (given #603) but among those options, I think putting the creds in the Orchestrator conf would be the easiest solve.

[cezmunsta]

I noticed this has been open for a while - is there still a plan to integrate this feature? I'm trying to minimize changes in a MySQL env where the master.info is still being written to a file and having the ability to tell Orchestrator what the UN/PW are would be a nice to have. Not a need to have (given #603) but among those options, I think putting the creds in the Orchestrator conf would be the easiest solve.

See https://github.com/openark/orchestrator/pull/603

Does that not help?

You could always write a query that has static data to produce the required output if you so wish ;)

[m00dawg]

Hmm that's clever, I didn't think about a static query but yep that would work! The idea was to avoid, at least for now, having to switch to storing the master info in the TABLE. That's probably the correct long term solution but has security implications (as would the query since it would get run on the DB itself). This feature request would be a little easier to secure and audit with fewer DB changes which made it compelling. The second option is indeed either #603 or switching to TABLE for the binlog info and making secure we have a good security/audit process for access to the mysql DB itself.

[cezmunsta]

The idea was to avoid, at least for now, having to switch to storing the master info in the TABLE. That's probably the correct long term solution but has security implications (as would the query since it would get run on the DB itself).

You could always store the data in a table with a varbinary field with aes_encrypt, possibly reading with a view that would allow you to run with the definer's privilege to protect direct access to the data

[Neabary]

hello. i setting up orchestrator at mariadb...they haven't slave_master_info table. i write into conf file:

"MySQLReplicationUser": "replicant",
"MySQLReplicationPassword": "superpa$$",                

but orchestrator not load it:

./orchestrator -c dump-config | jq | grep MySQL
  "MySQLTopologyUser": "orchestrator",
  "MySQLTopologyPassword": "---------------",
  "MySQLTopologyCredentialsConfigFile": "",
  "MySQLTopologySSLPrivateKeyFile": "",
  "MySQLTopologySSLCertFile": "",
  "MySQLTopologySSLCAFile": "",
  "MySQLTopologySSLSkipVerify": true,
  "MySQLTopologyUseMutualTLS": false,
  "MySQLTopologyUseMixedTLS": true,
  "MySQLOrchestratorHost": "------------",
  "MySQLOrchestratorMaxPoolConnections": 128,
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orchestrator",
  "MySQLOrchestratorPassword": "----------------",
  "MySQLOrchestratorCredentialsConfigFile": "",
  "MySQLOrchestratorSSLPrivateKeyFile": "",
  "MySQLOrchestratorSSLCertFile": "",
  "MySQLOrchestratorSSLCAFile": "",
  "MySQLOrchestratorSSLSkipVerify": true,
  "MySQLOrchestratorUseMutualTLS": false,
  "MySQLOrchestratorReadTimeoutSeconds": 30,
  "MySQLOrchestratorRejectReadOnly": false,
  "MySQLConnectTimeoutSeconds": 1,
  "MySQLDiscoveryReadTimeoutSeconds": 10,
  "MySQLTopologyReadTimeoutSeconds": 600,
  "MySQLConnectionLifetimeSeconds": 0,
  "MySQLHostnameResolveMethod": "@@hostname",
  "ApplyMySQLPromotionAfterMasterFailover": true,

./orchestrator --version
3.2.6
c846d43668239cad384dc31b9255a3ade3a35001

it not impelentet for now ? can any one review this for merge code?