MySQL两地三中心方案初步设计( 二 ) _MySQL

文章插图

基于MGR的多活的设计方案如下，在数据库层通过优先在本机房的实例节点设置权重，优先切换到同机房，在同机房出现故障的情况下，切换到同城异机房。

文章插图

以上方案的实施成本较低，对业务的侵入较少，适用于跨机房容灾的初级阶段的用户。
2）应用层双活，数据库双活方案
应用层双活和数据库双活：两个机房的应用程序同时对外提供服务，两个机房的数据库也同时提供读写，每个机房的应用程序读写同一个机房内的数据库，两个数据库之间双向复制，通过一致性协议解决双向写冲突问题，该模式理论上实现了数据库多点写入，但是在实际跨机房场景中，尤其是在写冲突密集的业务场景下，性能下降非常大，不适用于跨机房的OLTP 系统。
而对于应用双活+数据库多活的方案，需要重点考虑数据延迟和数据同步的问题。首先需要在业务上做隔离，数据目标为最终一致性，目前存在如下的五类方案。
方案一：MGR集群多活架构
可以基于MGR的多活特性，数据的写入可以在多个节点之间进行复制，实现数据强一致性需求，并且在节点间通信出现延迟的情况下，会自动实现服务降级。
对于此类方案，我们可以采用同机房多写，同城异机房只读的方案。

文章插图

方案二：分布式数据同步
基于分布式设计方案，可以引入数据组件syncer和writer,实现机房多活的业务需求，syncer和writer为数据的发布者和消费者，基于分布式协议进行处理。
在处理过程中有三类关键技术：
1）数据的处理基于分布式ID，能够唯一定位数据处理操作，并且该操作具备递增趋势。
2）同步组件的稳定性，同步组件可以理解为一种通用服务，需要考虑不同机房间的数据延迟和数据冲突处理机制，保证同步组件服务的稳定，高效。
3）同步组件的高可用，对于同步组件需要根据业务特点做权重处理，考虑不通IDC的业务情况，并重点考虑同步组件的数据冗余设计，保证发生异常时能够及时恢复数据。
此种方案短期内难以实现，但是长期来看，可以支持机房多活，业务价值更高。

文章插图

方案三：双主模式的多活
对于数据库原生的双主模式，两个节点均可以写入数据，可以实现跨机房的数据复制，延迟较低，在业务层需要做隔离，在故障发生时能够快速切换到同机房的Slave节点。
此方案对于两个IDC机房的场景中较为实用，但是机房多活的场景不适合。

文章插图

方案四：业务交叉的双活方案
此种方案是双活技术的变通实现，即存在两类业务A和B,数据存储在database级别（schema层级），分别在不通的IDC节点完成数据写入，比如业务A在IDC1完成写入，业务B在IDC2完成写入，两个节点之间存在跨机房的复制节点，在出现问题时，能够通过域名的方式切换到指定的IDC节点。
此种方案对于业务的依赖性较高，不适合机房多活的场景。

文章插图

方案五：基于NewSQL的改造方案
可以参考行业内的NewSQL开源解决方案，原生支持MySQL协议。
比如PolarDB,Sequoia，TiDB等。
欢迎大家抛砖引玉，后续跟进阅读量考虑要不要继续展开。：）
相关链接：
http://www.info2soft.com/6291.html
http://www.h3c.com/cn/d_201307/790142_30008_0.htm

【MySQL两地三中心方案初步设计】