貼一些比較老的內(nèi)容，文章是新寫的，技術(shù)可能都是大家熟悉的，給入門的兄弟們參考。高手輕拍
原文請見：http://www.muduo.net/index.php/u ... space-itemid-318728

二、
多數(shù)據(jù)中心的高可用結(jié)構(gòu)【環(huán)狀星型數(shù)據(jù)庫架構(gòu)】在介紹該結(jié)構(gòu)之前，我們首先了解一下mysql復(fù)制的有關(guān)內(nèi)容。在《highperformance mysql》的第一版中，作者介紹了這樣的一種數(shù)據(jù)庫結(jié)構(gòu)：

? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?
三個mysql的daemon均為上家的slave，均為下家的master，環(huán)形復(fù)制，如此，則生生不息。

每個環(huán)路上的master分別有自己的slave，解決mysql的效率和可用性的問題。

遺憾的是，Jeremy的想象力夠豐富，但是當時mysql的最新版本為?4.0，并不支持如此復(fù)雜的mysql復(fù)制結(jié)構(gòu)，缺少關(guān)鍵環(huán)節(jié)的解決方案，有哪些關(guān)鍵環(huán)節(jié)呢？

i.
Auto_increment?字段沖突問題

ii.
如上圖，4（mysql服務(wù)器3的slave）從3（mysql服務(wù)器4的master）復(fù)制數(shù)據(jù)，只能復(fù)制應(yīng)用程序在3上寫入的數(shù)據(jù)（即3產(chǎn)生了binlog），對于3（此時作為mysql服務(wù)器2?的slave）在2（作為mysql服務(wù)器3的master）那里復(fù)制得來的數(shù)據(jù)，無法復(fù)制到服務(wù)器4上的。

iii.
環(huán)形復(fù)制本地產(chǎn)生數(shù)據(jù)重復(fù)寫入的問題

就是上面三個當時無法解決的問題，Jeremy在《high performance mysql》中的整章內(nèi)容幾乎變成想像。

我相信如今的mysql 5的設(shè)計一定是吸收了Jeremy的構(gòu)想的。

(一)
架構(gòu)圖
結(jié)合《單數(shù)據(jù)中心的mysql高可用架構(gòu)》和mysql5的特性，我們設(shè)計出了如下的多數(shù)據(jù)中心mysql高可用結(jié)構(gòu)，即環(huán)狀星型結(jié)構(gòu)。




(二)
系統(tǒng)結(jié)構(gòu)說明
如上圖所示，假設(shè)A、B、C、D 4個數(shù)據(jù)中心，每個數(shù)據(jù)中心都擁有同樣的應(yīng)用程序（不限于web服務(wù)），各個數(shù)據(jù)中心的應(yīng)用程序按照《單數(shù)據(jù)中心的mysql高可用架構(gòu)》中提到的方案直接讀寫本地的數(shù)據(jù)庫數(shù)據(jù)。
此時，在確保單數(shù)據(jù)中心高可用的基礎(chǔ)上，我們將結(jié)構(gòu)簡化，簡化為如下結(jié)構(gòu)：

A、B、C、D是一個十分簡潔的mysql復(fù)制環(huán)，滿足這個復(fù)制結(jié)構(gòu)正常運行需要在如下方面進行配置：

?

i.
解決auto_increment字段數(shù)據(jù)沖突的問題，通過http://dev.mysql.com/doc/refman/5.1/en/replication-options-master.html#sysvar_auto_increment_increment

?

ii.
當同一臺機器作為slave且作為master的情況下，解決復(fù)制的內(nèi)容能夠被傳送到下一臺slave

?

iii.
解決某一數(shù)據(jù)從A復(fù)制到B，從B復(fù)制到C，從C復(fù)制到D，但是不會從D復(fù)制到A

下面將詳細的介紹如何解決上面的問題：

?

i.
AUTO_INCREMENT字段沖突的問題

?

