个人认为Percona 对MySQL最大的贡献就是它提供了MySQL 的热备份工具xtrabackup.
对于V2版本中有一个问题是:从备份文件中恢复数据时,对于备份前新创建的表,是无法完全利用工具恢复.frm表格式文件。(不过这并不影响使用)。(貌似网上有人已经做了修改)
由于我们默认的存储引擎是InnoDB,所以直接使用Innobackup 工具,每天凌晨两点备份。今天发现备份目录中都没有.frm文件。
第一步:查看备份日志
对于备份是否成功,我们通过邮件通知。db server 上有详细的日志:
innobackupex: Backing up file '/usr/local/mysql/data//wpf/abc_after.TRN' innobackupex: Backing up file '/usr/local/mysql/data//wpf/abc.frm' innobackupex: Backing up file '/usr/local/mysql/data//wpf/db.opt'
日志中有详细拷贝.frm文件的记录。而且没有任何Warning和Error。
第二步:日志没有可用信息,查看监控记录
翻看zabbix中的历史记录没有异常,查看pt-stalk中的记录,和以前相比,没有异常。
第三步:没有可用记录,怀疑备份文件是否有问题
如果备份文件有问题的话,可以直接报bug啦。对备份文件拷贝至其他机器进行恢复,并添加好.frm文件。对某张特殊表 进行时间戳,重复线上的查询。。结果没有问题。
第四步:查看其他crontab 程序
由于在使用xtrabackup 之前已经经过测试,也怀疑过脚本的问题。但已经报告备份成功而且能成功恢复。只有一个del程序。是删除15天之前的备份文件。程序内容大致为:
find path -mtime +15 | xargs rm -rf
但为什么只删除表结构文件呢,不删除数据文件?难道.ibd 对于find来说是特殊文件不删除(这个是不可能的)。备份文件的时间不一致? 同时备份的怎么会不一致呢?结果发现时间真的不一样。 数据文件是 ibbackup 程序拷贝,时间戳是备份的时间。而 .frm文件是innobackupex程序 未修改文件“最后修改时间”而copy至备份文件夹。
幸好发现的早!
del 删除程序改为:
find path -name "2*" -mtime +15 | xargs rm -rf 本文转自 位鹏飞 51CTO博客,原文链接:http://blog.51cto.com/weipengfei/1049423,如需转载请自行联系原作者