为什么二进制日志的恢复速度这么慢？

Question

我们有一个启用二进制日志记录的MySQL 5.5服务器和一个备份脚本，该脚本收集二进制日志并每天一次使用mysqldump生成一个完整的数据库转储。在测试从转储和绑定日志恢复数据库时，我们发现后者的恢复速度要慢一个数量级。

具体地说：

• 用mysql dbname < dbdump.sql从92.8MB的数据库转储恢复需要3M26.526s。
• 用mysqlbinlog -d dbname --start-position=107 mysql-bin.000{727..755} | mysql dbname恢复转储后的所有二进制日志花费了38米10.09秒。binlog文件的总大小为56.8MB，来自mysqlbinlog的输出大小为66.4MB。
• 将上述两个步骤结合在一起，只需从(93.2MB)转储中恢复，而这些转储是在二进制日志覆盖的事件之后执行的，总共花费了2m，15.406秒。

这一时间差距正常吗？能做些什么来减少这种情况吗？

Answer 1

您必须了解二进制日志是什么:它们存储自记录查询以来发生的所有查询(以STATEMENT格式)或行更改(以ROW格式)。所以，你的命令：

mysqlbinlog -d dbname --start-position=107 mysql-bin.000{727..755} | mysql dbname

基本上，依次执行服务器在这将近30个绑定日志期间发生的所有插入、更新和删除操作。这就是为什么从二进制日志中恢复只对时间点恢复有用(恢复自上次备份以来的最新更改)。

为了减少应用程序时间，您可以做一些事情，比如暂时减少数据库的持久性和一致性约束(因为您总是可以重播这些步骤)- -innodb_flush_log_at_trx_commit、禁用二进制日志、双重写入等等--或者只尝试使用行二进制日志，这可能会增加磁盘上的大小，但使它们更快地应用。

或者，您可以通过创建更频繁的完整备份(完全备份的大小不太大)、使用xtrabackup之类的工具创建真正的增量备份或差异备份，或者使用滞后的从站进行灾难恢复，从而减少必须应用的绑定日志数量。这是因为mysqldump和mysqlbinlog都以逻辑的方式恢复数据-物理备份在某些情况下可能更快，特别是对于完全恢复。

显然，也可能有一些特定的问题，例如，我有时发现重放LOAD DATA语句比我想象的要慢。

Answer 2

目标是什么？如果目标是拥有恢复系统的路径，那么请考虑使用复制并拥有一个从系统。奴隶通常会和主人在一分钟之内。这比你抱怨的93分钟要好得多。