标签：http io ar 使用 sp for strong on 数据
贴一些比较老的内容，文章是新写的，技术可能都是大家熟悉的，给入门的兄弟们参考。高手轻拍
原文请见：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.
稳定性，需要强健的监控和较为复杂的自动化报警、故障处理措施
标签：http io ar 使用 sp for strong on 数据
原文地址：http://www.cnblogs.com/seasonzone/p/4133558.html
