数据库管理-第165期 数据库高可用漫谈（20240327）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
国内某科技公司 DBA总监
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家，OCM讲师
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭。

前几天，在首席群里讨论，某些人已经实现了在常去的城市都有房产了，出差都有自己的房住（当然有没有其他的目的就不得而知了）。相较于外出住酒店，两种方式各有优劣：

• 自有房产是自己的，住着安全放心
• 自有房产需要持续维护：平时需要打扫卫生，交物业费，装修家具等等
• 在不同城市的自有房产水平不同：房屋面积，装修家具水平，交通，周边等等
• 酒店不是自己的，可能有安全风险
• 酒店不需要持续投入，随到随住
• 酒店可以提供更多的选择
• …

上面的内容借用德哥今天公众号结尾的一句话“其实 这段内容（原文为： 这篇文章）的内容和标题是匹配的, 只是我还没想好到底有什么关联”。
数据库的高可用究竟是什么，我觉得还是得从实际需求场景来：

• 如果你的业务不允许中断，那么数据库的高可用目标就是能够持续提供数据库能力
• 如果你的业务允许短时间中断，那么数据库的高可用目标就是能够快速恢复拉起的能力
• 如果你的业务允许较长时间中断，那么数据库高可用的目标就是有办法能够恢复数据库即可
• 如果你的业务无关紧要，那么数据库高可用的目标就是…可以算没有目标

那么从我个人角度以尽可能高的要求来看看数据库的高可用。

1 主从架构

主从架构是我们用的比较多的高可用架构，除了上图MySQL Replication，Oracle有(Active) DataGuard，PostgreSQL也有类似的主从架构。主从架构的优点其实是架构简单，大多数主从架构除了可以实现异地的数据容灾以外，也可以提供读写分离的能力（即主写备读），提升数据库整体性能表现。
主从架构主要需要考虑的问题是在switchover或failover后，应用能够正确连接到正确角色的数据库上，在这一点上MySQL提供了MySQL Router，三方开源则有MHA和Orchestrator等；Oracle则有TAC和GDS等。

2 集群

这里说的集群要区分于分布式架构，主要涉及MySQL Group Replication（MGR）和Oracle RAC架构等。

这里的集群主要是在实例级别提供高可用，即集群内部分实例故障，不影响数据库提供服务。但在RAC架构中仍可能有存储的单点故障，因此存储侧也应该实现高可用。当然在集群之上也可以和主从架构配合使用，提供异地容灾能力。

3 分布式

无论是Redis、MongoDB还是大量的国产数据库，都提供了分布式数据库架构。

其实简单来看，就是每个分片内以主从或者副本的方式，分片每个节点可以在不同的地域，实现高可用。而数据库的访问接口则一般通过分布式集群本身来管理并提供服务。分布式架构中，只要不是某个分片的所有节点全挂的情况出现，理论上不会出现数据库异常。

4 误区

前两天一朋友的数据库通过主从架构上线实现了国产数据库的上线，本是一件好事，但是有些人却说，不是分布式，高可用不行啊。其实反观下整体架构，这些人为啥看不到，别人用1+1的节点解决了分布式需要10+台服务器才能解决的问题。不得不说，分布式数据库在高可用上看似非常美好，但是节点数量的提升带来的管理压力提升、元数据维护增加、网络压力增大等，而且分布式不一定适合所有应用场景产生的数据结构和业务场景（这里还不考虑业务代码变更）。

5 光是数据库？

举个栗子，数据库实现异地容灾，且前端应用可以自动连接到对应角色的实例。但是业务应用程序却只部署在了一个地方，那么如果这个地方整个IDC出现异常，那么前端业务同样不可能实现容灾切换，所以应用程序也需要多地部署。

总结

本期浅谈了一下数据库的高可用，我认为一切还是从需求出发，结合可接受成本来做高可用。
老规矩，知道写了些啥。