Question

开启此类期权的风险是否真的高于仅仅减去最后N秒的交易？

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

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

所以我想知道如果我延迟事务日志刷新，这样的事情真的有可能，如果没有，那么数据库服务器实际上做了什么来防止这种情况（MySQL 5.5 w / InnoDB对我来说是最有趣的案例）。

Answer 1

在Quora上对这个问题得到了完整的答案：

“检查点（脏页刷新）fsync事务日志也是如此，以避免你提到的情况。后台线程计时器不是日志刷新的唯一来源。请注意，这会引发疯狂的警告，因为页面中的LSN将超过事务日志LSN。

通常，只要您确实不需要最后的数据（并且如果您运行复制的设置，您必须处理主服务器上可能存在的数据），运行禁用事务日志刷新的InnoDB是安全的。在奴隶上。“

Answer 2

来自几年前Percona Live会议的

This 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

简短回答 - 它是安全的，但如果操作系统或MySQL崩溃，您可能会丢失长达一秒的已提交事务。

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

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

4 个答案: