這種架構(gòu)一般用在以下三類場景
從策劃到設(shè)計制作,每一步都追求做到細膩,制作可持續(xù)發(fā)展的企業(yè)網(wǎng)站。為客戶提供網(wǎng)站制作、網(wǎng)站設(shè)計、網(wǎng)站策劃、網(wǎng)頁設(shè)計、國際域名空間、網(wǎng)頁空間、網(wǎng)絡(luò)營銷、VI設(shè)計、 網(wǎng)站改版、漏洞修補等服務(wù)。為客戶提供更好的一站式互聯(lián)網(wǎng)解決方案,以客戶的口碑塑造優(yōu)易品牌,攜手廣大客戶,共同發(fā)展進步。
1. 備份多臺 Server 的數(shù)據(jù)到一臺如果按照數(shù)據(jù)切分方向來講,那就是垂直切分。比如圖 2,業(yè)務(wù) A、B、C、D 是之前拆分好的業(yè)務(wù),現(xiàn)在需要把這些拆分好的業(yè)務(wù)匯總起來備份,那這種需求也很適用于多源復(fù)制架構(gòu)。實現(xiàn)方法我大概描述下:業(yè)務(wù) A、B、C、D 分別位于 4 臺 Server,每臺 Server 分別有一個數(shù)據(jù)庫來隔離前端的業(yè)務(wù)數(shù)據(jù),那這樣,在從庫就能把四臺業(yè)務(wù)的數(shù)據(jù)全部匯總起來,而不需要做額外的操作。那沒有多源復(fù)制之前,要實現(xiàn)這類需求,只能在匯總機器上搭建多個 MySQL 實例,那這樣勢必會涉及到跨庫關(guān)聯(lián)的問題,不但性能急劇下降,管理多個實例也沒有單臺來的容易。
2. 用來聚合前端多個 Server 的分片數(shù)據(jù)。
同樣,按照數(shù)據(jù)切分方向來講,屬于水平切分。比如圖 3,按照年份拆分好的數(shù)據(jù),要做一個匯總數(shù)據(jù)展現(xiàn),那這種架構(gòu)也非常合適。實現(xiàn)方法稍微復(fù)雜些:比如所有 Server 共享同一數(shù)據(jù)庫和表,一般為了開發(fā)極端透明,前端配置有分庫分表的中間件,比如愛可生的 DBLE。
3. 匯總并合并多個 Server 的數(shù)據(jù)
第三類和第一種場景類似。不一樣的是不僅僅是數(shù)據(jù)需要匯總到目標端,還得合并這些數(shù)據(jù),這就比第一種來的相對復(fù)雜些。比如圖 4,那這樣的需求,是不是也適合多源復(fù)制呢?答案是 YES。那具體怎么做呢?
具體操作:
1、在分析型數(shù)據(jù)庫上創(chuàng)建目標表,數(shù)據(jù)更新類型為實時寫入,字段名稱和MySQL中的建議均相同;
2、在阿里云數(shù)據(jù)傳輸?shù)目刂婆_上創(chuàng)建數(shù)據(jù)訂閱通道,并記錄這個通道的ID;
3、 配置dts-ads-writer/app.conf文件,配置方式如下:所有配置均保存在app.conf中,運行前請保證配置正確;修改配置后,請重啟writer,基本配置:
注意事項:
1、RDS
for
MySQL表和分析型數(shù)據(jù)庫中表的主鍵定義必須完全一致;如果不一致會出現(xiàn)數(shù)據(jù)不一致問題。如果需要調(diào)整RDS/分析型數(shù)據(jù)庫表的主鍵,建議先停止writer進程;
2、一個插件進程中分析型數(shù)據(jù)庫db只能是一個,由adsJdbcUrl指定;
3、一個插件進程只能對應(yīng)一個數(shù)據(jù)訂閱通道;如果更新通道中的訂閱對象時,需要重啟進程。
A服務(wù)器1.1
B服務(wù)器1.2
需求:要將A服務(wù)器中a庫的a1,b1,c1表同步到B服務(wù)器中b庫里
A服務(wù)器:
1.首先將A服務(wù)器中a-c表導(dǎo)出,可以通過mysqldump命令導(dǎo)出
B服務(wù)器:
這一需求在不同機器上的,
1,通過replication (master-slaves)實現(xiàn)了這兩張表的復(fù)制功能,
2,mysql的版本是5.1.54,基于記錄的復(fù)制(Row-Based Replication)。
3,但是在備庫調(diào)用存儲過程時出了問題,這個存儲過程中使用了UUID_short()函數(shù),在存儲過程這個函數(shù)不能產(chǎn)生新值。