Galera MySQL 5.7.17由于设置innodb_undo_table_spaces大于0导致使用RSYNC进行全量数据同步失败的原因及解决办法。
一、问题现场
将一个初始化过（执行过–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。
四、问题解决
出现问题的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程序中设置文件过滤的行中进行如下修改：
之后就可以成功添加节点了。
五、问题跟进
目前这个问题已经提交给了Galera MySQL，并且已经被官方修复。
本文出自微信号 滴滴技术（ID:didi_tech），作者赵博文
