1

重启后数据不可见。我猜测数据被传递给副本以写入，然后将其放入 ext4。但是在 ext4 可以将数据同步到磁盘之前，节点会重新启动并且数据不会下推到 EBS 磁盘。

有没有办法解决这个问题？我正在openebs使用jiva. 我有我的MySQL -> ext4 (iscsi volume) -> Replica -> ext4 (block disks - say Amazon EBS).

有时，我观察到，如果运行 Replica 的节点重新启动...

4

1 回答 1

1

这是lwn.net 上的一篇文章，它详细讨论了程序无法在 ext4 上进行充分同步（也称为崩溃一致性）时潜在的数据丢失（评论讨论也很有启发性）。

ext3 显然在使用时实现了更好的崩溃一致性，data=ordered因为它在元数据更改提交到日志之前强制数据到磁盘。此外，使用 5 秒的默认提交周期。在 ext4 的情况下，使用延迟物理块分配模型进行性能权衡，从而导致未提交的数据继续存在于缓存中一段时间​​。引用文章：

内核不喜欢让文件数据长时间处于未写入状态，但刷新数据仍可能需要一分钟左右（使用默认设置） - 远远长于 ext3 通常看到的 5 秒

因此，未写入的数据理论上只能存在于易失性缓存中，直到它被系统范围强制写入磁盘sync或应用程序显式fsync显示其自己的数据（正如 Jeffery 指出的那样）。如果应用程序/客户端不这样做，我们更容易丢失数据。

缓解此问题的一种方法是使用选项挂载所需的文件系统sync（请参阅此“ext4 和数据丢失”讨论线程），为此我们必须在两个地方强制执行它：

  1. 装入吊舱
  2. OpenEBS 存储池或后端存储

（在 1 的情况下，我们可以让目标将所有写入转换为同步，正如 Jeffery 所解释的）

虽然mount(8)文档明确指出，-o sync仅在ext3（在 ext 系列文件系统中）之前支持 using，但接受使用此选项的手动文件系统挂载。为了检查它是否是挂载协议允许但被 ext4 忽略的东西，我对 256M 的数据样本大小进行了一个基于 fio 的小型随机写入性能测试，磁盘使用同步选项挂载，并且与一个没有它。为了确保写入本身不是 SYNC 写入，使用direct=1and iodepth=4（异步多线程无缓冲 I/O）选择了 libaio ioengine。结果显示大约 300+ IOPS 的差异（当然，非sync挂载性能更好）。这一结果表明，sync挂载标志似乎确实起作用，但我仍在寻找更多证据。

于 2018-09-19T07:20:08.247 回答