乐趣区

关于jdbc:故障分析-Java-连接-MySQL-80-排错案例

作者:胡呈清

爱可生 DBA 团队成员,善于故障剖析、性能优化,集体博客:https://www.jianshu.com/u/a95…,欢送探讨。

本文起源:原创投稿

* 爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。

在客户那边遇见过几次这样的问题,Java 连贯 MySQL8.0 偶然 会报错:java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed。网上一搜这个报错,早有人踩过这个坑:

如果用户应用了 sha256_password 认证,明码在传输过程中必须应用 TLS 协定爱护,然而如果 RSA 公钥不可用,能够应用服务器提供的公钥;能够在连贯中通过 ServerRSAPublicKeyFile 指定服务器的 RSA 公钥,或者 AllowPublicKeyRetrieval=True 参数以容许客户端从服务器获取公钥;然而须要留神的是 AllowPublicKeyRetrieval=True 可能会导致歹意的代理通过中间人攻打(MITM)获取到明文明码,所以默认是敞开的,必须显式开启。

原始文档如下:

JDBC 增加参数 AllowPublicKeyRetrieval=True 后的确解决了问题,然而留神前边说的“偶然”两字,我遇见了大略三种状况,在这之前一点问题都没有,但一产生就会报错:

1.MySQL Server 重启了;

2.MySQL MGR 产生切换了;

3.DBA 对 MySQL Server 做了某些变更后。

那后面的解释就显得有点不够了,尤其是第 3 点,开发肯定会感觉这是 MySQL 层面的问题或者 DBA 的问题,而不是他们对 MySQL 驱动理解不够。上面就为大家揭晓答案。

caching_sha2_password

MySQL8.0 默认应用明码加密插件为:caching_sha2_password,应用 sha256 算法对明码加密。而且在应用此插件时,MySQL Server 会在内存中缓存用户的认证信息,使已连贯的用户的身份验证速度更快,文档形容:

这个缓存的说法就很暧昧了,当然因为文档上没有更多形容,咱们只能先做假如:Java 程序通过驱动连贯到 MySQL 时,如果 MySQl Server 有用户的验证缓存,则不须要额定配置 RSA 公钥即可连贯胜利;如果没有缓存也没有指定 RSA 公钥,则连贯报错:Public Key Retrieval is not allowed

有了假如,咱们就要去论证,实际上论证的办法就是测试。

测试过程

测试代码:

编译后运行,间接复现报错:

接下来手工应用 mysql 客户端,用代码中的 user1 用户连贯 MySQL 服务器,使其产生缓存(这个操作就是管理员创立了利用用户后,手工验证了利用用户是否可登录):

而后再次运行 java 程序,将不再报错:

而后重启数据库,再次运行程序触发报错:

再次手工连贯,尽管程序恢复正常:

执行 flush privileges;;操作清空用户缓存,随后运行程序再次报错:

MGR 产生切换的场景就很容易解释了,因为之前始终没有应用利用用户连贯过新的 Primary 节点,所以也就没有产生过缓存,所以应用程序连贯新的 Primary 节点会产生报错。

论断

一开始,在 MySQL Server 上创立利用用户后,手工应用 mysql 客户端对利用用户进行了验证,MySQL Server 缓存了利用用户的验证信息。应用程序的 JDBC 参数设置在没有指定 RSA 公钥和设置 AllowPublicKeyRetrieval=True 的状况下,连贯 MySQL Server,因为 MySQL Server 有用户缓存,所以能够失常连贯。

之后如果产生以下几种状况:

1.MySQL Server 重启了;

2.MySQL MGR 产生切换了;

3.DBA 对 MySQL Server 做了 flush privileges;

会导致 MySQL Server 的用户缓存生效,应用程序连贯 MySQL 异样:Public Key Retrieval is not allowed。

解决方案

以下计划抉择一种即可:

1. 应用程序指定 RSA 公钥;

2. 应用程序设置 AllowPublicKeyRetrieval=True;

3.MySQL Server 层批改用户的明码加密插件为 mysql_native_password。

退出移动版