数据库作为IT系统中最关键的服务之一，其可用性一直是系统设计中的重点考虑因素。同时，由于数据库有数据有状态的天性，数据库高可用有其天然的复杂性和难点，云原生架构下尤其如此，是一个值得深入探讨的课题。本系列文章将基于网易杭州研究院的研究与实践，解析数据库高可用技术要点，梳理主流数据库方案，为数据库技术建设规划提供参考。
本文由作者授权网易云发布，未经许可，请勿转载！
作者：倪山三，网易杭州研究院运维工程师
Catalog
- 0. Prologue
- 1. 数据库高可用技术要点
- 1.1. 冗余设计 — 数据冗余方案
- 1.2. 冗余设计 — 冗余数据间的一致性
- 1.3. 冗余设计 — 实例冗余
- 1.4. 故障切换 — 服务角色
- 1.5. 故障切换 — 故障感知与应对
- 1.6. 故障切换 — 业务连接切换
- 2. 主流数据库方案概览
- 2.1. 主流数据库高可用功能概览
- 2.2. MySQL数据库高可用功能概览
接上文：
网易杭研总结：数据库高可用技术之道（1）
网易杭研总结：数据库高可用技术之道（2）
1.3. 冗余设计 — — 实例冗余
前面我们介绍了数据库的核心资源, 数据, 如何实现多份冗余, 提高可用性. 接下来介绍数据库另外半壁江山, 服务实例, 如何实现冗余. 学习Oracle的同学一般背诵的第一条架构描述就是数据库服务由磁盘数据和进程实例两部分组成. 数据库的最终目的还是要读写数据, 离开了实例, 磁盘数据无法被访问, 数据库实际上也没有什么价值.
实例冗余的要求很简单, 就是当数据库服务进程由于各种原因失效的时候, 能够有一个或一组备用进程尽快接管服务, 这其实同多个应用服务互备没有区别. 但是数据库服务的目的是访问数据, 因此数据库实例冗余的难点和设计思路都是围绕着满足用户高可用切换前后必须访问“相同的数据"这一目标展开的.
1.3.1. shard nothing
最简单也是最经典的架构, 数据不共享. 典型的例子有MySQL, Oracle (仅dataguard), MongoDB, Redis, PostgreSQL等.
要注意, 在Oracle高可用实现有许多种架构方案(这部分我们会在第二章节详细讨论), 如果仅使用dataguard保护数据, 不引入其他组件的情况下, Oracle也可以看做shard nothing架构.
总而言之, 在使用日志进行数据同步冗余的架构中, 非共享模式是主流模式. 主库和备库数据库从服务到磁盘数据都是独立的, 分散在不同介质中的.
这一模式下, 数据库实例和底层磁盘数据可以看做绑定的一体, 实例或数据故障是通过相同机制完成冗余切换的. 应用切换到访问冗余服务后, 虽然读写看上去基于相同的数据, 满足业务要求, 但是这个相同是由日同步机制保障得到的逻辑副本, 物理上实际是另一份数据.
该架构实现简单, 通用性强, 注重实用, 是线上最常见的方案, 主要缺陷还是数据同步延迟造成主从可见数据不一致, 导致高可用失效风险. 使用DRBD等存储共享架构的冗余方案, 我倾向于也归于此类, 毕竟通过网络同步的存储介质是独立的.
1.3.2. shard data
在无共享架构下, 我们提到数据和服务看做一体, 任意一点故障都是通过整体切换来提供持续服务的. 但是单讲实例冗余的情况下, 也有一种思路是将服务实例同底层数据分开. 这里有两种截然不同的场景, 却在底层思路上有着共同点.
首先是非常古早的传统RDB高可用场景, 高端, 昂贵, 臃肿. 以IBM DB2 HACMP高可用架构为例.
传统高端RDB其数据并不存放在服务器本地盘中, 而是通过SAN网络存储于独立硬件存储设备中, 可以看做某种意义上的计算与存储分离, 因此具备同一份存储数据被多个数据库实例同时访问的前提. 这样的话, 实例冗余就是简单的两个主机连接同一份SAN数据, 一个主机实例挂掉, 另外一个主机实例接管物理意义上的相同数据, 所以叫数据共享模式. 这个模式基本已成明日黄花, 短期内不太可能有较大发展和广泛运用, HACMP架构的细节我们不会在下一章展开讨论. 但是需要强调的是, 该方案由于种种背景原因, 其可靠性是非常非常靠谱的, 功能并不是其被淘汰的原因.
该方案中多个冗余实例只能共享磁盘文件, 但是计算机为了高效IO, 所有被访问数据都会有内存镜像, 而两台服务器的内存无法共享, 如果两个实例都开放读写, 会存在内存数据不一致, 进而磁盘数据冲突的问题, 会彻底破坏数据库ACID底线. 因此虽然每台小机都价格不菲, 但是很遗憾, 平时只有一台提供线上读写, 另外一台只能闲着. 这点也是古早shard data模式同shard everything模式技术上有代差的标志.
接下来是当代, 在真正计算存储分离架构下的shard data模式. 以最常见的HBase为例, HBase的服务实例被称为RegionServer, 作为分布式集群, 多个RS共享同一个HDFS存储服务, 为了避免多个RS修改同一份数据的造成的数据冲突风险, HBase将逻辑数据通过range为维度拆分为大量独立region段, 然后将region段分配给特定的RS提供读写, 这样一来, 一个RS实例实际上只能读写一部分独立的数据. 当某个RS实例发生故障, 只需要将故障节点上本来负责的region段分配给其他RS, 且保证一个region只由一个RS读写, 就能做到RS故障后较快恢复整体可读写的目的. 在HBase集群中, 所有RS实例实际上都相当于其他任意RS实例的冗余, 我们把切换过程成为region move.
该模式是在共享HDFS数据的前提下实现的, 所以也算shard data. 其局限性也很明显了, 由于RS只能读写部分数据, HBase难以实现全局事务, NoSQL也有这一层的含义.
随着技术发展, 人们的预期也在提高, 有人就是希望既要存储计算分离, 共享存储, 又要支持全局事务, 全局读写相同数据, 让实例层实现"无状态"化. TiDB就是在这一挑战目标下诞生的NewSQL. TiDB存储层TiKV完全独立, 对外提供高可用和分布式扩缩容能力. 而作为数据库服务实例的TiDB间互相紧密通信, 通过事务协调机制来保证多个实例访问同一份数据的一致性. TiDB实例某种意义上可以看做无状态, 该模式下任意实例都是其他所有实例的冗余, 简单切换访问流量就好, 连类似region move的元数据改动都不需要, 是真正完全的shard data.
但是并没有什么外星黑科技让TiDB完美无暇, 实际上TiDB多实例间的事务协调机制除了raft外, 就是非常传统的乐观锁, 并不能解决并发访问造成数据冲突的问题, 而是通过锁来阻止这类冲突, 避免并发提交, 乐观锁并不是一种普适的数据库并发控制手段, 因此该方案的缺点就是非常挑业务场景, 一些并发更新热点数据的场景下, 乐观锁带来的更新成功, 提交失败问题是相当致命的, 可以说是TiDB的最大软肋.
另外多说一下, 分布式数据库技术, 不管存储是否分离, 其实例冗余都是有显著共性的, 比如Cassandra等等, 这里不再具体展开.
1.3.3. shard everything
终于轮到数据库领域最接近黑科技的方案登场了. Oracle RAC, shard everything, 虽然不太可能再次大范围推广, 但是谈到实例高可用就不得不提它.
shard everything没有第二个例子可举, 相当于RAC(real available cluster)的trade mark. 我们之前提到了, 共享数据模式下, 实例不能多活是因为内存不共享, 所以冗余实例只能冷备, 一活一备. 那么现在共享内存的多活冗余就来了. Oracle RAC架构下多个Oracle服务器和实例间共享一份SAN存储数据, 并且通过网络连接做到了访问内存对象的全局漂移实现共享, 这个网络可以是TCP网络, 也可以使用RDS协议, InfiniBand等交换设备提高跨实例内存对象共享的性能. 用户接入也可以无状态, 实例在共享数据的同时, 实现任意冗余互备和资源充分利用.
要说和TiDB的最主要差别, 就是对于冲突数据的处理上从粗暴的乐观锁重试, 变成了效率极高的悲观锁等待, 解决了事务提交失败的缺陷, 一定规模下性能上不会比单实例锁等待差太多. 【 @Ed Huang 提示, TiDB 3.0 已经支持悲观锁. 悲观锁实现大大降低了单行记录并发更新场景下事务失败的概率, 让TiDB看上去更像一个标准的数据库, 即分布式数据库获得了传统数据库的业务功能，当然该特性的成熟度还需要业务来验证. 】
shard everything的缺陷嘛…那就是性价比了. 虽然比HACMP那套好不少, 广泛作为冷备冗余的换代产品, 保证实例冗余的同时, 还兼具硬件水平扩展的功能. 但是硬件和基建以及服务费投入摆在那里, 一方面现代互联网应用通常会在钱和好用中间取一个折衷, 另外一方面RAC的内存共享毕竟是通过对象漂移实现的, 节点越多开销增加的风险也越大, 线性扩展性远不能满足海量应用的需求, 因此这一方案目前使用场景就比较集中, 并不广泛.
未完待续
推荐阅读：
- 网易杭研总结：数据库高可用技术之道（1）
- 网易杭研总结：数据库高可用技术之道（2）
- MySQL Group Replication在网易使用和优化实践
- MySQL/InnoDB数据克隆插件(clone plugin)实现剖析
- 如何建设中台？中台建设的组织、支撑技术和方法论
扫一扫
4339
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
