1

启用这样一个选项的风险是否真的高于丢失最后 N 秒的交易？

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

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

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

4

4 回答 4

1

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

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

一般来说，在禁用事务日志刷新的情况下运行 InnoDB 是安全的，只要您真的不需要最后的数据（如果您运行复制设置，您必须处理主服务器上丢失的数据，这些数据可能存在于从服务器上） 。”

于 2013-02-28T14:57:59.700 回答
0

这个来自几年前 Percona Live 会议的PDF有一个不错的文章（见第 55 页）。

简短的回答： 0 的值不会在 COMMIT 上刷新或同步，因此它根本不耐用。至少值为 2，您在 COMMIT 上刷新；但即便如此，您也只能每秒同步一次，因此这通常也是一种不可接受的妥协。

于 2013-02-21T01:40:41.737 回答
0

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

由您决定它是否适合您的应用程序（例如，金融软件不会容忍数据丢失，但如果评论丢失，博客将继续存在）。

于 2014-02-10T21:39:30.153 回答
0 
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但是对于金钱，必须使用银行或安全解决方案以免丢失任何数据。

于 2014-01-15T22:28:23.340 回答