在灾备演练过程中，如何既能保证业务RTO要求又符合行业监管呢？云和恩墨近期在某银行灾备切换项目测试中，给出了答案。

某银行自成立以来，积极探索中小银行改革发展和特色化经营之路，目前已经建立了灾备中心，基本满足灾备基础设施建设能力规范，但数据库真实业务接管演练的能力尚不具备。之所以不会轻易对数据库进行真实切换，原因主要有以下几点：

1、数据库架构多样复杂：RAC、DG、多从级联、并联等增加了数据库真实切换管理的难度。

2、数据一致性要求高：数据异地传输时受网络延时、带宽、主备数据中心距离等条件限制，易引起数据库数据不一致，从而导致切换失败；若切换失败，复杂的数据库架构会导致问题定位困难，直接影响生产数据库的运行，造成业务中断。

3、真实切换数据库后需要将接管业务期间的真实交易数据反向复制到生产中心，增加了切换的挑战。

4、数据库灾备切换依靠DBA手动或者脚本完成，面对数量庞大的切换任务，切换RTO、成功率难有保障。

因此，该银行大多采用模拟演练的方式进行数据库灾备切换。具体来说，模拟演练首先中断复制关系，启动灾备环境系统验证数据是否可用，再利用系统模拟业务操作的方式来验证灾备切换体系的可用性。通过选择部分网点接入灾备中心系统环境中，业务人员进行操作模拟真实交易进行验证，待验证结束后，删除模拟交易数据，恢复主备复制关系。

数据库模拟演练切换示意图

事实上，一般的模拟演练数据环境在无保护状态下，业务人员操作模拟数据存在极大风险隐患。其次，模拟演练无灾备体系真实接管业务的系统性能压力，也没有真实业务接管的复杂事务状态。最后，模拟演练不能保存模拟交易数据，恢复复制关系前不需要同步数据至生产中心，因此也无法验证灾备中心真实交易发生后进行生产回切，保留真实交易数据的过程。由此可见，模拟演练难以完全替代真实业务接管的灾备演练。

面对上述情况，云和恩墨开发的zCloud混合数据库云管平台不仅支持桌面演练（即模拟演练），还支持两地三中心、三地五中心、主从级联、并联等复杂架构的真实业务接管切换，满足各种复杂应用架构场景。在本次该银行的项目测试中，zCloud实现了真实业务接管的灾备演练，并且在整个切换过程中，清晰完整地展现了各步骤的状态。

首先将数据进行初始全备份后，在灾备中心新建演练任务，选择将Oracle DG一主多备架构切换为主-备-备级联架构，确认配置信息后，后台自动执行switchover。经过几分钟的执行，完成选择备库的主备switchover切换，最终形成新的主备级联容灾架构并且主-备-备级联同步正常，在主库写数据可实时同步到备库。

通过zCloud的批量切换演练功能，可选择switchover切换后的架构，批量设置切换演练的主库以及机房下可用作切换的多个备库，后台正常执行后完成选择备库的主备switchover切换，新的一主多从容灾架构完成。此外，在多备库间均开启实时日志应用，主备数据正常同步，在主库写入数据不切换日志组状态也实时同步到各个备库，保证了真实业务接管切换演练场景下，切换前后的数据一致性。

zCloud的自动化操作更是减少了人为操作导致的故障，避免了风险隐患，缩短了业务RTO，符合银行业监管要求。

Switchover切换自动化操作流程

根据银保监会要求，2021年底中小型银行机构所有重要信息系统必须经过一次真实接管业务能力的切换演练，而且要保证切换后稳定运行一段时间，建议在灾备中心验证24小时，且完成跑批后进行回切。然而，当前国内大多数中小银行均采用模拟切换演练的方式，距离银保监会的要求还有一定差距。

云和恩墨作为业界领先的智能数据技术提供商，凭借数百位DBA服务银行客户的丰富容灾经验，已经实现了多家银行客户的数十套系统的切换测试和上线，包含数百台主机、上千个应用，每年支持百余次/套灾备切换演练和千余次桌面演练。zCloud可满足中小型银行在机房搬迁改造、设备维修扩容、灾备演练等场景下稳定、可靠、批量、快速切换的实际业务需求，自动校验同步数据的完整性，简化应急演练流程，提高业务连续性保障。此外，zCloud最新的3.0版本中实现了服务化、智能化的数据库全生命周期管理，是目前业界支持数据库品类最多、提供的功能模块最全的数据库云管平台。