Closes#822.
In https://github.com/go-sql-driver/mysql/issues/1075, @acharis notes
that the way the go-sql driver is written, query timeout errors don't
get set in `rows.Err()` until _after_ a call to `rows.Next()` is made.
Because this kind of error means there will be no rows in the result
set, the `for rows.Next()` will never enter the for loop, so we must
check the value of `rows.Err()` after the loop, and surface the error up
appropriately.
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.
