使用事务日志刷新延迟是否有危险-例如将innodb_flush_log_at_trx_commit设置为0？

Question

确实，启用此选项的风险实际上比仅丢失最后N秒钟的交易高吗？

让我解释为什么我要问这个问题。 想象一下，数据库服务器刚刚处理了事务T，并因此修改了一组索引页。 这些索引页中很少有已经刷新到磁盘的，而其他很少。 但是T还没有将所有操作刷新到磁盘上的事务日志中。 现在我们关闭电源。

因此，当数据库服务器重新启动并尝试恢复时，它在事务日志中看不到任何T操作。 但是它的某些索引实际上反映了这些操作，因为在电源故障之前已刷新了由T修改的某些索引页。 即，结果是T的一部分被应用-并且可能以导致不一致的索引结构的方式（例如，表X的主索引不能反映T所做的任何更改，但是它的某些二级索引却可以）。

因此，我想知道是否可以延迟事务日志刷新，而如果不这样做，数据库服务器实际上会采取什么措施来防止这种情况的发生（MySQL 5.5 w / InnoDB对我来说是最有趣的情况）。

Answer 1

在Quora上获得了关于此问题的完整答案：

“还避免了检查点（脏页面刷新）fsync事务日志，以避免出现您提到的情况。后台线程计时器不是唯一的日志刷新源。请注意，这会引发疯狂的警告，因为页面中的LSN会是在您的事务日志LSN之前。

通常，在您确实不需要最后一个数据的情况下，在禁用事务日志刷新的情况下运行InnoDB是安全的（并且，如果您运行复制的安装程序，则必须处理主数据库上可能丢失的数据，这些数据可能存在于从数据库上） ”。

Answer 2

几年前Percona Live会议上的这份PDF撰写得不错（请参阅第55页）。

简短的答案：值0不会在COMMIT上刷新或同步，因此它根本不持久。 至少值为2时，您在COMMIT上刷新； 但是即使如此，您也只能每秒同步一次，因此通常也无法接受。

Answer 3

innodb_flush_log_at_trx_commit    
1  every commit log buffer flashed, synced,     no data loss
2  every commit log buffer flashed, not synced, data loss in OS crash or power loss
0  every second log buffer flashed, synced,     data loss on mysql crash, OS crash or power loss

我认为，如果您的数据不是很关键并且硬件有限，则可以使用innodb_flush_log_at_trx_commit=0 。 但是为了赚钱，必须使用银行或安全解决方案innodb_flush_log_at_trx_commit=1来避免丢失任何数据。

Answer 4

简短的回答-这很安全，但是如果OS或MySQL崩溃，您可能会丢失多达一秒钟的已提交事务。

由您决定应用程序是否可接受（例如，财务软件不会容忍数据丢失，但是如果丢失评论，博客将继续存在）。