Mysql復制定義及解析

下文內容主要給大家帶來Mysql復制定義及解析，這里所講到的知識，與書籍略有不同，都是億速云專業技術人員在與用戶接觸過程中，總結出來的，具有一定的經驗分享價值，希望給廣大讀者帶來幫助。

Master/Slave

Master: write/read，寫操作都在主節點上操作

Slaves: read，讀操作都是從節點這邊發出

為什么要復制？

冗余：promte（提升為主），異地災備，可以通過人工或者工具程序（MHA）實現

擴展：轉移一部分“讀”請求；

支援安全的備份操作；

測試需要；

主/從架構實現：

在主節點上啟用二進制日志，從節點啟動連接線程，請求主節點把這個事件發給自己一份，從節點上有一個線程叫IO Thread,主節點上啟用dump thread，IO Thread從節點將接受到的日志存儲到中繼日志，從云服務器上的SQL THread負責從中繼日志里生成一份數據。這樣的數據同步方式是異步。主服務器負責寫操作，從服務器負責讀操作。

主從有可能導致主從數據不一致。如主服務多線程進程，從服務區是單線程進程，有可能導致主從數據不一致，從服務器的數據可能會落后于主服務器，這個問題是不可避免的，只能盡早發現，將不正確的數據手動更改，如果數據差別很大，手動恢復很難，可以在主服務器上做備份，把數據直接回復到從服務器上。

主服務器存到二進制log，存到從服務器上是異步操作的。傳輸是單向的。但是這里有個問題，如果寫操作超出主服務器的性能，解決方法，使用雙主模型

主從復制的三種形式：同步復制，異步復制，半同步復制

同步復制：

        雙主模型：寫操作都在本地寫，同步給另一個節點，放到relay中。

主服務器都要啟動中繼日志和二進制日志，所有發給本節點的寫操作，都要記錄到二進制日志中，并通過dump thread發給對端主服務器，對端主服務器通過io thread將收到的數據存儲到中繼日志中，并依靠sql thread實現重放。主節點實現了冗余。每個節點都可以讀和寫操作。這種操作可以降低讀請求，每個服務器負載一半的請求，但是寫操作的請求數量是一樣的，因為，雙主的服務器都要寫入一份數據。

利用中間件的讀寫分離器實現請求讀寫分離，中間件可以利用keepalive實現冗余。但是有了雙主模型，就不需要讀寫分離，只需要用haproxy或者nginx或者lvs來實現請求的四層調度將請求調度到不同服務器上即可。

mysql主從復制弊端可能運行一段時間后，根據業務邏輯的不一樣，可能導致主從數據不一致，導致得到的數據不一致。該情況在數據要求強一致的情況下是不允許存在的。

在主服務器上，操作是多線程并行的，但是記錄到二進制文件中是串行記錄，從服務器是單線程運行獲取數據，這樣導致從服務器拉取數據的速度落后于主服務器，導致了數據的差異，長此以往會導致數據嚴重不一致。如果這里設置讀寫分離，可能導致從服務器上讀出的數據是錯誤的。雙主模型同樣有這個問題。主從數據不一致，建議解決辦法是手動修改數據。如果數據差別太大，將從服務器關閉，在主服務器上做備份，恢復到從服務器上。

異步復制：

一主多從；

一從一主；

級聯復制；一主復制給一從，同時，這個從服務器又是其他服務器的主，其他從服務器到這個中繼服務器復制數據，級聯的作用是降低主服務器的壓力。中間的這個從服務器要啟用二進制日志和中繼日志，同時，中間這臺從服務器僅起到過渡的作用，不需要保存數據，因此將block hole引擎用于這個中間從服務器上，使得不會產生數據保存，但是中繼日志和二進制日志都有正常保存，起到過渡的效果。

循環復制；多主模式下，采用循環復制，但是鏈條更長，可能導致數據落后嚴重。

雙主復制；

半同步復制：

一從多主模型：每個主服務器提供不同的數據庫，master只保證slaves中的一個操作成功，就返回，其他slave不管。這個功能，是由google為MYSQL引入的。

對于以上關于Mysql復制定義及解析，如果大家還有更多需要了解的可以持續關注我們億速云的行業推新，如需獲取專業解答，可在官網聯系售前售后的，希望該文章可給大家帶來一定的知識更新。