太长不看

数据库的高可用在技术上已经不是问题，目前落地的瓶颈主要在其高昂的硬件成本和管理成本。云平台为数据库提供近乎无限的标准资源，屏蔽实现细节，减少手动工作，极大的降低了数据库高可用的硬件成本和管理成本，使得数据库高可用为每个企业所用。

是什么在破坏数据库的可用性？

保障可用性需要的东西很粗暴：找出引发不可用故障的因素，并且消除之。下图是一个MySQL社区的调查，可以看出引发数据库故障的主要因素并不是地震火山机房爆炸，而是日常管理的疏忽。

图一 导致MySQL故障的主要因素

基本上，我们可以把故障来源分为三类：运行环境引发的，开发者引发的和数据库管理员引发的。提升可用性就是找出这三类故障并且设计对策。和其他软件一样，DB的可靠性工程（Reliability Engineering）不需要神秘的天启，也不依赖“数据库大神”，是每个IT团队都可以落地的。

云平台帮DB突破硬件的限制

运行环境（包括硬件）引发的故障主要来自四个方面：

1. 1. 数据库触及了硬件能力的上限，比如磁盘写满。

2. 2. 软件适配不同环境带来的复杂度，损害了软件本身的可靠性。

3. 3. 备份硬件的成本太高，迫使用户放弃备份。

4. 4. 硬件本身故障得不到及时处理。

而这几种故障，云平台都可以很好的缓解。

云消除数据库的资源限制

数据库开发者和DBA们花费了太多时间在管理硬件限制上了，不仅消耗了精力，而且也极容易隐藏错误。在云上，这种限制得到了大大的缓解，因为云提供的资源：

1. 1. 几乎无限：一个数据库几乎不太可能碰到云平台的资源上限。

2. 2. 即时可用：分配的资源即时到账，极大的降低对容量规划的要求。

3. 3. 用完就扔：用完的资源可以释放，释放后即停止付费。

4. 4. 自动分配：数据库可以调用API自行分配资源，而无需人工干预。

可以说，DBA领域臭名昭著的故障来源-磁盘空间不足-在云平台上已经解决了。用户可以用20G磁盘启动一个Serverless数据库，然后随着业务的变化，动态给磁盘扩容/缩容。考虑到阿里云EBS的上限是32TB，我认为99.99%用户不太可能触及磁盘容量上限。

有经验的读者会指出：即使云磁盘支持动态扩容，如果用户并不跟踪数据库的磁盘使用率，那么磁盘还是有被打爆的风险。

应对这种情况，云厂商进一步推出了Serverless数据库服务。Serverless数据库的用户把容量规划的工作完全委托给数据库软件。用户在启动数据库的时候，不指定CPU，不指定内存，只指定一个初始磁盘容量，所有的硬件资源都由数据库软件自行管理。

而分析型数据库Databend就更进一步，抛弃了块存储，使用对象存储（S），完全把存储管理交付给云厂商。

云为数据库提供标准化的硬件

维护过生产系统的朋友都知道，保持运行环境的一致性不仅可以降低管理成本，也是可用性建设的前提。但是开源软件（比如MySQL和PostgreSQL）的开发者并不能享受这种一致性。恰恰相反，他们要面对几乎无穷无尽的硬件组合：

1. 1. 包括X86，AMD64，ARM，RISC-V等不同的指令集。

2. 2. 包括机械硬盘，固态盘和SAN等不同的存储存储硬件。

3. 3. 包括Linux主要版本，Windows主要版本，FreeBSD等不同的OS内核。

4. 4. 包括Ubuntu，Amazon Linux，RedHat等不同的操作系统发行版。

5. 5. 包括XFS，ext4，Btrfs，NTFS等不同的文件系统格式。

这么多的硬件组合可能性，让代码变得非常繁琐。下图是MySQL 8.0.22版本关于线程亲和性的部分代码：

图二 MySQL 8.0.22版本关于线程亲和性的部分代码

因此，云厂家的云数据库天生有优势：他们可以选择一种硬件/操作系统/文件系统的组合，并且专注于为这一种组合写代码。

我们看到阿里云开辟了自己的MySQL分支AliSQL，AWS也基于MySQL做了自己的Aurora增强。两个分支都不需要适配自己IaaS所不提供的硬件，却可以针对自己的专属硬件（RMDA和Smart NIC）做有针对性的优化。长远来看，我相信他们的codebase和社区的会越来越远，最后成为拥有共同接口的三个独立数据库。

作为对比，MySQL的windows installer至今仍提供32位的，很难想象一个2023年还在使用32位机器的系统，怎么保障其可用性。

云为同城和异地容灾提供可负担的资源

两地三中心是一个很常见的高可用架构，但是多年以来，由于极为高昂的建设成本，这个架构基本停留在银行和其他大企业。一般来说，相对单数据中心，两地三中心会让基础设施的成本上升三道五倍，这是一般企业无法承受的。

