seata 1.5.1 k8s 部署,使用 8.0 mysql报错,怎么解决？

1.因为SSL连接原因(大部分人的原因)
因为MySQL在高版本需要指明是否进行SSL连接。有可能你 pom 文件引入的 MySQL 依赖版本是MySQL5.7及以上 这些的时候，你就需要指定SSL连接，如果你不知道，默认就是开启，所以就会出现上面的错误。

2.因为数据库连接超时原因
当数据库重启或数据库空闲连接超过设置的最大timemout时间，数据库会强行断开已有的链接。

解决
1.只需要设置useSSL=false来禁用SSL
例如：

jdbc:mysql://localhost:3306/test?useUnicode=true&characterEncoding=utf-8&useSSL=false

在MySQL5.7之前的版本，安全性较低，存在任何用户都可以连接上数据库，所以官方在5.7版本加大了对隐私的保护。并且采用了默认 useSSL = true值防止对数据库的随意修改，到了8.0版本，仍然保留了SSL，并且默认值为 true。

2.超时解决

• windows系统配置 MySQL 的 my.ini文件的 interactive_timeout=388000和wait_timeout=388000 属性。

• linux系统下需要去mysql的安装目录查看my.cnf文件，然后修改同样的属性。

——参考文档。

Seata 1.5.1 支持 MySQL 8.0,如果你在部署时遇到了报错,可以尝试以下方法来解决问题:

1. 检查 MySQL 服务是否启动正常,并且在 Seata 部署的机器上是否能够正常访问。

1. 检查 MySQL 的配置是否正确,包括端口号、用户名、密码等。

1. 检查 Seata 的配置是否正确,包括数据库连接地址、端口号、用户名、密码等。

1. 如果以上方法都无法解决问题,可以尝试修改 Seata 的配置文件,将连接池的 maxActive 参数设置得小一些,例如 10。这样能够减少连接池中的连接数,从而降低连接超时的风险。

可能原因：

A 执行的总体时间超过了60000ms，导致全局事务发起了全局回滚，此时A或B方法继续执行DB操作，校验全局事务状态，发现全局事务已经回滚。

B服务执行超出其设定的readTimeout 返回异常给A并将异常抛出导致全局事务回滚，此时B服务执行DB操作时，校验全局事务状态，发现全局事务已经回滚。

tc集群节点时间不一致。

影响：出现这种情况时，数据会整体回滚至A方法执行前的数据的初态，从数据一致性的视角上看，数据是整体一致的。

除了上述情况，如果引用的是seata-spring-boot-starter的话，产生这个错误的原因也可能是因为一个bug，目前在1.5版本进行了修复，具体可以参考issues4020，PR4039。
https://seata.io/zh-cn/docs/overview/faq/#39