MySQL备份故障：DDL 导致的 Xtrabackup 备份失败

日常数据库巡检发现备份日志提示以下问题

InnoDB: Last flushed lsn: 3375345258517 load_index lsn 3379255303757
InnoDB: An optimized (without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet. 
PXB will not be able take a consistent backup. Retry the backup operation

查阅资料得知是，DDL导致xtrackback备份失败。与业务部门沟通是当时半夜1点清表构建索引，与xtrackback备份脚本时间重合，故而导致备份失败。

资料引用：

• Percona 称这是 Xtrabackup 2.4.x 的一个 bug ，主要是为了避免得到一个错误的备份集，一旦检测到有不记录 redo 的 DDL 操作，就会将备份进程终止，而客户生产环境中的 PXB 版本正是2.4.3。
• 针对这一问题，Percona在Xtrabackup 2.4.8 及之后的版本中，新增了–lock-ddl，–lock-ddl-timeout，–lock-ddl-per-table这几个参数，使其可以在备份时加上备份锁，或给表加上 MDL 锁来阻塞其他的 DDL 操作，使备份顺利完成
• 原因明确了，就知道如何解决问题了，最后分别在2个从库上执行手动备份，每个实例（500G左右）大约耗时2小时40分钟完成备份
• Percona 以增加参数的方式提供了解决备份失败的方法，那如果暂时无法升级 PXB 版本，仅在 MySQL 层面，有没有解决方法呢？其实也是可以的。

总结：
1、DDL 业务变更操作应尽量避开备份窗口
2、默认情况下，即使是 Xtrabackup 高版本，如果备份时并发执行 DDL ，并且没有指定 DDL 锁参数（–lock-ddl，–lock-ddl-per-table），会导致备份失败。