a)大的故障分层,从底层到上层: 存储设备、数据库、数据库计算节点、应用节点、接入层网络、汇聚及核心层网络、LTM本地负载、GTM全局负载、数据中心路由等各功能层都要测试其单点和整体功能失效情况,当然测试的时候一个CASE可以覆盖多个分支。
b)数据库功能层:
ADG 无GAP正常切换、有GAP可以修复场合下的切换、有GAP不可修复场合下的切换等。
首先,所谓非计划内的切换也分为很多种场合,例如数据可修复以及不可修复的场合,DNS切换过程是否对于全部应用都奏效,DNS缓存机制如何设计?这个需要针对自己的架构再仔细考虑考虑。
接着,我们来谈数据丢失的场合。架设日志有GAP,但是不可修复,最终强制切换成功的情况下:
数据库界定数据的唯一方式就是事务的时间戳,ADG只能从日志GAP的事务ID顺序来判断数据丢失的时间戳信息,通过时间戳信息可以转换为数据库节点的时间点。应用判断业务完整性是靠应用的事务性和应用执行的时间点信息。如果两个时间点信息一致,那么结合应用事务的完整性就可以判断不同业务数据的RPO。具体通过什么方式达到时间信息的完全一致性,可能会涉及多个方面,需要根据自己的架构综合考虑NTP、RAC MTSS、应用取时机制及事务机制等等,总而言之要保障这几个时间机制最终能达到一致,这样才能将RPO定位到业务上,后续无论是补录还是其他方式都有业务根据可依。