5.5升级5.7回退 mysql_故障分析 | Bad handshake，升级 5.7.28 引起的“血案”

引言

作为一名 DBA 碰到过升级出问题需要回退么？碰到过回退还解决不了问题么？我有幸遇到了一次凶险的升级“血案”。问题来自协助客户升级 MySQL，以修复一个安全漏洞。升级版本为 5.7.30，但这个问题源于 5.7.28，并且影响 5.7.28 以上的版本，所以文章主要对比 5.7.27 和 5.7.28 版本。注意不是 bug，后面会详细说明！

一、现象

MySQL 从 5.7.27 升级到 5.7.30。完成后应用连接测试发现页面异常，mysql error 日志显示：2020-05-05T22:10:57.976402+08:00 2 [Note] Bad handshake

没有报错，但这条 Note 级别的日志，引起了我的注意，之前从来没有见过。由于时间紧急，决定先回退 MySQL 版本。回退后，问题未能解决。Bad handshake，"不好的握手"，网上查了资料，发现和 SSL 可能有关。这时业务也发来应用日志，日志有明显的 SSL 相关报错。然后，我们去检查了 jdbc 连接串，连接串使用了useSSL=true，改为useSSL=false后解决了。二、分析我们搭建了一套 java 应用环境，在 5.7.27 版本和 5.7.28 版本分别测试了发生故障时的 jdbc 串：spring.datasource.url=jdbc:mysql://192.168.199.198:3307/springbootdb?useUnicode=true&useSSL=true&characterEncoding=utf8

5.7.27 版本

1. 默认关闭了 SSLmysql> select @@version;

+------------+

| @@version  |

+------------+

| 5.7.27-log |

+------------+

1 row in set (0.00 sec)

mysql> show variables like '%ssl%';

+---------------+----------+

| Variable_name | Value    |

+---------------+----------+

| have_openssl  | DISABLED |

| have_ssl      | DISABLED |

| ssl_ca        |          |

| ssl_capath    |          |

| ssl_cert      |          |

| ssl_cipher    |          |

| ssl_crl       |          |

| ssl_crlpath   |          |

| ssl_key       |          |

+---------------+----------+

9 rows in set (0.00 sec)

2. 应用页面正常

3. tomcat 日志正常