数据库高可用 | 行业巨头不告诉你的“零停机”秘密!

高可用是数据库系统的基本需求，也是数据库技术实现的难点之一。但对于有些行业来说，“零停机”，是刚需！

比如半导体行业，停机哪怕一分钟都可能造成高达数万美元的直接经济损失；比如航空业，航班调度系统一旦出现故障，成千上万的旅客行程将受到影响，航空公司可能要面临天文数字的赔偿；再比如医疗行业，停机可能直接关系着患者的生命安全！

那么，支撑这些尖端产业的数据库是如何实现近乎神话般的“零停机”的呢？

要理解这一奇迹背后的奥秘，我们必须首先识别并解决影响数据库可靠性的几个常见问题：

问题1：数据库高可用架构以及灾备架构不完善

问题2：数据库运行性能及稳定性问题

问题3：故障应急处理缺乏规范流程和方案

问题4：缺少高效运维体系

问题5：缺少主动式隐患梳理及预防

......

针对这些普遍问题，中亦科技经过多年技术与经验积累，总结出以下关键点！

高可用架构与灾备

坚固基石，方能抵御风暴

许多企业的数据库高可用架构及灾备体系并不完善。为了解决这一问题，我们可以根据业务系统的重要性，将其分为几个不同的等级，并为每个等级量身定制相应的高可用架构及灾备方案。

其中核心系统属于A类系统。A/B/C/D类业务系统生产端数据库的架构都是RAC集群，区别为是否配置了ADG,是采用小型机还是X86，是在一套集群上部署一套还是两套数据库。分类之后再进行核心业务系统和核心系统除外的灾备架构和实现方式。

核心业务系统高可用架构图

数据库补丁管理

精准施策，防范未然

适时地进行补丁分析与升级至关重要。当遇到新版本操作系统或数据库安装、季度PSU补丁发布等情况时，就需要进行详尽的补丁分析，以避免潜在问题。这一过程不仅需要精确的分析策略，还需要完善的补丁升级计划，确保数据库始终保持在最佳状态。

那么，什么时候需要做补丁分析？

以Oracle数据库为例，当出现下列情况时，需要考虑做补丁分析：

1. 在目标版本的操作系统上安装数据库，为了避免目标版本的OS出现BUG需要分析OS需要安装哪些补丁。
2. 安装目标版本的数据库，为了避免新安装数据库出现严重BUG，需要数据库应该安装哪个patchset、哪个PSU补丁及小补丁。
3. 随着ORACLE季度PSU补丁的发布，需要关注新补丁的分布并对严重性分类，需要做补丁分析，这样，已有数据库可以根据升级策略提前升级补丁以预防潜在问题。
4. 当已有数据库出现严重BUG，考虑安装补丁时，具体需要安装哪个PSU补丁。

数据库最佳实践

细节决定成败

基于多年服务经验，我们总结了一系列最佳实践，覆盖操作系统配置、ASM参数调整、数据库参数优化等多个方面。通过这些精心设计的策略，我们能够有效消除系统运行中的隐患，确保数据库的稳健运行。

数据库高可用测试

实战检验，确保万无一失

在数据库系统上线前，进行全面的高可用测试至关重要。这包括但不限于服务器单节点故障、网络故障、心跳网络故障等场景。通过预先设定的测试案例，我们可以验证系统在面对各种极端条件下的表现，确保其能够在实际应用中保持高度的可靠性和稳定性。

对RAC集群高可用架构和容灾能力进行测试，主要包含以下几个场景：

服务器单节点故障：服务器发生故障重启是运行期间常见的问题之一，硬件故障，网络故障，参数配置错误等都可能导致服务器不稳定或者宕机；一旦服务器硬件出现故障，数据库随之也会受到影响，可能会导致数据库重启或者关闭。针对这些情况，设计两个测试用例分别模拟单节点手动重启服务器和异常宕机时的情景。

服务网络故障：本次预设的生产环境是双公网网卡和双私网网卡的rac环境，其中每组网卡都分为主网卡和备网卡，当公网主网卡出现故障后系统会自动切换到备网卡继续运行，理论上这个切换的过程会非常短、不会对业务产生影响；同时，因为数据库正常运行时不会用到备网卡，如果是备网卡发生故障业务也不会受到影响。当公网双网卡同时发生故障时，服务器将无法对外开放。

心跳网络故障：本次预设的生产环境是双公网网卡和双私网网卡的rac环境，其中每组网卡都分为主网卡和备网卡，当公网主网卡出现故障后系统会自动切换到备网卡继续运行，理论上这个切换的过程会非常短、不会对业务产生影响；同时，因为数据库正常运行时不会用到备网卡，如果是备网卡发生故障业务也不会受到影响。当私网双网卡同时发生故障时，如果较短时间就恢复，集群层面不会出现异常，若超过了misscount时间集群会出现脑裂现象。

服务器单节点HANG故障：服务器运行期间由于硬件或软件异常原因都有可能导致节点HANG死。操作系统因CPU、内存耗尽或BUG，OS挂起，无法响应数据库。针对这些情况，分别设计0S无法响应、cluster软件关键进程无响应、cluster软件关键进程异常终止、database软件关键进程无响应、database软件关键进程异常终止、业务作业进程无响应等6个大的场景进行测试。

操作人员操作失误：实际环境中，有可能存在操作人员误操作导致数据丢失，本次场景分闪回查询表、延迟闪回adg三个测试用例来分别模拟恢复数据。

除此之外还将对san网络故障、软件升级、HBA卡升级等场景进行测试。

运维体系建设

预防为主，应对为辅

构建全面的运维体系是保障数据库长期稳定运行的基础。这包括制定详细的预防策略、建立完善的监控机制、提供详尽的手册指南以及系统的培训支持。通过主动预防而非被动应对，我们能够显著降低系统故障率，提高整体服务质量。

运维体系建设关系到数据库系统的持续稳定运行，主要内容如下：

1. 制定预防未来可能导致性能不稳定的统计信息策略并实施，数据存放策略标准；
2. 提供数据库监控指标体系和具体实现方式；
3. 制定数据库备份恢复策略；
4. 提供数据库变更手册、应急手册和维护手册；
5. 提供系统性的培训和指导，为客户后续的深度自主运维奠定良好的人才基础。
6. ... ...

为了提升业务连续性和用户体验，提升系统可用性、稳定性、安全性，全面提升运维质量，我们还会制定了数据库运维体系说明手册，用以指导数据库的日常运维工作。

Oracle运维体系的模型

主动式优化与问题梳理

防微杜渐，未雨绸缪

数据库运维和消防一样，永远都是“预防重于救火”，被动式的故障处理只能解决突发的问题，只有主动梳理及预防才能防患于未然，真正做到事半功倍！

中亦科技会从主动式分析和预防及基于开发运维最佳实践进行问题梳预防进行说明。主动对数据库运行情况进行性能监控，抓取性能表现不佳或扩展性不佳的SQL/PLSQL并进行主动分析，提交优化建议。通过梳理并预防潜在问题，我们能够提前发现并解决隐患，减少未来可能出现的问题数量。

在这个信息爆炸的时代，数据库的可靠性很关键。中亦科技一直在不断的总结项目经验，培养专业技术团队，完善服务体系，希望通过不断升级的数据库可靠性方案，提高数据库的可用性和稳定性！

如果您有数据库可靠性提升的需求，欢迎留言联系我们，我们的技术专家团队将竭诚为您服务。