1 引言
2 双活架构
2.1 ORACLE篇
ORACLE常规架构
1：数据集群本身，采用高可用的RAC架构，默认IDC数据库支持读写操作，双活IDC数据库只支持读操作；
2：常规情况下，双活IDC数据库还承担LDR、ADG、温备等角色；
3：常规情况下，默认IDC和双活IDC的应用全部连接默认IDC的数据库；
4：常规情况下，默认IDC的数据会通过Dataguard的方式把数据同步到双活IDC的数据库中；
5：应用通过域名（通过域名对应用进行数据库切换）方式连接数据库，不能使用IP方式进行连接；
常规架构
1：应用全部连接Mysql集群的Master节点，支持读写操作；
2：Slave节点支持只读操作；
3：当Master出现故障，MHA会自动识别，并把一个Slave节点提升为Master节点；
4：MHA本身的高可用由MHA Manager(Backup)来支持，MHA Manager(主)挂了后，需要启动备用 MHA Manager来工作；
5：切换到同IDC-A的Slave1支持自动主从切换，跨IDC-B的Slave2节点不支持自动主从切换，如果IDC-A出现故障，需要手工将IDC-B的节点手工启用，并切换为Master，并修改域名DNS解析；
1：IDC级别的容灾切换，需要手工切换Mysql Master节点，也就是把原来IDC-B的Slave切换为Mater节点，并切换DNS解析到IDC-B这边；
2：由于是主从复制的架构，当半同步降级时发生主从切换会有少量数据丢失;
1、数据库同步时效指标：Oracle/MySQL数据库规范约定，RPO同城小于5分钟，跨中心小于15分钟。
2、跨数据中心的切换时效指标：跟应用系统RPO关联。
5、跨数据中心切换的方法：
一是通过自动工具自动探测，结合日志等进行自动切换；
二是授权值班同事，人工一键触发切换操作。
目前切换需要人工确认。
6、切换之后应用系统的操作：需要应用系统评估，建议应用系统结合日志、监控、工具等给出切换的过程和切换的影响的报告，根据报告和指标确定后续具体处理操作。
7、切换对应用系统的要求：
修改为使用域名对接数据库；
需要应用系统支持幂等；
切换时效需要关注DNS Cache缓存（默认1分钟刷新）的问题
应用系统连接数据库需要有超时机制，在DB出错的情况下，进行重连。
要求每个应用系统都在测试环境进行切换模拟测试，观察表现；
8、数据库故障切换测试：
可由测试负责人和DBA测试接口人（段义强、刘雪峰）讨论切换测试步骤和方案，按照方案进行执行。
分不同的测试场景：
1）网络故障&恢复：网络恢复自动就会恢复，连接池会重建连接。
2）数据库实例故障&恢复：如Oracle RAC架构，DBA直接进行切换即可，连接池会重建连接。
3）存储故障&恢复： 涉及到数据库一致性问题，应用系统需要关注并确认数据一致性问题。
9、大事务的同步时延问题：
原则上不允许出现大事务，需要应用系统改造，可通过代码分析以及联系DBA确认是否有大事务存在。
10、切换的方法和流程：操作上会提供切换工具。流程上：
11、切换从库后主库恢复正常是否切换回原主库，需要具体分析
12、数据库连接池的配置
建议推荐使用druid，按内部架构给的连接池配置参数进行配置，这样配合域名DNS解析切换以便达到自动重连的目的；
应用系统要根据应用的SQL复杂度以及应用之间接口的超时合理配置超时参数
主要超时参数说明如下：
connectTimeout：连接超时，配置在url上，默认30s：
示例：jdbc:mysql://xxx.xx.xx.xxx:3306/xxx?connectTimeout=1000，单位s
socketTimeout：读取超时时间，配置在url，默认无，不超时：
示例：jdbc:mysql://xxx.xx.xx.xxx:3306/xxx?socketTimeout=60000，单位ms
loginTimeout：登录超时事件，配置在properties中，默认0，不超时：
示例：loginTimeout=2，单位s
maxWait：获取数据库连接最大等待时间，配置在properties中，默认-1，不超时：
示例：maxWait=3000，单位ms
queryTimeout：查询SQL超时时间，默认无，单位s，按需配置：
1、在连接池中设置：queryTimeout，优先级 3
2、在mybatis配置文件设置默认值:defaultStatementTimeout优先级 2
3、在mybatis mapper文件中对每一个sql方法设置timeout值 ，优先级 1
4、在JDBC Statement设置 setQueryTimeout ，优先级 1
transactionQueryTimeout：事务中操作SQL超时，默认无，按需配置：
示例：transactionQueryTimeout=10 ，单位s
5 问题和挑战
1 容灾切换时，域名DNS解析延迟：IDC-A与IDC-B连接数据库时，无论是oracle还是mysql都推荐适用域名进行连接，当发送容灾切换时，DNS解析对于应用是有延迟的，所以在切换时需要注意生效的时间是否能满足应用的要求
2 数据一致性：Oracle使用的是Dataguard同步数据，Mysql使用主从复制的方式同步数据（半同步，异步），双活IDC数据库节点会出现数据一致性问题，这个需要业务考虑清楚，故障切换带来的数据一致性问题
3 Mysql同城切换：Mysql的主从复制与MHA的架构，只支持同IDC的自动切换，如果发生IDC级别的故障，需要人工介入，手工启动同城容灾的数据库为Master节点，这里的操作与判断需要运营人员快速响应
6 总结
作者：陈强 （CHENQIANG747 ），网金研发团队架构师
在此感谢DBA团队王鹏冲、孙少卿的指导。
本文系个人观点，描述不当或不正确，欢迎指正。
