復(fù)制是將主數(shù)據(jù)庫的DDL和DML操作通過二進制日志傳到從庫上，然后再從庫重做，從而使得從庫和主庫保持數(shù)據(jù)的同步。MySQL可以從一臺主庫同時向多臺從庫進行復(fù)制，從庫同時也可以作為其他從庫的主庫，實現(xiàn)鏈式復(fù)制。
MySQL復(fù)制的優(yōu)點：
- 主庫故障，可以快速切換至從庫提供服務(wù)；
- 在從庫執(zhí)行查詢操作，降低主庫的訪問壓力；
- 在從庫執(zhí)行備份，避免備份期間對主庫影響；
MySQL復(fù)制原理
1、MySQL主庫在事務(wù)提交時會把數(shù)據(jù)變更作為事件Events記錄在Binlog中，主庫上的sync_binlog參數(shù)控制Binlog日志刷新到磁盤；
2、主庫推送Binlog中的事件到從庫的Relay Log，之后從庫根據(jù)Relay Log進行重做，通過邏輯復(fù)制來達到主從庫的數(shù)據(jù)一致；
MySQL通過3個線程來完成主從庫間的數(shù)據(jù)復(fù)制：其中Binlog Dump線程運行在主庫上，I/O線程和SQL線程運行在從庫上。當在從庫啟動復(fù)制（Start Slave）時，首先創(chuàng)建I/O線程連接主庫，主庫隨后創(chuàng)建Binlog Dump線程讀取數(shù)據(jù)庫事件并發(fā)送給I/O線程，I/O線程獲取到事件數(shù)據(jù)后更新到從庫的Relay Log中，之后從庫上的SQL線程讀取Relay Log中更新的數(shù)據(jù)庫事件并應(yīng)用，
如下圖所示：
查看主庫：
mysql> show processlist\G;
*************************** 1. row ***************************
Id: 3
User: root
Host: 10.24.33.187:54194
db: NULL
Command: Sleep
Time: 176
State:
Info: NULL
*************************** 2. row ***************************
Id: 4
User: root
Host: 10.24.33.187:54195
db: NULL
Command: Sleep
Time: 176
State:
Info: NULL
*************************** 3. row ***************************
Id: 8
User: root
Host: localhost
db: test
Command: Query
Time: 0
State: starting
Info: show processlist
*************************** 4. row ***************************
Id: 12
User: repl
Host: dsz884.hcg.homecredit.net:39731
db: NULL
Command: Binlog Dump --Binlog Dump線程
Time: 87
State: Master has sent all binlog to slave; waiting for more updates --由此可見，以“推送”的方式同步
Info: NULL
4 rows in set (0.00 sec)
ERROR:
No query specified
查看備庫：
mysql> show processlist\G;
*************************** 1. row ***************************
Id: 1
User: system user
Host:
db: NULL
Command: Connect
Time: 4427
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 2
User: system user
Host:
db: NULL
Command: Connect
Time: 2044
State: Slave has read all relay log; waiting for more updates
Info: NULL
由此可見，MySQL復(fù)制是異步的，從庫和主庫存在一定的延時。
復(fù)制相關(guān)的日志
1、BinlogBinlog會記錄mysql中所有的數(shù)據(jù)修改操作，可以通過如下方式查看Binlog的格式，對應(yīng)有三種，分別為Statement、Row和Mixed：
mysql> show variables like '%binlog_format%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 row in set (0.00 sec)
2、Relay LogRelay Log的文件格式、內(nèi)容和Binlog一樣，唯一區(qū)別是從庫上的SQL線程執(zhí)行完當前Relay Log中的事件后，SQL線程會自動刪除該Relay Log，從而釋放空間。為保證從庫Crash重啟后，從庫的I/O線程和SQL線程仍能知道從哪里開始復(fù)制，從庫默認會創(chuàng)建兩個日志文件master.info和relay-log.info來保存復(fù)制的進度，這兩個文件分別記錄了從庫的I/O線程當前讀取主庫Binlog的進度和SQL線程應(yīng)用Relay Log的進度。
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.24.33.186 --主庫IP
Master_User: repl --主庫用于主從復(fù)制的用戶賬號
Master_Port: 3306 --主庫端口
Connect_Retry: 60
Master_Log_File: mysql-bin.000005 --從庫I/O線程當前讀取主庫Binlog文件名
Read_Master_Log_Pos: 4356 --從庫I/O線程讀取主庫Binlog的位置
Relay_Log_File: strong-relay-bin.000006 --SQL線程正在應(yīng)用的Relay Log
Relay_Log_Pos: 320 --Relay Log的位置
Relay_Master_Log_File: mysql-bin.000005 --Relay Log對應(yīng)的Binlog
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 4356 --SQL線程正在應(yīng)用Relay Log的位置對應(yīng)的Binlog的位置
Relay_Log_Space: 1153
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 2a3e3fd9-0587-11e8-bdb8-0800272325a8
Master_Info_File: /usr/local/mysql-5.7.21-el7-x86_64/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
ERROR:
No query specified
mysql>
MySQL復(fù)制方式
Binlog的格式有三種，分別對應(yīng)了MySQL復(fù)制的3種技術(shù)。
MySQL復(fù)制架構(gòu)
MySQL復(fù)制的常見架構(gòu)有一主多從復(fù)制架構(gòu)、多級復(fù)制架構(gòu)和雙主復(fù)制（Dual Master）架構(gòu)。
1、一主多從架構(gòu)在主庫讀請求壓力非常大的場景下，通過配置一主多從復(fù)制架構(gòu)實現(xiàn)讀寫分離，把對實時性要求不是特別高的讀取請求通過負載均衡分布到多個從庫上，從而降低主庫的讀取壓力，如圖：
2、多級復(fù)制架構(gòu)一主多從架構(gòu)能解決大部分讀請求壓力特別大的場景的需求，由于MySQL的復(fù)制是主庫推送Binlog到從庫，主庫的I/O壓力和網(wǎng)絡(luò)壓力會隨著從庫的增加而增加（每個從庫都會在主庫上有一個獨立的Binlog Dump線程來發(fā)送Binlog事件），而多級復(fù)制架構(gòu)解決了一主多從場景下，主庫額外的I/O和網(wǎng)絡(luò)壓力的場景，如圖：
3、雙主復(fù)制/Dual Master架構(gòu)雙主復(fù)制/Dual Master架構(gòu)特別適合于DBA做維護需要主從切換的場景，通過該架構(gòu)避免了重復(fù)搭建從庫的麻煩，如圖：
您可能感興趣的文章:- 分析MySQL復(fù)制以及調(diào)優(yōu)原理和方法
- Linux下MySQL數(shù)據(jù)庫的主從同步復(fù)制配置
- 詳解Docker方式實現(xiàn)MySql 主從復(fù)制（實踐篇）
- Mysql中復(fù)制詳細解析
- MySQL高可用解決方案MMM(mysql多主復(fù)制管理器)
- MySQL5.7.18主從復(fù)制搭建(一主一從)教程詳解
- Mysql5.7.18的安裝與主從復(fù)制圖文詳解
- 詳解MySQL實現(xiàn)主從復(fù)制過程
- 利用pt-heartbeat監(jiān)控MySQL的復(fù)制延遲詳解
- 詳解MySQL主從復(fù)制讀寫分離搭建
- 詳解如何利用docker快速構(gòu)建MySQL主從復(fù)制環(huán)境
- 簡單談?wù)凪ySQL的半同步復(fù)制
