【问题标题】:Cassandra Write ahead log and memtables flush to diskCassandra 预写日志和内存表刷新到磁盘
【发布时间】:2020-05-15 00:00:44
【问题描述】:

一直在阅读 Cassandra,我觉得它真的不能容错,是吗?

我的意思是,采取一个非常简单的场景,传入写入,您写入 WAL,写入内存表,然后在 WAL 中标记写入成功,然后服务器在内存表满之前崩溃,因此它不会刷新到磁盘作为 SSTable,这意味着我刚刚丢失了这个写入 + 我将无法重做它,因为它在 WAL 中标记为“完成”。

我在这里遗漏了什么还是真的不能容错?这对我来说似乎很奇怪,因为它被用于这么多地方和这么多数据,这让我觉得我错过了一些东西。

【问题讨论】:

    标签: cassandra cassandra-3.0


    【解决方案1】:

    提交日志写在内存表之前。您只需编写突变,没有将突变标记为应用于 memtable。在 memtable 完全刷新到新的 sstable 之前,不会从 commitlog 中删除突变。

    尽管了解这一点很重要,但使用某些提交日志策略,它们不会阻止 ack 在提交日志刷新时写入,因此您仍然可以拥有仅受 RF 保护的数据丢失窗口。因此,在这些情况下,了解持久性的一致性级别和复制因子也很重要。在 4.0+ 中,我认为 group commitlog sync 是批处理和定期之间的绝佳选择。

    【讨论】:

    • 什么是射频?复制因子?
    • 复制因子
    • “使用一些提交日志策略,他们不会阻止 ack 在提交日志上写入”,你的意思是我可以在我发送给 Cassandra 的写入时在我的客户端中得到一个 ack,即使它还没有被写入提交日志还没有(在内存中,因为默认情况下文件仅每 10 秒刷新一次)?
    • 没错。这就是为什么如果您的复制很差或以任何方式依赖单节点持久性,您应该使用批处理或组提交日志同步。
    猜你喜欢
    • 2010-09-15
    • 1970-01-01
    • 2017-06-17
    • 2012-03-01
    • 2010-09-10
    • 2019-08-29
    • 1970-01-01
    • 2011-01-28
    • 1970-01-01
    相关资源
    最近更新 更多