auto_increment_increment?和?auto_increment_offset?這兩個系統(tǒng)變量是為了滿足master?àmaster?這種mysql復(fù)制模式產(chǎn)生的，這兩個變量能夠控制AUTO_INCREMENT?列的行為，避免 AUTO_INCREMENT 列的value產(chǎn)生沖突。關(guān)于這部分的詳細內(nèi)容，建議參考：http://dev.mysql.com/doc/refman/5.1/en/replication-options-master.html#sysvar_auto_increment_increment

?

ii.
--log-slave-updates

?

一般情況下，slave服務(wù)器不需要（也不會）將它從master服務(wù)器那里接收到的“更新”記錄到binlog里面，但是這個系統(tǒng)變量能夠讓mysql的slave服務(wù)器記錄這些“更新”到自己的binlog。在使用這個變量的情況下，需要首先配置mysql的“--log-bin”變量。

?

iii.
--replicate-same-server-id

?

默認情況下，這個值被置成0。以避免在環(huán)形復(fù)制結(jié)構(gòu)中出現(xiàn)的無限循環(huán)復(fù)制。

?

Ok，在普通復(fù)制結(jié)構(gòu)的基礎(chǔ)上，經(jīng)過上面的三點額外配置，mysql環(huán)形復(fù)制即可以正常工作。如上圖的A、B、C、D4臺mysql環(huán)形復(fù)制結(jié)構(gòu)，可以在任意一個mysqld服務(wù)中插入、更新數(shù)據(jù)，而在任一mysqld服務(wù)器中，可以查到所有的數(shù)據(jù)。當然，對于滿足環(huán)狀星型高可用mysql數(shù)據(jù)庫架構(gòu)來講，還需要進一步解決：

?

i.
任一mysql集群（如A）的master服務(wù)的高可用（通過heart-beat實現(xiàn)虛擬IP地址的漂移，通過漂移IP實現(xiàn)）

?

ii.
數(shù)據(jù)庫各組之間間數(shù)據(jù)連通性及可靠性問題【針對業(yè)務(wù)要求，指定不同的標準】

?

a)
通過?UDT網(wǎng)關(guān)進行傳輸層代理

?

b)
通過專線進行解決

?

iii.
解決mysql binlog傳輸?shù)膸拞栴}，該問題考慮下面兩種解決方法：

?

a)
通過--slave_compressed_protocol?，在mysql?主、從服務(wù)器之間使用協(xié)議壓縮，降低帶寬要求：

?

1.
slave_compressed_protocol=1

2.
SET @@global.slave_compressed_protocol=1;

b)
通過開發(fā)mysql?差異化復(fù)制協(xié)議（如互動社區(qū)的binlog項目）

Mysql的環(huán)狀星型多數(shù)據(jù)中心結(jié)構(gòu)能夠解決如下的問題：

?

i.
解決由于跨網(wǎng)操作數(shù)據(jù)反應(yīng)慢的問題，數(shù)據(jù)更新在本地IDC進行，確保動態(tài)程序快速、及時。

?

ii.
解決數(shù)據(jù)中心的冗余問題，如果某一個IDC的數(shù)據(jù)中心宕到，可隨時切換到另外的數(shù)據(jù)中心。

?

當然，這種結(jié)構(gòu)也不是完美的，在解決了一些問題的同時，也會帶來一些其他的問題：

?

i.
數(shù)據(jù)同步延遲，跨IDC的數(shù)據(jù)庫同步相比同網(wǎng)的mysql復(fù)制，網(wǎng)絡(luò)環(huán)境更為復(fù)雜，由于binlog的傳輸問題，容易帶來更大的數(shù)據(jù)延遲

?

ii.
穩(wěn)定性，需要強健的監(jiān)控和較為復(fù)雜的自動化報警、故障處理措施

轉(zhuǎn)載于:https://www.cnblogs.com/seasonzone/p/4133558.html

總結(jié)

以上是生活随笔為你收集整理的多数据中心的高可用结构【环状星型数据库架构】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。