数据库管理-第233期 数据库的高可用（20240822）

数据库管理-第233期 数据库的高可用（20240822）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，HaloDB外聘技术顾问，OceanBase观察团成员，青学会MOP技术社区（青年数据库学习互助会）技术顾问
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

首先通报了下行程，今天在帝都参加2024DTCC。其次呢，这是一篇MOP社区邀稿，主要是针对上周四MOP社区数据库高可用的直播做个总结，也顺便蹭蹭本周一个热点。当然本期还是针对数据库，也不针对任何产品与技术。

1 高可用的目标

高可用的概念，其实可以很复杂，用一大堆专业术语，加上数不清的9，最终实现架构的高大上。但是对于我来说，或者说对于支撑业务的使用者来说，高可用的目标却是很简单，即数据库任意节点的故障不影响承载业务的运行。那么实现这一目的数据库一般的解决方案有：

1. 主备：一主一备or一主多备，主备间实时同步（可能存在部分备节点异步同步），一般主节点可读可写，备节点只读。备节点故障不影响使用；主节点故障需要将可用备节点提升为主节点（这里一般需要一个判定和切换时间）。
2. 多活：这里一般是采用副本模式，每个节点都是可读可写的（这里一般会用到Paxos或者Raft协议来实现一致性和性能之间的平衡）。任意节点故障不影响其他节点运行。

以上两种方式可直接用于传统的集中式数据库，也可以用于分布式数据库的某个分片。

2 基础架构

本周的大事，让我有了一点思考，就是数据库运行的基础架构是不是应该多元化：

• 公有云：公有云确实可以提供一站式解决方案，也有一定的动态扩缩容能力，使用便捷。但是对于客户来说，其高可用并不是那么透明，而且如果云的基础架构出现问题后，客户只能等云厂商解决问题
• 私有云：私有云（我认为也包含虚拟化），相较于公有云就是使用、搭建、维护有一定门槛，高可用设计与实施需要自己来实现，出现问题也需要自己处理
• 裸金属：直接在服务器上安装操作系统并安装数据库使用，非常传统且“落后”方式，高可用解决方案依托于数据库提供的解决方案。如果是操作系统和数据库出现故障需要自己处理，而更多的问题主要出现在硬件层面。当然，很多地方会吐槽硬件资源利用率的问题，这个下一节再讲。

我的思考是，近几年在全球范围内出现了多次某家公有云大规模故障的情况，公有云的基础架构也不是那么的健壮；私有云则有一定的上手门槛，设计、实施投入可能会比较庞大。所以在很多关键业务上，我们会看到多云架构和混合云架构，但是公有云之间的壁垒以及云上云下的阻碍。当然很多时候一些高负载业务还得在裸金属服务器上运行。

3 预留

举个栗子，一个高负载的三副本的数据库（不考虑是集中式还是分布式），每个节点的CPU占用率一般介于40-50%之间，如果某个节点出现异常，其余两个节点大概率是无法接管（这里可以回看我写CPU那几篇文章），这个副本很可能会比较卡。这种情况其实是没有实现高可用的目标的，即便是云上可以动态扩容，但是新的节点如果还需要重新同步数据，则比较麻烦。
这个场景也就是很多重点系统的数据库要求CPU占用率不能太高的重要原因之一。

总结

本期简单扯了一下数据库高可用相关的一些事情。
老规矩，不知道写了些啥。