Mysql Percona xtrabackup几乎从不生成可行的备份，但报告称；好的&引用；

我的MySQL（Percona）DB服务器使用的是Percona 5.7.18-16

我正在使用Percona xtrabackup 2.4.8对正在运行的服务器进行实时备份

我已经设置了一个测试服务器来验证从上述主服务器进行的备份

测试服务器也在运行Percona 5.7.18-16

我发现Percona xtrabackup 2.4.8几乎从未做过可行的备份。。。即使它在完成备份阶段时在CLI中报告“已完成OK！”。在测试服务器上，当备份损坏时，大约80%的时间索引都已损坏，有时在恢复备份时，表本身也会损坏

在验证服务器上运行“check table tablename”会使innodb中的验证服务器崩溃，每次备份都会导致各种表和索引损坏

现场时，DB的大小约为400GB。我通过sha256sum确保了我在测试服务器上还原的.tar与在源/主服务器上还原的.tar是完全相同的二进制文件。我用

rsync -avh --progress --no-whole-file --partial user@source_server/path_to_tar.tar .

将xtrabackup生成的目录的.tar传输到验证/测试服务器

我通过innobackupex符号链接调用它，e。g

innobackupex --user=myuser --password=mypass --parallel=4 --rsync ...

然后

innobackupex --apply-log --user=myuser --password=mypass --use-memory=2GB ...

以这种方式生成的备份中约有90%已损坏，在生成备份后，xtrabackup未报告任何错误或故障。对于企业应用程序来说，这是一个惊人的失败率

有什么想法可以尝试解决这个问题吗？Xtrabackup似乎是一种常见且流行的工具

我在live server的表上运行了一个“检查表…”，它是干净的。目前，它上面的5.7 Percona实例正在运行大约370天。在过去的一年中，它每24小时处理大约2500万次插入和大约3000万次更新

但事实证明，使用xtrabackup进行一致备份是可能的

有什么建议吗？有人见过这个吗？如何让xtrabackup对Percona 5.7实例进行一致备份

谢谢

---

Stefan

你如何判断它是否腐败？Percona.com应该能够帮助你。登记他们的资源，而不是任何第三方。在三个关键表上运行检查表。每次至少有一个完整的表或其索引被报告损坏。然后，测试服务器实例崩溃并在/var/log/mysqld.log中记录崩溃转储，该转储标识损坏的表和损坏的页面，或者按名称列出损坏的索引。几乎每一次备份都会发生这种情况（大约90%的备份都是由官方Percona repo的xtrabackup 2.4.8一次又一次地产生的）