而云平台的多区域极大的降低了两地三中心的部署和维护成本。在笔者的范例repo中，读者可以看到只需要几行terraform代码，用户就可以启动同城跨可用区的主从数据库，再用几行terraform代码，又可以启用远程备份数据功能。考虑到无状态的计算节点平时并不需要开启，两地三中心带来的额外成本实际上只有一个数据库副本的费用，是每一个企业都可以承担的。

实际上，云厂商们在这个基础上再走了一步，直接推出了各种Global Databases。

Cloud Spanner 为多区域实例提供了业界领先的高可用性 (99.999%)，停机时间比 99.99% 少 10 倍，并可跨区域和多区域配置提供透明的同步复制。

Amazon DynamoDB 全局表为大规模的全局应用程序提供快速的本地读写性能。全局表会在您选择的 AWS 区域中自动复制您的 DynamoDB 表。

可以想像得到，再过若干年，随着云平台和云数据库的普及，两地三中心会走出金融行业的私家园林，成为行业基本配置。

托管云服务能更快的处理硬件故障

DBA们都很熟悉下图这种故障

图三 磁盘失效导致的数据丢失故障

我的朋友冯老板主张《云数据库是个杀猪盘》，理由是云数据库的盘比他从华强北买的SSD盘贵很多倍，不过我相信大多数架构师都会赞同：如果花钱能提升存储层的可靠性，并且自动化硬盘失效的处理，那回是一笔非常，非常，非常划算的买卖。

毕竟，谁也不愿意被业内同行连续“呵呵”再“呵呵”。

云平台帮助DB抵挡来自开发者的攻击

关于数据库，有一个很尴尬的事实：虽然大家都同意数据库是IT系统的核心，但是大多数开发者其实不懂数据库，至少没有到让DBA放心的程度。

在大多数DBA眼里，应用开发者几乎是敌人，他们会不定时的用如下手段攻击DB：

1. 1. 胡乱选型，比如把大量图片塞进关系型数据库。

2. 2. 强行拿到DML和DDL高权限，然后误删数据，然后试图掩盖，然后恢复不了，然后躺平放弃，最后跪求DBA恢复数据。

云提供更多的数据库服务供选择

正如鲁迅所说“正确的选型时数据库高可用的第一步”。如果有人硬要把海量图片塞进MySQL，可用性是没办法维持的。反之，只要把监控数据从MySQL移到时序数据库去，可用性自然就提升一个档次。

图四 迅哥儿总是对的

大多数架构师当然知道One size fits all不可行，但是他们仍然把所有数据都塞进关系型数据库，为什么呢？

一个重要原因是维护NoSQL数据库的成本过高。如果你同事安装个MongoDB都费了半条命，那么把文档数据塞进MySQL是你能做出的最佳选择。

在这种窘境下，云厂商提供的广泛的数据库服务就非常有价值了。随便打开一个主流云厂家的控制台，你都可以找到一个非常长的数据库产品清单，覆盖了各种OLTP， OLAP，KV，时序数据库，图数据库，文档数据库。基本上，使用Console的默认配置，十来分钟就能启动一个合适的数据库实例。对于急于PoC做验证的架构师来说，这一点太有价值了。

云平台缩短恢复数据的时间

如图1所示，开发者的DROP TABLE仍然是数据库故障的不小来源。实际上，DROP TABLE只是极端例子，更多的故障来自应用开发者对生产数据库的错误更新。要降低此类故障，我们可以事先预防和事后补救。

先按下事前预防不表，事后补救碰到的挑战有二：

1. 1. 怎么保证备份文件（binlog/WAL）存在并且可用？

2. 2. 怎么快速的从备份文件恢复数据？

保证数据有备份

对于第一个问题，很多管理者的解决方案是“建立流程规范，定时巡检，强化责任心，加强员工教育”，这种高姿态固然没错，但是它们实际上有意无意的忽视了一个问题：数据库备份实在太繁琐太容易出错了。

有心的读者可以读一下《分享几个数据库备份脚本》。可以看到，大多数从业者还在自行撰写shell脚本备份数据库，并且使用crontab来编排任务。文中分享的脚本，没有单元测试/集成测试，也没有代码版本管理，工程质量完全随缘。只要有一个变量写错了，很可能脚本就是在空转，搞得不好用户会在需要的时候发现一年来备份了365个空文件。

这时候，云平台的优势就比较明显了。用terraform的话，启动周期性备份只需要一行代码：

如果需要异地备份，需要多一点：

缩短数据恢复时间

可用性的Time to recovery这个指标非常关键，故障越快恢复则系统可用性损失越小。从笔者的观察看，即使数据库有备份，大多数团队的恢复过程也不是很理想。

