MySQL [Bad handshake] error after update

master-slave-replicationMySQLUbuntu

I have MASTER-SLAVE configuration on 2 servers. The MySQL replication is set over SSL (I use self-signed certificates).

Everything had been working well. But today some packages (mysql also) were updated via apt update, upgrade. Current version is: mysql Ver 14.14 Distrib 5.7.28, for Linux (x86_64)

Both server and client have the same mysql version now, but slave can't connect to the master. In master's log I see the following error repeating many times:

2019-11-19T16:49:55.109509Z 1130 [Note] Bad handshake
2019-11-19T16:50:55.296184Z 1432 [Note] Bad handshake

What should I check in order to fix this problem? I've already tried to reissue certificates, but it didn't help.

Thanks.

Best Answer

MySQL 5.7.28 dropped support for yaSSL. On some platforms, such as RHEL and presumably Ubuntu, that resulted in a change from yaSSL to OpenSSL. There are a variety of things that would have worked under yaSSL but no longer work under OpenSSL. For example, yaSSL could not handle certificate chains, but OpenSSL both sends and verifies full chains.

Among other troubleshooting techniques, try taking a packet capture of the TLS handshake with tcpdump and decoding it in Wireshark.

Related Solutions

MySQLDump wrong dump

Just reading the header you put in the question shows something interesting. In fact, the question shows three things:

MySQL dump 10.13 Distrib 5.1.34, for apple-darwin9.5.0 (i386) indicates you used mysqldump from apple-darwin9.5.0 (i386) binaries
Server version 5.0.51a-24+lenny2 shows the version of mysql you used mysqldump to dump from.
You wanted to load the mysqldump file into Ver 14.14 Distrib 5.1.57, for apple-darwin10.3.0 (i386) using readline 5.1

What a jumble of versions to do this with.

If you want to see if mysqldump has an issue with the line that has DATEDIFF, try dumping just the schema.

mysqldump --no-data --all-databases ... > MySQLSchema.sql

This will display ony the schema. No INSERTs will be in the output. You can then hunt down that lines. You may also want to dump the data onyl without the schema,

mysqldump --no-create-info --all-databases ... > MySQLData.sql

Splitting the dumps allows you to load the schema into an editor and see if there are any problems. If you do not see any problems, load the MySQLSchema.sql into the target server. If the error is reproduced, you can fix the schema file and reload. Once the schema is loaded, you can separate load MySQLData.sql

BTW you should use mysqldump binary whose version is 5.0.51a-24+lenny2. Use dumps from version as mysqld is usually better to port and may minimize problems like this.

Give it a Try !!!

Mysql – Does replication with SSL encryption work on MySQL 5.5

To use SSL for encrypting the transfer of the binary log required during replication, both the master and the slave must support SSL network connections. If either host does not support SSL connections (because it has not been compiled or configured for SSL), replication through an SSL connection is not possible.

Setting up replication using an SSL connection is similar to setting up a server and client using SSL. You must obtain (or create) a suitable security certificate that you can use on the master, and a similar certificate (from the same certificate authority) on each slave.

For more information on setting up a server and client for SSL connectivity refer this link

Please follow the steps mentioned here:

http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-ssl.html

I was searching in bugs.mysql.com related to MySQL 5.5 but there is nothing reported w.r.t "replication with SSL" for v5.5. You can mention exact error message here for analysis.

Best Answer

Related Solutions

MySQLDump wrong dump

Mysql – Does replication with SSL encryption work on MySQL 5.5

Related Question