多数据中心的高可用结构【环状星型数据库架构】

贴一些比较老的内容,文章是新写的,技术可能都是大家熟悉的,给入门的兄弟们参考。高手轻拍
原文请见:http://www.muduo.net/index.php/u ... space-itemid-318728

二、
多数据中心的高可用结构【环状星型数据库架构】在介绍该结构之前,我们首先了解一下mysql复制的有关内容。在《highperformance mysql》的第一版中,作者介绍了这样的一种数据库结构:

                              
三个mysql的daemon均为上家的slave,均为下家的master,环形复制,如此,则生生不息。

每个环路上的master分别有自己的slave,解决mysql的效率和可用性的问题。

遗憾的是,Jeremy的想象力够丰富,但是当时mysql的最新版本为 4.0,并不支持如此复杂的mysql复制结构,缺少关键环节的解决方案,有哪些关键环节呢?

i.
Auto_increment 字段冲突问题

ii.
如上图,4(mysql服务器3的slave)从3(mysql服务器4的master)复制数据,只能复制应用程序在3上写入的数据(即3产生了binlog),对于3(此时作为mysql服务器2 的slave)在2(作为mysql服务器3的master)那里复制得来的数据,无法复制到服务器4上的。

iii.
环形复制本地产生数据重复写入的问题

就是上面三个当时无法解决的问题,Jeremy在《high performance mysql》中的整章内容几乎变成想像。

我相信如今的mysql 5的设计一定是吸收了Jeremy的构想的。

(一)
架构图
结合《单数据中心的mysql高可用架构》和mysql5的特性,我们设计出了如下的多数据中心mysql高可用结构,即环状星型结构。




(二)
系统结构说明
如上图所示,假设A、B、C、D 4个数据中心,每个数据中心都拥有同样的应用程序(不限于web服务),各个数据中心的应用程序按照《单数据中心的mysql高可用架构》中提到的方案直接读写本地的数据库数据。
此时,在确保单数据中心高可用的基础上,我们将结构简化,简化为如下结构:




A、B、C、D是一个十分简洁的mysql复制环,满足这个复制结构正常运行需要在如下方面进行配置:

 


i.
解决auto_increment字段数据冲突的问题,通过http://dev.mysql.com/doc/refman/5.1/en/replication-options-master.html#sysvar_auto_increment_increment

 


ii.
当同一台机器作为slave且作为master的情况下,解决复制的内容能够被传送到下一台slave

 


iii.
解决某一数据从A复制到B,从B复制到C,从C复制到D,但是不会从D复制到A





下面将详细的介绍如何解决上面的问题:

 


i.
AUTO_INCREMENT字段冲突的问题








 

auto_increment_increment 和 auto_increment_offset 这两个系统变量是为了满足masterßàmaster 这种mysql复制模式产生的,这两个变量能够控制AUTO_INCREMENT 列的行为,避免 AUTO_INCREMENT 列的value产生冲突。关于这部分的详细内容,建议参考:http://dev.mysql.com/doc/refman/5.1/en/replication-options-master.html#sysvar_auto_increment_increment

 


ii.
--log-slave-updates

 

一般情况下,slave服务器不需要(也不会)将它从master服务器那里接收到的“更新”记录到binlog里面,但是这个系统变量能够让mysql的slave服务器记录这些“更新”到自己的binlog。在使用这个变量的情况下,需要首先配置mysql的“--log-bin”变量。

 


iii.
--replicate-same-server-id

 

默认情况下,这个值被置成0。以避免在环形复制结构中出现的无限循环复制。

 

Ok,在普通复制结构的基础上,经过上面的三点额外配置,mysql环形复制即可以正常工作。如上图的A、B、C、D4台mysql环形复制结构,可以在任意一个mysqld服务中插入、更新数据,而在任一mysqld服务器中,可以查到所有的数据。当然,对于满足环状星型高可用mysql数据库架构来讲,还需要进一步解决:

 


i.
任一mysql集群(如A)的master服务的高可用(通过heart-beat实现虚拟IP地址的漂移,通过漂移IP实现)

 


ii.
数据库各组之间间数据连通性及可靠性问题【针对业务要求,指定不同的标准】

 

a)
通过 UDT网关进行传输层代理

 

b)
通过专线进行解决

 


iii.
解决mysql binlog传输的带宽问题,该问题考虑下面两种解决方法:

 

a)
通过--slave_compressed_protocol ,在mysql 主、从服务器之间使用协议压缩,降低带宽要求:

 

1.
slave_compressed_protocol=1


2.
SET @@global.slave_compressed_protocol=1;

b)
通过开发mysql 差异化复制协议(如互动社区的binlog项目)





Mysql的环状星型多数据中心结构能够解决如下的问题

 


i.
解决由于跨网操作数据反应慢的问题,数据更新在本地IDC进行,确保动态程序快速、及时。

 


ii.
解决数据中心的冗余问题,如果某一个IDC的数据中心宕到,可随时切换到另外的数据中心。

 

当然,这种结构也不是完美的,在解决了一些问题的同时,也会带来一些其他的问题:

 


i.
数据同步延迟,跨IDC的数据库同步相比同网的mysql复制,网络环境更为复杂,由于binlog的传输问题,容易带来更大的数据延迟

 


ii.
稳定性,需要强健的监控和较为复杂的自动化报警、故障处理措施

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。