我正在使用 innobackupex 来备份我的数据库,如下所示:
usr/local/bin/innobackupex --user=bkpuser --password='example' --rsync \
--no-timestamp /pathtobackup 2> /pathtobackup/innobackupex.log
现在这页面显示“但是有些事务尚未完成,还有一些事务尚未刷新到其数据文件中。换句话说,如果数据库崩溃,则备份原样将类似于数据目录。仍然必须应用一些其他事务。”。
这是真的吗?我认为至少刷新部分不是真的,而且我不确定交易。我的目标是能够恢复我的数据库,就像它从未发生过故障一样,所以请提供建议。
答案1
简洁版本:如果您正在对繁忙的服务器运行备份,那么是的。
如果您锁定服务器以防止更新,即作为从属服务器并mysql -e "STOP SLAVE"
在备份之前执行更新,我怀疑 xtrabackup_logfile 会为空,并且 apply-log 不会执行任何操作。
较长版本:
有一份文档提供了制作备份和恢复它的示例,作为操作指南的一部分准备从属设备进行复制,这表明在日志可供使用之前需要添加一个步骤来应用日志;
innobackupex --user=yourDBuser --password=MaGiCdB1 /path/to/backupdir
innobackupex --user=yourDBuser --password=MaGiCdB1 /
--apply-log /path/to/backupdir/$TIMESTAMP/
这选项页面对于 innobackupex 表示--apply-log
从读取事务xtrabackup_logfile
通过应用位于同一目录中名为 xtrabackup_logfile 的事务日志文件,在 BACKUP-DIR 中准备备份。此外,创建新的事务日志。InnoDB 配置是从备份时由 innobackupex 创建的 backup-my.cnf 文件中读取的。
我怀疑其中xtrabackup_logfile
包含备份运行但数据库未被锁定期间的事务。我认为通过这种策略,innobackupex 可以在很短的锁定时间内运行,并使用 binlog 回顾性地将更新应用于备份。
xtrabackup-manager 工具应用日志在此文件中有一个 apply-log 步骤;
http://code.google.com/searchframe#i12s1rWpN4M/trunk/includes/genericBackupTaker.class.php&q=apply%20log%20package:xtrabackup-manager.googlecode.com
目前还不清楚这些文件是什么格式(file xtrabackup_logfile
返回“数据”),尽管它们在我的系统上似乎很稀疏,但在这种情况下我并不期望有任何待处理的事务,因为备份是从已停止的从属服务器获取的。不过,如果你想知道,可以查看 xtrabackup 的源代码。