数据库管理-第340期 高可用，不止数据库（20240620）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner
10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

前天晚上和一位大厂老大哥聊了大概半小时的数据库高可用方案，总是是一些在我看来比较“脑残”的方案，主要是为了实现RPO=0（RTO就不存在了）。探讨过程中突然聊到了，如果数据库挂了，应用连续性怎么解决。

1 数据库RPO

RPO，灾难恢复时允许的最大数据丢失时间，简单来说就是数据库故障时，会丢多少数据。对于数据库本身通过主备/副本方式实现高可用和RPO=0这里就不作具体探讨了，本期主要想要探讨的是，数据库挂了，应用到数据库的连接肯定会丢失，而正在处理的数据要怎么保证，是否可以将操作自动转移到正常节点。在确保数据库已入库数据不丢失的情况下，实现应用不中断不丢任何还未入库的数据。

2 负载均衡

在很多数据库的架构中，都会自带负载均衡或者要求在数据库连接前端增加负载均衡。对于数据库自带的负载均衡往往功能会更加强大：

• 可以更加敏感且明确的判断节点运行状态，判断其是否真正可用，避免连接被分发到不可用节点
• 对数据库本身负载更加明确，可以更好的分发数据库请求
• 可以判断数据库节点的角色，实现一定程度的故障转移

而外部的负载均衡在上面这些方面上就会稍微差一点。无论是哪种负载均衡都也要考虑以下一些特殊情况：

• 节点假死
  在生产中我们是遇到过节点本身已经处于不可用的状态（如IO卡死），但是节点本身还可以做出一定程度的响应（比如内存中进程/线程还存活），导致上层负载均衡/管理监控等对该节点实际状态产生误判，这种情况往往需要人为介入关闭/重启节点或者中断网络。当然遇到这种情况也可以使用更加复杂的方式对节点状态进行判断，比如定期执行探活SQL来判断节点真实状态，但可能增加性能消耗
• 跨集群
  如果不同的集群承载了不同的角色，当主集群异常，如何快速甚至是自动将连接切换到备集群是一件相对复杂的事情，一般来说不同的集群，其内部连接分发是独立的，这往往需要在数据库上层单独创建一套连接管理服务抑或是在应用程序中使用高级数据库连接方式来判断数据库连接。如果有异地容灾，网络环境更加复杂，需要做的事情也更多

3 连接转移

如何将故障节点的连接以不中断的方式转移到正常节点，这点是很难的，一般来说无论以何种方式实现的数据库高可用，数据库故障导致连接中断之后应用一般都会报错，当前的数据库操作会中断，这种情况下往往需要通过重试机制来重连数据库进行操作。在某些情况下，比如未配置重试机制、积压操作太多、应用配置等原因，应用会挂掉，需要人为介入处理，这期间可能会丢掉部分在途的数据。
Oracle可以通过TAC来实现数据库连接的自动转移，即数据库在出现异常时会通知应用连接进行切换转移，应用的数据操作不会报错中断，具体内容可以查看《 数据库管理-第220期 Oracle的高可用-03（20240715）》和《 数据库管理-第221期 Oracle的高可用-04（20240717）》。类似的功能目前还没有在国产数据库上看到，希望跟进。

总结

本期感觉又写的乱糟糟的，我希望在数据库高可用RPO=0的基础上，应用对数据库变化无感，不丢任何在途数据。
老规矩，不知道写了些啥。