MySQL-主从架构探索
文章目錄
- 生猛干貨
- 官方文檔
- 為什么要用主從方案
- 常見的主從方案
- 一主一從 M-S
- 一主多從 M-S-S-S
- 多主一從 M-M-M-S (5.7開始支持)
- 使用場景
- 一主多級從
- 雙主 M-M
- 環形主從(復制)S-S-S-S
- 使用場景
- MySQL安裝
- 主從復制的概念
- 主從復制的兩種方案
- 主從架構的架構圖解析
- MySQL主從復制涉及到三個線程
- 主節點 binary log dump 線程
- 從節點-I/O線程
- 從節點-SQL線程
- MySQL 主從復制的過程
- MySQL 主從復制模式
- 異步模式（mysql async-mode）
- 半同步模式(mysql semi-sync)
- 全同步模式(mysql fully synchronized)
- binlog記錄格式
- GTID復制模式
- MySQL 主從復制主要用途
- MySQL復制性能優化
- 如何在MySQL5.7中配置多線程復制
- MySQL主從復制無法解決的問題
- 搞定MySQL
生猛干貨
帶你搞定MySQL實戰，輕松對應海量業務處理及高并發需求，從容應對大場面試
官方文檔
https://dev.mysql.com/doc/
如果英文不好的話，可以參考 searchdoc 翻譯的中文版本
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
為什么要用主從方案
可以從以下的幾個方面來考慮
- 如果主服務器出現問題，可以快速切換到從服務器提供的服務 。 （如果做了讀寫分離的話，主庫掛了，起碼還能提供查詢服務。 如果又做了高可用的話，從服務可以提升為主節點。 ）
- 可以在從服務器上執行查詢操作，降低主服務器的訪問壓力
- 可以在從服務器上執行備份，以避免備份期間影響主服務器的服務
常見的主從方案
每個方案都有其適用的場景，沒有通用的放之四海而皆準的方案。根據自己的業務選擇合理的方案。
一主一從 M-S
最簡單的主從方案
一主多從 M-S-S-S
一主一從和一主多從是最常見的主從架構，實施起來簡有效，不僅可以實現HA，而且還能讀寫分離，進而提升集群的并發能力。
多主一從 M-M-M-S (5.7開始支持)
多主一從可以將多個mysql數據庫備份到一臺存儲性能比較好的服務器上。
使用場景
舉個例子 master節點是各個分公司的庫， slave節點是集團公司的庫。 數據同步至集團slave節點。
集團公司要動態的掌握子公司的財務狀況，集團每個月要進行匯總，這個時候各個子公司（master節點）把數據匯總到集團公司（slave節點），這樣是不是方便來集團公司匯總查看了？
一主多級從
級聯復制模式下，部分slave的數據同步不連接主節點，而是連接從節點。
因為如果主節點有太多的從節點，就會損耗一部分性能用于replication，那么我們可以讓3~5個從節點連接主節點，其它從節點作為二級或者三級與從節點連接，這樣不僅可以緩解主節點的壓力，并且對數據一致性沒有負面影響。
雙主 M-M
雙主結構，相互讀寫復制。
雙主復制，也就是互做主從復制，每個master既是master，又是另外一臺服務器的slave。這樣任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。
我們常用的M-M-M 高可用的方案就是基于這個來做的。
環形主從(復制)S-S-S-S
使用場景
比較特殊的一種場景
舉個例子： 各個分公司之間有些數據是共享的，任何一個分公司的數據的變化都要通知到其他分公司，這個時候使用這種閉環的方案比較合適。
MySQL安裝
MySQL-CentOS7通過YUM安裝MySQL5.7.29
主從復制的概念
MYSQL的主從復制主要是說數據可以從一個MySQL數據庫服務器主節點復制到一個或多個從節點。
MySQL 默認采用異步復制方式。
這樣從節點不用一直訪問主服務器來更新自己的數據，數據的更新可以在遠程連接上進行，從節點可以復制主數據庫中的所有數據庫或者特定的數據庫，或者特定的表。
主從復制的兩種方案
目前來說，MYSQL提供了兩種方式來實現主從復制
我們這里重點來討論基于bin log的主從復制
主從架構的架構圖解析
MySQL主從復制涉及到三個線程
MySQL主從復制涉及到三個線程
- 主節點（log dump thread)
- 其余兩個(I/O thread, SQL thread)運行在從節點
主節點 binary log dump 線程
當從節點連接主節點時，主節點會創建一個binlog dump 線程，用于發送bin-log的內容。
從節點-I/O線程
當從節點上執行start slave命令之后，從節點會創建一個I/O線程用來連接主節點，請求主庫中更新的bin-log。I/O線程接收到主節點binlog dump 進程發來的更新之后，保存在本地relay-log中。
從節點-SQL線程
SQL線程負責讀取relay log中的內容，解析成具體的操作并執行，最終保證主從數據的一致性。
MySQL 主從復制的過程
對于每一個主從連接，都需要三個線程來完成。
當主節點有多個從節點時，主節點會為每一個當前連接的從節點建一個binary log dump 進程，而每個從節點都有自己的I/O進程，SQL進程。
從節點用兩個線程將從主庫拉取更新和執行分成獨立的任務，這樣在執行同步數據任務的時候，不會降低讀操作的性能。比如，如果從節點沒有運行，此時I/O進程可以很快從主節點獲取更新，盡管SQL進程還沒有執行。如果在SQL進程執行之前從節點服務停止，至少I/O進程已經從主節點拉取到了最新的變更并且保存在本地relay日志中，當服務再次起來之后，就可以完成數據的同步。
要實施復制，首先必須打開Master 端的binary log（bin-log）功能，否則無法實現。 因為整個復制過程實際上就是Slave 從Master 端獲取該日志然后再在自己身上完全順序的執行日志中所記錄的各種操作。
- 從節點(Slave )上的I/O 進程連接主節點(Master)，并請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內容；
- 主節點(Master)接收到來自從節點(Slave )的I/O請求后，通過負責復制的I/O進程根據請求信息讀取指定日志指定位置之后的日志信息，返回給從節點。返回信息中除了日志所包含的信息之外，還包括本次返回的信息的bin-log file 的以及bin-log position；從節點的I/O進程接收到內容后，將接收到的日志內容更新到本機的relay log中，并將讀取到的binary log文件名和位置保存到master-info 文件中，以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log 的哪個位置開始往后的日志內容，請發給我”；
- Slave 的 SQL線程檢測到relay-log 中新增加了內容后，會將relay-log的內容解析成在主節點上實際執行過的操作，并在本數據庫中執行。
MySQL 主從復制模式
MySQL 主從復制默認是異步的模式。MySQL增刪改操作會全部記錄在binary log中，當slave節點連接master時，會主動從master處獲取最新的bin log文件
異步模式（mysql async-mode）
主節點不會主動push bin log到從節點，這樣有可能導致failover的情況下，也許從節點沒有即時地將最新的bin log同步到本地,但效率高。
半同步模式(mysql semi-sync)
主節點只需要接收到其中一臺從節點的返回信息，就會commit；否則需要等待直到超時時間然后切換成異步模式再提交；這樣做的目的可以使主從數據庫的數據延遲縮小，可以提高數據安全性，確保了事務提交后，binlog至少傳輸到了一個從節點上，不能保證從節點將此事務更新到db中。性能上會有一定的降低，響應時間會變長.
半同步模式不是mysql內置的，從mysql 5.5開始集成，需要master 和slave 安裝插件開啟半同步模式。
全同步模式(mysql fully synchronized)
主節點和從節點全部執行了commit并確認才會向客戶端返回成功
binlog記錄格式
MySQL 主從復制有三種方式：
基于SQL語句的復制（statement-based replication，SBR），
基于行的復制（row-based replication，RBR)，
混合模式復制（mixed-based replication,MBR)。
對應的binlog文件的格式也有三種：STATEMENT,ROW,MIXED。
-
Statement-base Replication (SBR)就是記錄sql語句在bin log中，Mysql 5.1.4
及之前的版本都是使用的這種復制格式。優點是只需要記錄會修改數據的sql語句到binlog中，減少了binlog日質量，節約I/O，提高性能。缺點是在某些情況下，會導致主從節點中數據不一致（比如sleep(),now()等）。 -
Row-based Relication(RBR)是mysql master將SQL語句分解為基于Row更改的語句并記錄在bin log中，也就是只記錄哪條數據被修改了，修改成什么樣。優點是不會出現某些特定情況下的存儲過程、或者函數、或者trigger的調用或者觸發無法被正確復制的問題。缺點是會產生大量的日志，尤其是修改table的時候會讓日志暴增,同時增加bin log同步時間。也不能通過bin log解析獲取執行過的sql語句，只能看到發生的data變更。
-
Mixed-format Replication(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上兩種模式的混合，對于一般的復制使用STATEMENT模式保存到binlog，對于STATEMENT模式無法復制的操作則使用ROW模式來保存，MySQL會根據執行的SQL語句選擇日志保存方式。
MySQL 5.7.6之前默認為STATEMENT模式。MySQL 5.7.7之后默認為ROW模式. 這個參數主要影響主從復制。
GTID復制模式
GTID底層也是基于bin log 。
1、全局事物標識：global transaction identifieds。
2、GTID事物是全局唯一性的，且一個事務對應一個GTID。
3、一個GTID在一個服務器上只執行一次，避免重復執行導致數據混亂或者主從不一致。
4、GTID用來代替classic的復制方法，不在使用binlog+pos開啟復制。而是使用master_auto_postion=1的方式自動匹配GTID斷點進行復制。
5、MySQL-5.6.5開始支持的，MySQL-5.6.10后開始完善。
6、在傳統的slave端，binlog是不用開啟的，但是在GTID中，slave端的binlog是必須開啟的，目的是記錄執行過的GTID（強制）
基于GTID復制實現的工作原理
-
主節點更新數據時，會在事務前產生GTID，一起記錄到binlog日志中。
-
從節點的I/O線程將變更的bin log，寫入到本地的relay log中。
-
SQL線程從relay log中獲取GTID，然后對比本地binlog是否有記錄（所以MySQL從節點必須要開啟binary log）。
-
如果有記錄，說明該GTID的事務已經執行，從節點會忽略。
-
如果沒有記錄，從節點就會從relay log中執行該GTID的事務，并記錄到bin log。
-
在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果有就用全部掃描。
MySQL 主從復制主要用途
-
讀寫分離 : 有時候會遇見某個sql 語句需要鎖表，導致暫時不能使用讀的服務，這樣就會影響現有業務，使用主從復制，讓主庫負責寫，從庫負責讀，這樣，即使主庫出現了鎖表的情景，通過讀從庫也可以保證業務的正常運作。
-
數據實時備 : 當系統中某個節點發生故障時，可以方便的故障切換
-
高可用HA
-
架構擴展: 隨著系統中業務訪問量的增大，如果是單機部署數據庫，就會導致I/O訪問頻率過高。有了主從復制，增加多個數據存儲節點，將負載分布在多個從節點上，降低單機磁盤I/O訪問的頻率，提高單個機器的I/O性能。
MySQL復制性能優化
影響主從延遲的因素
- 主庫寫入二進制日志的時間 ------> 控制主庫的事務大小，分割大事務
- 二進制日志傳輸的時間 ------> 使用mixed日志格式 或者 使用row,但要set binlog_row_image=minimal;
- 默認情況下從庫只有一個SQL線程，主庫上并發修改但到了從庫變成了一個線程串行 -----> 使用多線程復制 （5.6提供的功能） ,在mysql中可以按照邏輯時鐘的方式來分配SQL線程
如何在MySQL5.7中配置多線程復制
在從服務器上 配置
[root@artisan binlog]# mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 51 Server version: 5.7.29-log MySQL Community Server (GPL) ... .... .....mysql> mysql> stop slave; Query OK, 0 rows affected (0.01 sec)mysql> set global slave_parallel_type='logical_clock'; Query OK, 0 rows affected (0.03 sec)mysql> set global slave_parallel_workers=4; # 設置4個SQL線程 Query OK, 0 rows affected (0.04 sec)mysql> start slave; Query OK, 0 rows affected (0.36 sec)mysql>查看
mysql> show processlist \G; *************************** 1. row ***************************Id: 21User: rootHost: localhostdb: NULL Command: QueryTime: 0State: startingInfo: show processlist *************************** 2. row ***************************Id: 22User: system userHost: db: NULL Command: ConnectTime: 126State: Waiting for master to send eventInfo: NULL *************************** 3. row ***************************Id: 23User: system userHost: db: NULL Command: ConnectTime: 126State: Slave has read all relay log; waiting for more updatesInfo: NULL *************************** 4. row ***************************Id: 24User: system userHost: db: NULL Command: ConnectTime: 126State: Waiting for an event from CoordinatorInfo: NULL *************************** 5. row ***************************Id: 25User: system userHost: db: NULL Command: ConnectTime: 126State: Waiting for an event from CoordinatorInfo: NULL *************************** 6. row ***************************Id: 26User: system userHost: db: NULL Command: ConnectTime: 126State: Waiting for an event from CoordinatorInfo: NULL *************************** 7. row ***************************Id: 27User: system userHost: db: NULL Command: ConnectTime: 126State: Waiting for an event from CoordinatorInfo: NULL 7 rows in set (0.00 sec)ERROR: No query specifiedmysql>MySQL主從復制無法解決的問題
- 無法分擔主庫的寫壓力 ---->分庫分表
- 無法提供讀寫分離的功能
- 無法進行自動故障轉移及主從切換—> MMM或者 MHA（推薦）
搞定MySQL
總結
以上是生活随笔為你收集整理的MySQL-主从架构探索的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 白话Elasticsearch73_ES
- 下一篇： MySQL-CentOS7通过YUM安装