MySQL二进制日志格式-磁盘填充

Question

我已经配置了一个MySQL服务器实例，启用了二进制日志记录。我不做任何复制，但是二进制日志是我们恢复计划的一部分-能够重播自上次完全备份以来的所有事务。

不久前，在一个已经运行了几周的系统上，人们注意到MySQL错误日志已经增长到超过5GB的异常大小。查看日志，几乎每一行都是关于“写入二进制日志的不安全语句”的警告。

现在，我无法控制使用数据库的应用程序，因此无法尝试使这些语句“安全”。因此，作为“修复”，我将binlog_format配置为混合语句，而不是语句。这告诉MySQL在可能的情况下使用语句日志记录，但返回到行日志记录和不安全语句。这样做成功地使错误日志的大小保持在可管理的大小。

但是，现在二进制日志的增长速度比以前快得多(我在今天的几个小时内看到了3GB的日志文件)，大概是因为现在系统正在为受影响的每一行写入日志(对于“不安全”语句)，对于影响大量行的语句，好吧，您可以看到图片了。

所以，我发现自己在一块岩石和一个艰难的地方之间。如果使用语句格式，二进制日志是可管理的，但错误日志中有大量警告。如果我使用混合格式，错误日志是很好的，但是二进制日志增长得足够快，甚至可能在一天内填充分区。

这让我想到了我的疑问:这些“不安全”的言论到底有什么影响？就像我说的，我没有任何复制，所以我不需要担心一台服务器和另一台服务器完全相同。我只需要确保在需要从备份恢复的情况下，所有的数据都在那里。“不安全”语句的日志记录会导致数据丢失，还是只会出现某些行的顺序不同(可能有不同的主键id)的情况？如果这不是什么大问题，那么我可以在错误日志中禁用警告(尽管这看起来确实很麻烦)。

否则，我可能会被迫完全取消二进制日志记录，而只是依赖于恢复计划中可能过时的完整备份。

在这种情况下有什么建议吗？

Answer 1

基于行的复制格式实际上比基于语句的复制格式使用更多的磁盘空间。这很简单，因为在binlog中将包含插入/更新的所有数据，而不仅仅是语句。因此，如果语句要求插入100行，如果binlog_format=STATEMENT只插入一条语句，但是if is行实际上将包含所有条目。

因此，为了节省磁盘空间，您必须恢复为基于语句的。mysql将尝试将语句写入binlog，但在出现不安全语句时，将恢复为基于行的语句。在您的示例中，您似乎有许多不安全的语句，因此您最终得到了基于行的二进制日志。

你可以做几件事

• 将其保留为行，并实现一个清理作业，该作业将在一段时间后清除日志，这需要计算出适合您的系统的内容。在删除日志之前，您应该将它们复制到其他地方，这样就不会丢失日志。
• 通过第二个系统实现复制，并再次在主系统上进行清理作业(确保从机同步，否则可能会丢失数据)
• 仔细查看可能不安全的语句，这可能需要与应用程序的开发人员协作。