2019獨角獸企業重金招聘Python工程師標準>>>

0x00前言

本書講述到定稿前的MySQL5.5版，所以下面內容的適用范圍止步于MySQL5.5。本文僅僅強調書中講述的重中之重， 以便快速查閱，詳細的內容還請認真閱讀書本和MySQL的官方文檔。

0x01簡介

本章闡述所有與復制相關的內容

• 簡要介紹復制如何工作
• 討論基本的復制服務搭建
• 與復制相關的配置
• 如何管理和優化復制服務器

0x02復制概述

• MySQL支持兩種復制方式：基于行的復制和基于語句的復制。
• 都是通過主庫上記錄二進制日志，雖然有開銷，但是不會很大。
• 同一時間點備庫上的數據可能與主庫存在不一致性，并無法保證主備之間的延遲。
• 通過復制可以將讀操作指向備庫來獲得更好地讀擴展。
• 目前備庫只能串行化執行。

復制解決的問題

• 數據分布
• 負載均衡
• 備份
• 高可用性和故障切換
• MySQL升級

復制如何工作

• 主庫把數據更改記錄到二進制日志中。
• 備庫將主庫上的日志復制到自己的中繼日志中。
• 備庫讀取中繼日志中的事件，將其重放到備庫數據之上。

<!-- more -->

0x03配置復制（略）

0x04復制的原理

現在一般使用基于行的復制更佳。

基于語句的復制（邏輯復制）

優點

• 實現相當簡單
• 不用太多帶寬
• 容易理解

缺點

• 很多情況無法正確復制，如使用了now()等函數
• 若使用了觸發器或者存儲過程也最好不要使用

基于行的復制

優點

• 減少鎖的使用，更高效地復制數據
• 占用更少的CPU
• 解決數據不一致的情況

缺點

• 無法知道服務器正在做什么
• 無法處理諸如在備庫修改表的schema的情況
• 帶寬較高

0x05復制拓撲（往后補充圖）

MySQL的復制有一個限制：每個備庫只能有一個主庫，但是可以用一些其他方法來解決這樣的限制。

一主庫多備庫（多用于備份和讀寫分離）

備庫之間根本沒有交互。有以下用途：

• 為不同的角色使用不同的備庫
• 可把一個備庫當做代用的主庫
• 把備庫放在遠程數據中心，用作災難恢復
• 備份，培訓，開發，測試

主動-主動模式下的主-主復制

用于兩個處于不同地理位置的辦公室，并且都需要一份可寫的數據拷貝。弊大于利。

主動-被動模式下的主-主復制

切換主動被動服務器很方便。

擁有備庫的主-主結構（用于增加冗余）

環形復制（要避免成環）

主庫、分發主庫以及備庫

• 當備庫足夠多時。會對主庫造成很大的負載，于是需要采用blackhole存儲引擎的分發主庫。
• 不一定只使用一個分發主庫。
• blackhole表沒有任何數據，但是目前有bug

樹或金字塔形

定制的復制方案

• 選擇復制性
• 分離功能（分離OLTP和OLAP）
• 數據歸檔
• 將備庫用作全文索引
• 只讀備庫
• 模擬多主庫復制
• 創建沒有數據的日志服務器

0x06復制和容量規劃

主備庫的模式下，并不是增加備庫就能線性增加讀寫功能。并且在開啟復制功能時，要考慮監控延時，可用性。

0x07 MySQL復制的高級特性

半同步復制

可以幫助確保備庫擁有主庫數據的拷貝，減少潛在的數據丟失危機。有助于備庫提供更好地冗余度和持久性。 半同步復制在提交過程中增加一個延遲：當提交事務時，在客戶端接收到查詢結束反饋前必須保證二進制日志已經傳輸 到至少一臺備庫上。

• 在主庫上已經完成事務提交，只有通知客戶端被延遲了。
• 備庫在接收到事務后發送反饋而非（備庫）完成事務后發送。
• 如果備庫一直沒有回應已收到事件，會超時并轉化為正常的異步復制模式。

復制心跳

保持備庫一直與主庫相聯系，避免悄無聲息地斷開連接。

0x08小結

• KISS原則（Keep It Simple Stupid），用簡單的就好。
• 監控，監控，監控，重要的事情說三遍。
• 理解復制的異步本質，且設計你的應用避免或容忍從備庫讀取臟數據。
• 在一個復制拓撲中不要寫入多于一個服務器，把備庫配置為只讀，并降低權限以阻止對數據的改變。
• 打開本章鎖討論的明智且安全的設置。（往后補充）

引用

《高性能MySQL · 第三版》

轉載于:https://my.oschina.net/joshuashaw/blog/666674

總結

以上是生活随笔為你收集整理的《高性能MySQL》の复制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。