一. 簡介
MySQL自帶復制方案,帶來好處有:
數(shù)據(jù)備份。
負載均衡。
分布式數(shù)據(jù)。
概念介紹:
主機(master):被復制的數(shù)據(jù)庫。
從機(slave):復制主機數(shù)據(jù)的數(shù)據(jù)庫。
復制步驟:
(1). master記錄更改的明細,存入到二進制日志(binary log)。
(2). master發(fā)送同步消息給slave。
(3). slave收到消息后,將master的二進制日志復制到本地的中繼日志(relay log)。
(4). slave重現(xiàn)中繼日志中的消息,從而改變數(shù)據(jù)庫的數(shù)據(jù)。
下面放一張經(jīng)典的圖片來說明這一過程:
![](/d/20211018/1069a0a9f36025c0bd4af3953e86959d.gif)
二. 實現(xiàn)復制
實現(xiàn)復制有以下步驟:
1.設(shè)置MySQL主庫的二進制日志以及server-id
MySQL配置文件一般存放在/etc/my.cnf
# 在[mysqld]下面添加配置選項
[mysqld]
server-id=1
log-bin=mysql-bin.log
server-id是數(shù)據(jù)庫在整個數(shù)據(jù)庫集群中的唯一標示,必須保持唯一。
重啟MySQL。
注:如果MySQL配置文件中已經(jīng)配置過此文件,則可以跳過此步。
2.新建復制賬號
在主庫里面新建用于從庫復制主庫數(shù)據(jù)的賬號,并授予復制權(quán)限。
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO user_name@'host' IDENTIFIED BY 'password';
3.設(shè)置MySQL主庫server-id
和第二步配置一樣,要注意的地方有兩點:
如果不需要從庫作為別的從庫的主庫的話,則不需要配置二進制日志。很多時候復制并不需要復制主庫的全部數(shù)據(jù)庫(特別是mysql的信息配置庫)。因此可以配置replicate_do_db來指定復制的數(shù)據(jù)庫 4.從庫初始化主庫的數(shù)據(jù)
如果數(shù)據(jù)量不算大的情況下,可以使用mysqldump工具導出主庫數(shù)據(jù),然后導入到從庫里面。
mysqldump --single-transaction --triggers --master-data databasename > data.sql
如果數(shù)據(jù)量大的情況下應該使用Xtrabackup去進行數(shù)據(jù)庫的導出,此處不做介紹。
可能會有同學問,為什么不直接使用二進制日志進行初始化呢?
如果我們主庫運行了比較長的一段時間,并不太適合使用從庫根據(jù)二進制日志進行復制數(shù)據(jù),直接使用二進制日志去初始化從庫會比較耗費時間和性能。更多的情況下,主庫的二進制日志的配置項沒有打開,因此也就不存在以前操作的二進制日志。 5.開啟復制
從庫執(zhí)行下面命令
mysql> CHANGE MASTER TO MASTER_HOST='host',
-> MASTER_USER='user',
-> MASTER_PASSWORD='password',
-> MASTER_LOG_FILE='mysql-bin.000001',
-> MASTER_LOG_POS=0;
注意最后的兩個命令:MASTER_LOG_FILE和MASTER_LOG_POS,表示從庫的從哪個二進制文件開始讀取,偏移量從那里開始,這兩個參數(shù)可以從我們導入的SQL里面找到。
![](/d/20211018/5a01615346df84445f413b559a8126cc.gif)
開啟復制
這時候就完成了復制,在主庫更新一個數(shù)據(jù)或者新增數(shù)據(jù)在從庫都可以查詢到結(jié)果。
![](/d/20211018/77ed0f50add35296d37101e4728606e7.gif)
在主庫上也可以查詢的到復制線程的狀態(tài)。
![](/d/20211018/125f0d9b343d064c0a5eddbae65935c8.gif)
三. 復制的日志格式
MySQL復制的日志格式有三種,根據(jù)主庫存放數(shù)據(jù)的方式不同有以下三種:
row |
基于行的格式復制,記錄需要修改的每行的數(shù)據(jù)信息。 如果一個SQL修改了2w行的數(shù)據(jù),那么就會記錄2w行的日志格式 |
保證了數(shù)據(jù)的強一致性,且由于記錄的是執(zhí)行后的結(jié)果,在從庫上執(zhí)行還原也會比較快 |
日志記錄數(shù)量很多,主從之間的傳輸需要更多的時間。 |
statement |
基于段的日志格式復制,也就是記錄下更改的SQL記錄,而不是更改的行的記錄。 |
日志記錄量最小。 |
對于一些輸出結(jié)果不確定的函數(shù),在從庫上執(zhí)行一遍很可能會出現(xiàn)問題,如uuid,從庫根據(jù)日志還原主庫數(shù)據(jù)的時候需要執(zhí)行一遍SQL,時間相對較慢。 |
mixed |
混合上面兩種日志格式記錄記錄日志,至于什么時候使用哪種日志方式由MySQL本身決定。 |
可以平衡上面兩種日志格式的優(yōu)缺點。 |
|
mysql5.7以前默認使用statement格式。
設(shè)置方式,可以在配置文件設(shè)置(首選):
或臨時設(shè)置全局變量(當前mysql連接有效):
查看日志格式
mysql > show variables like 'binlog_format';
設(shè)置日志格式
mysql > set binlog_format='row';
由于兩個主從服務(wù)器一般都會放在同一個機房里面,兩者之間同步的速度會會比較快,為保證強一致性,應該首選行的日志格式記錄(row),保證傳輸素速度可以選擇混合方式(mixed)。
而行的日志格式有下面三種記錄方式:
minimal |
只記錄被修改列的數(shù)據(jù) |
full |
記錄被修改的行的全部列的數(shù)據(jù) |
noblob |
特點同上,只是如果沒有修改blob和text類型的列的情況下,不會記錄這些列的數(shù)據(jù)(也就是大數(shù)據(jù)列) |
|
mysql默認是full,最好修改成minimal。
四. 主從復制延遲
由于主庫和從庫之間不在同一個主機上,數(shù)據(jù)同步之間不可以避免地具有延遲,解決的方法有添加緩存,業(yè)務(wù)層的跳轉(zhuǎn)等待,如果非得從數(shù)據(jù)庫層面去減緩延遲問題,可以從復制時候的三大步驟(主庫產(chǎn)生日志,主從傳輸日志,從庫還原日志內(nèi)容)入手:
1.主庫寫入到日志的速度
控制主庫的事務(wù)大小,分割大事務(wù)為多個小事務(wù)。
如插入20w的數(shù)據(jù),改成插入多次5000行(可以利用分頁的思路)
2.二進制日志在主從之間傳輸時間
主從之間盡量在同一個機房或地域。
日志格式改用MIXED,且設(shè)置行的日志格式未minimal,原理詳見上面的日志格式介紹。
3.減少從庫還原日志的時間
在MySQL5.7版本后可以利用邏輯時鐘方式分配SQL多線程。
設(shè)置邏輯時鐘:slave_parallel_type=‘logical_clock';
設(shè)置復制線程個數(shù):slave_parallel_workers=4;
五. 需要注意的地方
重啟MySQL最好切換未MySQL用戶再進行操作,不然文件啟動后會有權(quán)限問題。搭建好MySQL的環(huán)境后就設(shè)置好配置里的log-bin選項,這樣以后如果數(shù)據(jù)庫需要從庫的復制,就不需要重啟數(shù)據(jù)庫,打斷業(yè)務(wù)的進行。需要打開主庫的防火墻的對應的mysql端口。由于從庫同步主庫的方式,監(jiān)聽主庫發(fā)送的信息,而不是輪詢,因此如果出現(xiàn)通信出現(xiàn)了故障,重新連接后如果主庫沒有進行數(shù)據(jù)更改的操作,從庫不會同步數(shù)據(jù),因此可以通過插入空事務(wù)的方式同步數(shù)據(jù)。
以上就是小編本次整理的全部內(nèi)容,感謝你對腳本之家的支持。
您可能感興趣的文章:- Linux下MySQL數(shù)據(jù)庫的主從同步復制配置
- 詳解Docker方式實現(xiàn)MySql 主從復制(實踐篇)
- Mysql中復制詳細解析
- MySQL高可用解決方案MMM(mysql多主復制管理器)
- MySQL5.7.18主從復制搭建(一主一從)教程詳解
- Mysql5.7.18的安裝與主從復制圖文詳解
- 詳解MySQL實現(xiàn)主從復制過程
- 利用pt-heartbeat監(jiān)控MySQL的復制延遲詳解
- 詳解MySQL主從復制讀寫分離搭建
- 詳解如何利用docker快速構(gòu)建MySQL主從復制環(huán)境
- 簡單談?wù)凪ySQL的半同步復制
- MySQL復制優(yōu)點、原理詳解