Galera MySQL 5.7.17由于设置innodb_undo_table_spaces大于0导致使用RSYNC进行全量数据同步失败的原因及解决办法

Part.1

一问题现场

将一个初始化过（执行过–initialize）的节点添加到Galera MySQL集群中时：数据同步完成后，Innodb使用undo log中的记录回滚未提交的事务时会触发下面的ERROR：

ERROR说Innodb访问了一个undo log表空间之外的数据页。

二问题猜测

在Galera MySQL中，向正在运行的集群中添加一个节点时会触发全量数据同步——SST。SST会选择一个donor，并将这个donor的整个数据目录中的内容同步给新添加的节点。

照此，如果新添加的节点上的数据是donor节点的一份一模一样的拷贝的话，那undo log也会是donor节点正在使用的undo log，理论上也就不会出现任何问题。

所以怀疑是在进行SST的时候出了问题，没能正常同步undo log。

三验证猜测

删除没能正常同步数据的节点数据文件夹夹内的所有文件（恢复到–initialize之前的状态）并启动MySQL，将这个节点添加到集群中，发现数据文件夹内并没有undo log：

于是产生上面ERROR的原因可以确定为是执行SST时没能正常同步undo log table space。

Part.2

问题解决

出现问题的Galera MySQL集群使用rsync作为SST同步数据的方法；在使用rsync同步数据时默认会使用【/usr/bin/wsrep_sst_rsync】程序。

改程序在调用rsync传输数据之前会为rsync设置如下的文件过滤规则：

可以看出文件过滤规则中虽然指定了innodb的系统表空间iddata,但是却没有添加undo log表空间的文件——以undo开头的文件：

在MySQL 5.7之后的版本，为了避免大的事务造成系统表空间变的过大，将配置【innodb_undo_table_spaces】设置为大于0的值时，Innodb使用独立于系统表空间之外的文件存储undo log；但是Galera MySQL的【wsrep_sst_rsync】却没有考虑到这一点，导致进行数据同步时，没能正确同步独立的undo log表空间。

于是在wsrep_sst_rsync程序中设置文件过滤的行中进行如下修改：

之后就可以成功添加节点了。

Part.3

问题跟进

目前这个问题已经提交给了Galera MySQL，并且已经被官方修复。

本文转载自公众号滴滴技术（ID：didi_tech）。

原文链接：

https://mp.weixin.qq.com/s/wKdU7GskIIFRVDGOXKry-Q

创作场景

Galera MySQL 5.7.17 bug 修复