MySQL——主從復制與讀寫分離

一、為什么需要主從復制

為什么需要主從復制，主要有以下三個場景：

• 在業務復雜的系統中，有這么一個情景：有一句sql陳述句需要鎖表，導致暫時不能使用讀的服務，那么就很影響運行中的業務，使用主從復制，讓主庫負責寫，從庫負責讀，這樣，即使主庫出現了鎖表的情景，通過讀從庫也可以保證業務的正常運作
• 做資料的熱備
• 架構的擴展，業務量越來越大，I/O訪問頻率過高，單機無法滿足，此時做多庫的存盤，降低磁盤I/O訪問的頻率，提高單個機器的I/O性能

二、什么是主從復制

MySQL 主從復制是指資料可以從一個 MySQL 資料庫服務器主節點復制到一個或多個從節點

MySQL 默認采用異步復制方式，這樣從節點不用一直訪問主服務器來更新自己的資料，資料的更新可以在遠程連接上進行，從節點可以復制主資料庫中的所有資料庫或者特定的資料庫，或者特定的表

重點在于資料如何在主庫和若干個從庫之間保持資料一致性，資料如何才能正確、即時的進行同步更新

三、主從復制原理–bin log

主從復制流程原理：

• master服務器將資料的改變記錄二進制binlog日志，當master上的資料發生改變時，則將其改變寫入二進制日志在

• slave 從服務器會在一定時間間隔內對 master 二進制日志進行探測其是否發生改變，如果發生改變，則開始一個 I/O Thread 請求 master 二進制事件

• 同時主節點為每個 I/O 執行緒啟動一個 dump 執行緒，用于向其發送二進制事件，并保存至從節點本地的中繼日志中，從節點將啟動 SQL 執行緒從中繼日志中讀取二進制日志，在本地重放，使得其資料和主節點的保持一致，最后 I/O Thread 和 SQLThread 將進入睡眠狀態，等待下一次被喚醒，

簡而言之就是：

• 從庫會生成兩個執行緒,一個 I/O 執行緒,一個 SQL 執行緒;
• I/O執行緒會去請求主庫的 binlog ,并將得到的binlog寫到本地的 relay-log (中繼日志)檔案中;
• 主庫會生成一個 log dump 執行緒,用來給從庫I/O執行緒傳 binlog ;
• SQL執行緒,會讀取relay log檔案中的日志,并決議成sql陳述句逐一執行;

注意：我們可以發現主從復制的實作原理的重點就在于 bin log，那么我們可能會有一個疑問–由于 bin log 的持久化存盤，會不會在持久化 bin log 的時候，I/O 是否會成為瓶頸？

其實是不會的，因為 redo log 、undo log 是回圈寫，是隨機讀寫的；而 bin log 是不斷進行 append 追加寫的，是順序寫的，性能很高，不會存在 I/O 瓶頸

流程圖如下：

具體步驟如下：

1. 從庫通過手工執行change master to 陳述句連接主庫，提供了連接的用戶一切條件（user 、password、port、ip），并且讓從庫知道，二進制日志的起點位置（file名 position 號）； start slave

2. 從庫的IO執行緒和主庫的dump執行緒建立連接，

3. 從庫根據change master to 陳述句提供的file名和position號，IO執行緒向主庫發起binlog的請求，

4. 主庫dump執行緒根據從庫的請求，將本地binlog以events的方式發給從庫IO執行緒，

5. 從庫IO執行緒接收 binlog events，并存放到本地relay-log中，傳送過來的資訊，會記錄到master.info中

6. 從庫SQL執行緒應用relay-log，并且把應用過的記錄到relay-log.info中，默認情況下，已經應用過的relay 會自動被清理purge

主從復制的注意點：

