在听到新兴的分布式数据库介绍时,总会听到「强一致」「不丢数据」或者「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的秘密 (下)
欢迎跟帖讨论。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
您提到的这些观点确实为判断一个数据库是否能够确保不丢数据提供了很好的分析框架。从您的描述中,我们可以总结出几个关键点来评估数据库的数据安全性:
Write-Ahead Logging (WAL):这是确保事务日志先行于实际数据写入磁盘的一种机制,是保证数据一致性和持久性的基础。几乎所有现代数据库系统都采用了这一机制。
事务日志的持久化方式:直接I/O(Direct I/O)相比缓冲I/O更能确保数据及时写入磁盘,减少数据丢失的风险。Oracle、MySQL和OceanBase在处理redo log时采取了不同的策略,其中OceanBase明确指出使用了Direct I/O,并且通过Paxos协议跨节点复制redo log,以增强数据的持久性。
多副本与一致性协议:OceanBase采用的三副本架构及Paxos协议是其保证“RPO=0”优势的关键。只要超过一半的副本确认日志成功持久化,就认为写操作完成,这不仅提高了系统的可用性,也确保了即使在部分节点故障的情况下,数据也不会丢失。
两阶段提交:MySQL中的InnoDB引擎利用两阶段提交来协调redo log和binlog的一致性,虽然提升了性能灵活性,但可能不如OceanBase的Paxos协议在极端情况下的数据安全级别。
配置与策略:不同数据库系统提供了不同的配置选项,如MySQL的sync_binlog
和innodb_flush_log_at_trx_commit
参数,允许用户根据性能需求调整日志落盘的严格程度,而OceanBase则通过其内部机制确保了较高的默认安全标准。
综上所述,要判断一个数据库是否真的不丢数据,可以考虑以下步骤: - 确认该数据库是否实施了WAL机制。 - 了解其事务日志的持久化策略,特别是是否使用Direct I/O。 - 分析其多副本架构和一致性协议,比如是否采用类似Paxos这样的强一致性协议。 - 考察数据库的默认配置以及是否有灵活的配置选项来平衡性能与数据安全性。
最后,实践检验也是重要一环,可以通过模拟故障场景、进行压力测试等方法,验证数据库在异常情况下的表现,从而更直观地评估其数据不丢失的能力。