主页 / dba / 问题 / 334295
Accepted
Potter
Asked: 2023-12-23 02:44:25 +0800 CST

恢复binlog时，应该从dump的开始时间开始恢复还是从dump的结束时间开始恢复？

  • 772

如果我恢复mysqldump备份，然后需要恢复二进制日志中的其他事务，我应该从转储的开始时间（备份开始时）开始恢复还是从转储的结束时间（备份开始时）开始恢复已完成）？

mysqlbinlog --start-datetime=?? /backup/mysql-bin.0*

我已经看到转储的最后一行有完成时间。我应该用它来开始恢复吗？

...
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2023-12-22 12:24:27

但转储没有开始时间。如果我需要从开始时间恢复，如何知道时间？

另外，我们是否可以只恢复单个数据库（因为二进制日志具有所有数据库的更改）？

mysql

1 个回答

  1. Best Answer

    使用时间戳很容易出错，因为一秒范围内可能有很多 binlog 事件。

    更准确的方法是在转储文件中包含准确的二进制日志坐标。创建转储文件时，必须使用该--source-data选项（也称为MySQL 8.0.26 之前的版本）。--master-data

    回复您的评论：

    如果没有该选项进行转储，则无法获得精确的日志文件和位置--source-data。您只能根据时间戳进行猜测，正如我所说，这很可能是不准确的。

    您要么猜测得太早，并重播转储中已表示的更改，要么猜测得太晚，并错过一些更改。

    转储文件末尾的时间戳可能不是您应该使用的时间戳。

    如果转储备份了 InnoDB 表并且使用了该选项，则转储仅包含在转储进程开始时（即事务启动时）--single-transaction提交的更改。但转储文件中不存在该时间戳。转储仅在最后输出时间戳。因此，如果您在读取二进制日志时使用此时间戳，您一定会错过转储开始和结束之间提交的所有更改。

    如果您可以获得创建转储文件时的时间戳（而不是上次写入转储文件的时间戳），则可以估计应该开始从二进制日志中读取的时间戳。这取决于操作系统此信息是否可用。

    • 1

相关问题