主從復(fù)制很早以前就配置過了，近來重新整理的時候發(fā)現(xiàn)以前部署的主從有些步驟是多余，現(xiàn)在重新寫個文檔記錄下主從復(fù)制的流程。這里分為兩種情況，一是主從都是空白的庫，二是主庫已經(jīng)有數(shù)據(jù)了。實驗的MySQL版本為5.7.30.
1. 實驗的架構(gòu)
部署的架構(gòu)非常簡單，只需要準(zhǔn)備兩臺虛擬機，上面部署同樣版本的MySQL。如何部署MySQL就不做介紹，我這里使用的是RPM包的方式來安裝的。
我們知道MySQL的主從復(fù)制依賴于binlog日志，所以我們需要開啟binlog日志。需要注意的主從的server_id的值一定不能一樣，否則會報錯,報錯的內(nèi)容如下所示：
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
最后兩臺機器上的配置文件中關(guān)于binlog日志相關(guān)的配置對比如下,他們只有server_id的區(qū)別而已。
主：
log_bin=mysql-bin
server_id=1
binlog_format=ROW
expire_logs_days = 15
從：
log_bin=mysql-bin
server_id=2
binlog_format=ROW
expire_logs_days = 15
下面分開兩種情況來介紹部署的步驟，他們之間會略有差異。
2. 兩個空白的數(shù)據(jù)庫
如果主從數(shù)據(jù)庫都是剛剛部署完成的，里面完全沒有數(shù)據(jù),所以直接在從庫上配置主從復(fù)制即可。
1 查看主庫的狀態(tài)，獲取當(dāng)前binlog日志的文件名稱和位置點。
show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 734 | | | |
+------------------+----------+--------------+------------------+-------------------+
- 創(chuàng)建一個專門用于主從復(fù)制的賬號，該操作在主庫上執(zhí)行。
grant replication slave on *.* to 'rep'@'10.1.10.%' identified by '123456';
flush privileges;
- 在從庫上配置主從復(fù)制，下面的信息都是來自前面的兩步
CHANGE MASTER TO
MASTER_HOST='10.1.10.52',
MASTER_PORT=43306,
MASTER_USER='rep',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=734;
- 在從庫上開啟復(fù)制，檢查主從復(fù)制的狀態(tài)
-- 開始進行主從復(fù)制
start slave;
-- 查看主從復(fù)制的狀態(tài)
show slave status \G;
最后能在輸出中看到當(dāng)前主從復(fù)制的狀態(tài)，這里要注意三個參數(shù),他們分別是主從復(fù)制的IO進程、主從復(fù)制的SQL進程以及主從復(fù)制的延遲。
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
如果兩個進程都是Yes，那就證明主從復(fù)制沒問題。如果Seconds_Behind_Master不為0，那就是從庫和主庫還沒有完全一致，還在同步中。
- 驗證，在主庫中創(chuàng)建表或者插入數(shù)據(jù)，然后檢查從庫中是否也有這樣的結(jié)果。
注： 如果主從復(fù)制的時候不想要把rep這個賬戶也同步過來，可以把1和2的步驟調(diào)換。這里你應(yīng)該可以猜到了， 使用這種方式配置的主從，從庫的賬戶可以和主庫不一樣的。但是我們還是建議從庫和主庫完全一致，這樣主庫出問題的時候也好用從庫來進行恢復(fù)。
3. 主庫有數(shù)據(jù)
如果主數(shù)據(jù)庫已經(jīng)有了數(shù)據(jù)，那么我們需要把主庫的數(shù)據(jù)導(dǎo)出，然后在從庫上導(dǎo)入，最后再配置主從復(fù)制。
- 創(chuàng)建一個專門用于主從復(fù)制的賬號，該操作在主庫上執(zhí)行。
grant replication slave on *.* to 'rep'@'10.1.10.%' identified by '123456';
flush privileges;
- 導(dǎo)出主庫的數(shù)據(jù)，注意這里使用 --master-data=1 的參數(shù)，這樣導(dǎo)出來的SQL文件會記錄binlog日志文件的名稱和位置。
mysqldump -uroot -p -h10.1.10.52 -P3306 -A -B -F --master-data=1 --single-transaction > all_20210810.sql
- 在從庫上配置主從復(fù)制，這里不需要配置binlog日志文件名稱和位置
CHANGE MASTER TO
MASTER_HOST='10.1.10.52',
MASTER_PORT=3306,
MASTER_USER='rep',
MASTER_PASSWORD='123456';
- 在從庫上導(dǎo)入剛剛導(dǎo)出的SQL文件
mysql -uroot -p -h10.1.10.53 -P3306 < all_20210810.sql
- 在從庫上開啟復(fù)制，檢查主從復(fù)制的狀態(tài)
-- 開始進行主從復(fù)制
start slave;
-- 查看主從復(fù)制的狀態(tài)
show slave status \G;
- 驗證，在主庫中創(chuàng)建表或者插入數(shù)據(jù)，然后檢查從庫中是否也有這樣的結(jié)果。
注：由于我們導(dǎo)出主庫的數(shù)據(jù)是導(dǎo)出全部的庫，所以系統(tǒng)庫也會被導(dǎo)出。最后導(dǎo)入到從庫的時候，會覆蓋掉從庫的系統(tǒng)庫,也就是說從庫的賬戶密碼會和主庫的完全一致。如果你不想這么來，你可以只導(dǎo)出需要同步的數(shù)據(jù)庫，然后配置只同步某個庫，操作方法這里不做介紹。
