Related issue: https://github.com/github/gh-ost/issues/521
- Add --ssl-cert and --ssl-key options to specify SSL public/private
key files
- Allow combining --ssl-allow-insecure with other --ssl* flags.
`mysql.RegisterTLSConfig` allows combining the corresponding
parameters in the `tls.Config` it receives, so gh-ost should
allow this. I found being able to pass --ssl-allow-insecure along
with --ssl-ca, --ssl-cert, and --ssl-key useful in testing.
- Use the same TLS config everywhere. Since the CLI only supports
a single set of --ssl* configuration parameters, this should be
fine -- `mysql.RegisterTLSConfig` documentation indicates the
TLS config given will not be modified, so it can safely be used
in many goroutines provided we also do not modify it. The previous
implementation did not work when the TLS config was duplicated,
which happens when gh-ost walks up the replication chain trying
to find the master. This is because, when the config is duplicated,
we must call `RegisterTLSConfig` again with the new config. This
config is exactly the same, so it's easiest to side-step the issue
by registering the TLS config once and using it everywhere.
- Adding a command line option for users to enforce tls/ssl connections
for the applier, inspector, and binlog reader.
- The user can optionally request server certificate verification through
a command line option to specify the ca cert via a file path.
- Fixes an existing bug appending the timeout option to the singleton
applier connection.
The TABLE_SCHEMA and TABLE_NAME are already guaranteed to have the same value in COLUMNS and UNIQUES because of the WHEREs in each query. Dropping it from the ON clause makes it complete much faster.
On (at least) MySQL 5.6 installs with thousands of tables, this query completes in a few seconds without the additional join conditions, but takes more than a minute with it.
There is no need to call `applyColumnTypes` more than once for the same
`databaseName` and `tableName`, it is just move the additional
`columnList` to the first call.
The given `columnLists` may not contain all columns available in the
given table. This patch prevents the code to fail. Before this patch the
code was panicking whenever it was trying to set a value into a `nil`
object, e.g. `columnList.GetColumn('non-existant').Type = SomeType`.
For some reason the application was not completely failing but as a
side-effect any column after the non-existant column would never get its
Type properly set.