• master將操作陳述句記錄到binlog日志中，然后授予slave遠程連接的權限（master一定要開啟binlog二進制日志功能；通常為了資料安全考慮，slave也開啟binlog功能）
• slave開啟兩個執行緒：IO執行緒和SQL執行緒，其中：IO執行緒負責讀取master的binlog內容到中繼日志relay log里；SQL執行緒負責從relay log日志里讀出binlog內容，并更新到slave的資料庫里，這樣就能保證slave資料和master資料保持一致
• Mysql復制至少需要兩個Mysql的服務，當然Mysql服務可以分布在不同的服務器上，也可以在一臺服務器上啟動多個服務
• Mysql復制最好確保master和slave服務器上的Mysql版本相同（如果不能滿足版本一致，那么要保證master主節點的版本低于slave從節點的版本）
• master和slave兩節點間時間需同步

四、mysql主從復制形式

主從復制中資料庫一般肯定是要放在不同的機器里面的，因為如果放在一臺機器里面還是會占用同一臺服務器的性能，就沒有了主從復制的意義了

主從復制分為如下形式

1、一主一從

2、主主復制

3、一主多從

這種主從復制是最適合做讀寫分離的：

• 把主服務器作為寫服務器
• 把從服務器作為讀服務器

把資料的壓力分攤給不同的機器

4、多主一從

這種主從復制場景適合做資料備份

5、聯機復制

這種主從復制場景適合做資料備份，但是這種模式不是很好，因為從資料庫間是存在層級關系的，會出現如下問題：

• 延遲：各從資料庫之間進行資料同步必然存在延遲
• 依賴性太強：一旦某一臺從資料庫掛掉，則后續依賴的資料庫也會掛掉

五、mysql主從同步延時分析

mysql 的主從復制都是單執行緒的操作，主庫對所有 DDL 和 DML 產生的日志寫進 binlog ，由于 binlog 是順序寫，所以效率很高，slave 的 sql thread 執行緒將主庫的 DDL 和 DML 操作事件在 slave 中重放

DML 和 DDL 的IO操作是隨機的，不是順序，所以成本要高很多，另一方面，由于 sql thread 也是單執行緒的，當主庫的并發較高時，產生的 DML 數量超過 slave 的 SQL thread 所能處理的速度，或者當 slave 中有大型 query 陳述句產生了鎖等待，那么延時就產生了

延時解決方案：

• 業務的持久化層的實作采用分庫架構，mysql服務可平行擴展，分散壓力，
• 單個庫讀寫分離，一主多從，主寫從讀，分散壓力，這樣從庫壓力比主庫高，保護主庫，
• 服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層，降低mysql的讀壓力，
• 不同業務的mysql物理上放在不同機器，分散壓力，
• 使用比主庫更好的硬體設備作為slave，mysql壓力小，延遲自然會變小，
• 使用更加強勁的硬體設備

mysql5.7之后使用MTS并行復制技術，永久解決復制延時問題------自學

六、讀寫分離

1、讀寫分離介紹

MySQL讀寫分離基本原理是讓master資料庫處理寫操作，slave資料庫處理讀操作，master將寫操作的變更同步到各個slave節點，使資料庫壓力分攤到各個服務器，防止其中某臺服務器壓力過大

MySQL讀寫分離能提高系統性能的原因在于：

• 物理服務器增加，機器處理能力提升，拿硬體換性能，

• 主從只負責各自的讀和寫，極大程度緩解X鎖和S鎖爭用，

• slave 可以配置 myiasm 引擎，提升查詢性能以及節約系統開銷，

• master 直接寫是并發的，slave 通過主庫發送來的 binlog 恢復資料是異步，

• slave 可以單獨設定一些引數來提升其讀的性能，

• 增加冗余，提高可用性

2、讀寫分離的配置

1、硬體配置

master 192.168.85.11
slave  192.168.85.12
proxy  192，168.85.14

2、首先在master和slave上配置主從復制

3、進行proxy的相關配置

