這篇文章主要講解了“MySQL 多源復制，過濾復制與應用場景介紹”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“MYSQL 多源復制，過濾復制與應用場景介紹”吧！

我們提供的服務有：網(wǎng)站設計制作、成都做網(wǎng)站、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、漳州ssl等。為上1000家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術(shù)的漳州網(wǎng)站制作公司

Mysql的使用中，會伴隨著一個其他數(shù)據(jù)庫中很少被提到的問題，數(shù)據(jù)融合。ORACLE ,SQL SERVER ,PG 你可以去分區(qū)表，MYSQL 中遇到這樣的問題大多去分庫分表去解決，雖然現(xiàn)在有了TIDB 可以進行MYSQL 的后續(xù)的數(shù)據(jù)融合，但如果數(shù)據(jù)量不大的情況下，或者有些 MYSQL 8的新支持的語法需求等等，多源復制還是一個好的選擇。

缺點也是顯而易見的，多源復制復制不會解決你復制中可能由于你不注意產(chǎn)生的復制的沖突問題。例如重名的數(shù)據(jù)庫，部署系統(tǒng)數(shù)據(jù)的沖突。下面就來看看如何來多源復制，和其中的一些 “坑”。

首先目前大部分單位的MYSQL 基本上已經(jīng)啟用了 GTID ，這里下面的復制中，全部使用 GTID 的方式進行連接.  

測試的機器有

主

192.168.192.200

192.168.192.202

從

192.168.192.201

首先備份 200 和 202 上的數(shù)據(jù)庫，備份的時候，僅僅只備份了需要進行數(shù)據(jù)同步的數(shù)據(jù)庫，并未進行全部備份，而做多源復制中，也需要這樣做，否則做第一個復制還好，后面的復制就不好做了，會有一些問題。

備份是通過mydumper 進行的備份，而mydumper 目前最新的0.95 是TIDB 的團隊在維護，應該是靠譜的在mysql 5.7及以下版本（如有不對請指正）

在 200 的機器上

在202 的機器上

在201 的機器上恢復相關(guān)的數(shù)據(jù)庫

恢復數(shù)據(jù)庫

同理恢復第二個數(shù)據(jù)庫到winner 數(shù)據(jù)庫

恢復后的數(shù)據(jù)庫 201 是這樣的。

下面我們來建立與兩臺MYSQL 主的復制

CHANGE MASTER TO MASTER_HOST='192.168.198.200', MASTER_USER='admin', MASTER_PORT=3306, MASTER_PASSWORD='XXXX', MASTER_AUTO_POSITION = 1 FOR CHANNEL 'C200';

CHANGE MASTER TO MASTER_HOST='192.168.198.202', MASTER_USER='admin', MASTER_PORT=3306, MASTER_PASSWORD='XXXX', MASTER_AUTO_POSITION = 1 FOR CHANNEL 'C202';

通過上面兩個語句，201 就已經(jīng)與 200， 201 兩臺機器建立的復制的關(guān)系。

啟動復制 start slave;  查看201 上的復制狀態(tài)

我們可以看到對于兩臺主機的復制是OK 的。而坑其實就不遠了

1  舉例，為了管理mysql 方便，我們在每臺MYSQL 上建立管理庫monitor

那么馬上問題就在數(shù)據(jù)匯聚庫 201 上出現(xiàn)問題，我先后在 200 ，和 202 兩臺機器上建立monitor 數(shù)據(jù)庫，按照邏輯來說，201 的復制 關(guān)于202 的復制應該會停，但由于特殊的設置，并未停止復制。但201 的錯誤日志，會毫不留情的記錄這個錯誤。

下面的錯誤日志報告 202   主機創(chuàng)建數(shù)據(jù)庫的命令失敗了

其實這就是配置中，讓復制中的DDL 語句的錯誤忽略產(chǎn)生的結(jié)果，但如果我們繼續(xù)操作一些非DDL 的操作，則復制就不會繼續(xù)工作了。

我們創(chuàng)建一個表，test1 分表在 200 和 202 機器上，然后插入數(shù)據(jù)，201 的復制報錯了。原因是主鍵重復。

通過這個事例想說明的問題

1  如果多源復制，建議還是DDL 的錯誤在多源復制的機器上更寬容一些。

2  不建議有類似比如每個數(shù)據(jù)庫都有的數(shù)據(jù)庫并在這個數(shù)據(jù)庫里面還有同樣的表和主鍵設置

那如果有類似的問題怎么辦，必須要在每個MYSQL的物理服務器上有相同命名的數(shù)據(jù)庫，而這個庫可以不進行復制。

那就祭出我們的復制過濾來解決問題，原理就是我們對傳遞過來的日志進行過濾，凡是不在我們允許的復制的數(shù)據(jù)庫list  中的都不進行復制。

我們先停止201 上的復制，stop slave; 然后將201 上的monitor 數(shù)據(jù)庫刪除

在201上執(zhí)行 下圖的語句 

啟動復制，然后我們在原來的 200 和 202 上在對monitor 數(shù)據(jù)庫中的表進行操作，

202 上的表

200 上的表

而 201 上的可以刪除 monitor 數(shù)據(jù)庫，復制將過濾一概不是 employees winner 數(shù)據(jù)庫之外的數(shù)據(jù)。

下圖，201 已經(jīng)沒有monitor  數(shù)據(jù)庫

并且201上的復制是正常工作的

MYSQL 的多源復制，其實是一個比較好的功能，也是針對某些分庫操作后的數(shù)據(jù)再次融合和簡單的數(shù)據(jù)聯(lián)合查詢而使用到的功能，當然其中的坑也很多，使用中不注意就會有各種復制的問題。

感謝各位的閱讀，以上就是“MYSQL 多源復制，過濾復制與應用場景介紹”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對MYSQL 多源復制，過濾復制與應用場景介紹這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！