阿里云
阿里云多端小程序中小企业获客首选
发表主题 回复主题
  • 2371阅读
  • 0回复

[用户交流]如何分析一个数据库是否能做到不丢数据?

级别: 论坛版主
发帖
62
云币
148

    在听到新兴的分布式数据库介绍时,总会听到「强一致」「不丢数据」或者「RPO=0」这些话语。 包括OceanBase更是把这个作为优势之一宣传。

     那么如何己判断一个数据库是否真的不丢数据?  

     这里有些观点供大家参考。


      1. 看数据库是否支持事务日志先行机制(Write-Ahead Logging, WAL)。即写数据之前先写REDO 。
      2. 看REDO如何持久化到磁盘?或者持久化到多个机器的磁盘。


     基本上所有的数据库都支持WAL机制,不同之处在于对事务日志持久化的处理逻辑上。  


       持久化到磁盘的时候牵扯到一个IO。操作系统的io接口有两类。一类是buffered io。读写会经过内核里 的page cache(或叫buffer)。写到这个cache里请求就返回了。但是数据并不是及时刷写到磁盘。另外一类就是direct io。读写不经过内核里page cache。写请求会直接抵达磁盘。
       如果考虑写安全,数据库的写应该都是directio。


    
     ORACLE的redo和data的写都是directio。redo及时落盘。ORACLE提供dataguard搭建主备同步,redo在同步到备库的时候有同步和异步两种行为,同步策略有高安全、高可用、高性能三种策略。所以redo也不一定是实时在备库上落盘。
     MySQL的架构特别一些,有server层和引擎层。对于每个事务有innodb的redolog和server层的binlog。所以MySQL内部有个两阶段提交协议去维护binlog和innodb redo log的一致性。但是由于binlog是sql,只记录已提交的事务的sql,所以这个一致性并不是严格的。加上MySQL为了性能更好,提供了2个参数用于控制binlog 落盘和redo log盘的行为。 在性能最好的配置下(双1),binlog和redo log并不实时落盘。
      OceanBase的redo 和data写也是directio,redo会实时落盘。同时在三副本架构下,redo还会持久化到其他节点的磁盘上。只不过使用了paxos协议,只要一半以上成员redo持久化成功,主副本的写就可以继续提交了。这个保证了redo绝对可靠安全。


     详细介绍请参考这里  揭开数据库RPO等于0的秘密 (上)  揭开数据库RPO等于0的秘密 (下)


      欢迎跟帖讨论。
[ 此帖被mq4096在2019-03-11 10:17重新编辑 ]
发表主题 回复主题
« 返回列表上一主题下一主题

限100 字节
如果您在写长篇帖子又不马上发表,建议存为草稿
 
验证问题: 4 + 7 = ?
上一个 下一个
      ×
      全新阿里云开发者社区, 去探索开发者的新世界吧!
      一站式的体验,更多的精彩!
      通过下面领域大门,一起探索新的技术世界吧~ (点击图标进入)