有心的读者可以读一下《如何使用Python对MySQL的误操作快速恢复数据？(建议收藏)》和《MySQL误删数据？快速恢复指南来了！》。可以看到，恢复步骤十分繁琐，而且操作者需要有Linux机器权限，需要知道具体的备份文件格式，甚至需要分辨究竟是用mysql-bin.000001 还是mysql-bin.000002文件。

这个事是如此的繁琐，以至于用户需要接受专门的培训：《「专业培训」PostgreSQ备份与恢复实战》。

软件工程的一个定理：一个流程步骤越多，know how要求越高，则越容易出错。数据库故障一般伴随重大压力，只要操作者稍微惊慌一下，就可能出错，搞得不好没恢复数据反而把备份文件给删了。

那么在云上，PITR是怎么做的呢？以AWS为例：

1. 1. 选择要恢复的时间点

可以看出，云平台屏蔽了各种实现细节，只向用户询问恢复时间点这一个信息，用户出错的概率就大大降低了。

其他云平台的服务大致差不多，如果您云厂商不能提供这个服务，而是要求您用pg_restore或者mysqlbinlog直接操作备份文件，建议您向厂家的CTO投诉。

云平台降低管理不当引起的故障

云规范了数据库的版本

软件版本升级是一个很消耗精力的工作，几乎没有人喜欢这项工作，但是对于企业来说，这是IT运营中很重要的一个工作。甚至可以说，软件版本的更新速度是企业IT团队工程成熟度的一个重要指标。

相对于操作系统和其他软件，数据库版本的更新速度非常，非常，非常的落后。

根据《全球共有多少MySQL实例在运行？这里有一份数据》，在2022年5月31日，也就是MySQL社区终止5.6的技术支持一年两个月之后，全球仍然有30%的MySQL实例是这个版本，换句话说，30%的用户在使用一个不再打安全补丁的过时数据库。

而再过五个月，5.7也将EOL了，到时候现存46%的MySQL 5.7实例升级比例会是多少？恐怕不容乐观。

云平台的优势在于，它能从源头上控制供给的版本数量，同时又能通过自动升级控制最终部署的版本数量。可以负责任的预测，在五个月之后，上台面的云厂商就不会再提供MySQL 5.7版本，而且会提供工具帮助客户升级到MySQL 8.X。

云平台控制DB管理权限

当大多数DBA严格控制开发者权限的时候，他们对自己的权限管理却是很粗放的。

下面是《人间悲剧！新来的小仙女在客户生产环境执行rm -rf，整个数据库都没了，我很慌》分享的一个故障，明显可以看出新DBA的权限过大。

图八 新手DBA拿到Root权限引发故障（顺便说一句，原文的性别歧视非常不合适，故障和性别无关）

对于此类故障，云数据库可以在几个角度予以帮助。

1. 1. 直接拒绝用户访问RDS所在主机，从根源上杜绝误删的可能性。

2. 2. 帮助用户轻松配置访问控制角色，给不同的DBA赋予不同的权限。

以阿里云为例，用户可以通过访问控制RAM服务，给上述新手DBA配置如下权限

这个策略将

1. 1. 拒绝该用户对生产DB实例的任何访问。

2. 2. 拒绝该用户删除预发布环境的DB备份。

3. 3. 允许除此之外的其他DB管理面操作。

云平台帮助检查不当配置

上文我主张云平台降低了数据库备份的繁琐程度，有朋友会自然的问：“你降低备份配置门槛很好，可是我又怎么确保我的同事们都开启备份了呢？数据库备份的难题不在技术，而在管理成本。”

这是个好问题，实际上云平台也有答案。AWS Config服务有内置规则db-instance-backup-enabled，可以帮助企业巡查指定的数据库（比如指定生产环境）是否配置了备份，如果发现未备份的数据库，则可以告警。AWS Config是一个持续检查的服务，所以你不需要定期半年做一次《数据库配置健康度专项行动》。

同理，还有一个rds-multi-az-support规则，则可以自动巡查你的数据库是否开启了多AZ容灾能力。

国内使用的话，阿里云对应的服务叫做配置审计，对应规则叫RDS实例开启日志备份。我没能在腾讯云和华为云找到对应服务，有知道的读者欢迎您留言。

总结

即使作为一个云计算的狂热粉丝，我也要承认目前云数据库的技术突破并不是很多，总体而言，仍然是托管开源数据库的阶段。这也是很多同行并不是很服气的原因之一。但是，话说回来，绝大多数企业提升数据库可用性的瓶颈并不在技术层，而是在巨大的管理成本。而云平台提供的工具确实能降低管理成本，让高可用数据库变成企业标配。

参考资料

致谢

在上述参考资料作者之外，我还要特别感谢：

1. 1. 接受我技术采访的A云厂家专业技术人士

2. 2. 在各个微信群和我抬杠的DBA同行

3. 3. 以及耐心回答我各种问题的ChatGPT