容灾方案

  目前有以下三种容灾方案可供参考：

1. 主从半同步复制+手动切换

方案介绍：由两台服务器上的数据库实例搭建主从架构，两个实例之间的数据同步使用MySQL半同步复制机制。主机绑定VIP，在主库故障后手动将VIP绑定至备机，将上层请求切换至备库，备库写入数据后成为新主，原主实例恢复后成为新主的备库，具体架构图如下：

优点：不存在VIP漂移问题，规避因底层同步延时导致的数据不一致。

缺点：故障时需要人工介入，效率低。

1. 主从半同步复制+keepalived自动切换

方案介绍：由两台服务器上的数据库实例搭建主从架构，VIP绑定在主实例上，程序通过VIP将数据写入主库。主实例由keepalived中间件通过脚本判活，如果检测失败则停止主机keepalived服务，VIP漂至从机，程序数据继续入库，具体架构图如下：

优点：实现故障自动切换，无需人工干预

缺点：如存在网络闪断等情况影响存活判断，可能会导致主从多次切换，造成潜在数据不一致问题

1. 阿里云MySQL RDS使用的高可用方案如下图所示，两台数据库实例组成主从模式，正常情况下应用层通过SLB访问主库，从库不可访问；主库故障则SLB自动切换至连接从库，上层应用无感知。同时也支持手动模式进行实例切换，具体架构图如下：

优点：数据库托管给云平台，降低运维成本

缺点：费用较高

1 本地容灾还是异地容灾，异地容灾的网络带宽及稳定性。

2 灾备数据库是否需要在线查询，是否需要效验比对某些核心数据是否与生产库一致。

3 RTO（恢复时间目标，指生产库发生故障到灾备库投入运行期望的时间）、RPO（数据恢复点目标，指生产系统所能容忍的数据丢失量）。

4 备份模式选择，单向备份模式（active/standby）还是双向互备模式。其中双向互备模式又分为半双工和全双工，半双工在任一时间点依然是单向模式（active/standby），只有一个数据库接受业务请求，当主库故障时允许主备自动切换。全双工模式（active /active），用于双业务中心异地互备，两个数据库同时接受业务请求。对于全双工模式需要考虑数据是否存在主键冲突。

5 部署及维护成本，灾备库是否支持异构（不同操作系统、不同数据库版本）、是否需要在主备库安装代理程序或在数据库额外创建对象、是否需要调整表结构等。应用系统升级是否需要重新配置备份过程，是否需要人工干预等。

灵蜂数据库复制软件Beedup提供数据库（Oracle/SQL Server/DB2/MySQL/PostgreSQL）容灾功能，具备以下特点：

1 Beedup采用TCP连接主从数据库，支持本地或异地容灾。软件读取解析主库归档或在线日志，还原其中的DDL及DML操作在备库执行，通过将软件部署到主库所属网络，可以在备份时有效降低网络负载。软件提供断点机制增量读取解析日志，可以忍受苛刻的网络条件。

2 Beedup采用SQL接口向从库写入DML及DDL，从库实时在线可用。另外软件提供主从表的差异比对功能，可以随时效验主从数据一致性。

3 Beedup采用事务单元复制主库变化到从库，主库事务提交后，软件立即读取解析事务并复制变化到从库，整个过程秒级完成。当主库发生故障时，可以直接修改从库IP为主库IP接管其上业务。

4 Beedup支持active/standby和active /active备份模式，对于active /active模式的自增主键冲突，无需调整业务系统，Beedup提供自增值到目标库的重新计算并更新相关依赖信息的功能。

5 Beedup采用JDBC读写主备数据库，对数据库运行平台及版本无要求，当生产库采用高性能设备时，备份库可以选择普通商用配置。软件部署灵活，既可部署于主服务器，也可部署于备份服务器，或者部署到可以TCP连通主备服务器的其它任意机器。软件对主库不需要任何写入操作，通过读取解析主库归档或在线日志复制事务到备份库，对于表结构、视图、存储过程、触发器等DDL操作均可自动备份，无需人工干预。