#1、下載mysql-proxy
https://downloads.mysql.com/archives/proxy/#downloads
#2、上傳軟體到proxy的機器
直接通過xftp進行上傳
#3、解壓安裝包
tar -zxvf mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit.tar.gz
#4、修改解壓后的目錄
mv mysql-proxy-0.8.5-linux-glibc2.3-x86-64bit mysql-proxy
#5、進入mysql-proxy的目錄
cd mysql-proxy
#6、創建目錄
mkdir conf
mkdir logs
#7、添加環境變數
#打開/etc/profile檔案
vi /etc/profile
#在檔案的最后面添加一下命令
export PATH=$PATH:/root/mysql-proxy/bin
#8、執行命令讓環境變數生效
source /etc/profile
#9、進入conf目錄，創建檔案并添加一下內容
vi mysql-proxy.conf
添加內容
[mysql-proxy]
user=root
proxy-address=192.168.85.14:4040
proxy-backend-addresses=192.168.85.11:3306
proxy-read-only-backend-addresses=192.168.85.12:3306
proxy-lua-script=/root/mysql-proxy/share/doc/mysql-proxy/rw-splitting.lua
log-file=/root/mysql-proxy/logs/mysql-proxy.log
log-level=debug
daemon=true
#10、開啟mysql-proxy
mysql-proxy --defaults-file=/root/mysql-proxy/conf/mysql-proxy.conf
#11、查看是否安裝成功，打開日志檔案
cd /root/mysql-proxy/logs
tail -100 mysql-proxy.log
#內容如下：表示安裝成功
2019-10-11 21:49:41: (debug) max open file-descriptors = 1024
2019-10-11 21:49:41: (message) proxy listening on port 192.168.85.14:4040
2019-10-11 21:49:41: (message) added read/write backend: 192.168.85.11:3306
2019-10-11 21:49:41: (message) added read-only backend: 192.168.85.12:3306
2019-10-11 21:49:41: (debug) now running as user: root (0/0)

4、進行連接

#mysql的命令列會出現無法連接的情況，所以建議使用客戶端
mysql -uroot -p123 -h192.168.85.14 -P 4040

3、MyCat

實際的生產環境中很少使用proxy和amoeba，生產環境中較為常用的是國產中間件 MyCat：http://www.mycat.io/

mycat的具體介紹：http://www.mycat.io/document/mycat-definitive-guide.pdf

關鍵概述：

對于 DBA 來說，可以這么理解 Mycat：

Mycat 就是 MySQL Server，而 Mycat 后面連接的 MySQL Server，就好象是 MySQL 的存盤引擎,如InnoDB，MyISAM 等，因此，Mycat 本身并不存盤資料，資料是在后端的 MySQL 上存盤的，因此資料可靠性以及事務等都是 MySQL 保證的，簡單的說，Mycat 就是 MySQL 最佳伴侶，它在一定程度上讓 MySQL 擁有了能跟 Oracle PK 的能力，

對于軟體工程師來說，可以這么理解 Mycat：

Mycat 就是一個近似等于 MySQL 的資料庫服務器，你可以用連接 MySQL 的方式去連接 Mycat（除了埠不同，默認的 Mycat 埠是 8066 而非 MySQL 的 3306，因此需要在連接字串上增加埠資訊），大多數情況下，可以用你熟悉的物件映射框架使用 Mycat，但建議對于分片表，盡量使用基礎的 SQL 陳述句，因為這樣能達到最佳性能，特別是幾千萬甚至幾百億條記錄的情況下，

對于架構師來說，可以這么理解 Mycat：

Mycat 是一個強大的資料庫中間件，不僅僅可以用作讀寫分離、以及分表分庫、容災備份，而且可以用于多租戶應用開發、云平臺基礎設施、讓你的架構具備很強的適應性和靈活性，借助于即將發布的 Mycat 智能優化模塊，系統的資料訪問瓶頸和熱點一目了然，根據這些統計分析資料，你可以自動或手工調整后端存盤，將不同的表映射到不同存盤引擎上，而整個應用的代碼一行也不用改變，

當前是個大資料的時代，但究竟怎樣規模的資料適合資料庫系統呢？對此，國外有一個資料庫領域的權威人士說了一個結論：千億以下的資料規模仍然是資料庫領域的專長，而 Hadoop 等這種系統，更適合的是千億以上的規模，所以，Mycat 適合 1000 億條以下的單表規模，如果你的資料超過了這個規模，請投靠 Mycat Plus 吧！

短時間內我們小白開發者是接觸不到 MyCat 的，如果遇到業績場景再回來學習