搭建基于binlog方式的主從架構詳細步驟

下文主要給大家帶來搭建基于binlog方式的主從架構詳細步驟，希望這些內容能夠帶給大家實際用處，這也是我編輯搭建基于binlog方式的主從架構詳細步驟這篇文章的主要目的。好了，廢話不多說，大家直接看下文吧。

基于binlog方式的主從架構，也可稱為傳統的異步復制方式。

環境：

主從復制原理圖：

主從復制原理：

通過三個線程來實現。

Master，通過dump thread，將數據更改操作記錄到binary log（這些記錄叫做binary log events）

Slave，IO thread，將Master的binary log復制到自己的relay log中

Slave，SQL thread，從Slave的realy log中讀取并重放這些記錄

主從復制的應用場景：

1、Slave作為Master的數據備份

當Master出現問題時，人工或自動切換到Slave主機，保證服務不間斷

2、Master和Slave做讀寫分離，Slave實現負載均衡，將讀寫流量分離

我這里引入網站找到的一張圖片

3、在讀寫分離架構下，將多個Slave根據業務進行拆分

在這里引入從網上找到的一張圖片

主從搭建配置：

1、修改my.cnf配置

Master主機配置：

cat /home/data/mysql3306/my.cnf

server_id = 2

log_bin = /home/data/mysql3306/mysql-bin

上面兩個是必須配置的，其他參數根據自己的MySQL安裝目錄和業務情況自行配置

Slave主機配置：

cat /home/data/mysql3306/my.cnf

server_id = 1

Slave主機的binlog不是必須開啟的，其他參數根據自己的MySQL安裝目錄和業務情況自行配置，如果有級聯復制的需求，才進行開啟，一般主從架構不開啟，以節省磁盤I/O

2、授權復制連接用戶

mysql> grant replication slave on *.*to repliter@'192.168.32.2' identified by PASSWORD ' *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9';

推薦先將密碼進行加密（password()函數）后，再進行授權的方式，這樣明文密碼就不會記錄到binglog中，減少風險

3、配置主從復制過濾規則

如果我們的業務數據拆分到了各個Slave上，比如：Slave1主機只需要復制論壇（bbs）的數據，Slave2只需要復制在線課堂（edusoho_e）的數據等等，這種情況下，我們就需要配置主從復制的過濾規則，只選擇Slave主機需要復制的數據。有兩種過濾規則可以進行配置。當然了，也可以不進行配置，直接同步所有的數據至Slave

Master主機上配置主從復制過濾規則：

cat /home/data/mysql3306/my.cnf

binlog-do-db=bailidb（更多過濾規則請閱讀MySQL官網）

注意：需要重啟MySQL

更新數據前，先看看position位置

mysql> show master status\G;

*************************** 1. row ***************************

             File: mysql-bin.000006

         Position: 120

     Binlog_Do_DB: bailidb

插入一條非過濾規則數據庫的數據：

INSERT INTO `backup`.`vip_1` (`sname`) VALUES ('Python');

mysql> show master status\G;

*************************** 1. row ***************************

             File: mysql-bin.000006

         Position: 120

     Binlog_Do_DB: bailidb

position位置沒有變動

更新一條符合過濾規則數據庫的數據：

UPDATE `bailidb`.`bl_admin` SET `username` = 'heihei' WHERE `userid` = '40';

mysql> show master status\G;

*************************** 1. row ***************************

             File: mysql-bin.000006

         Position: 562

     Binlog_Do_DB: bailidb

position位置變動，說明配置已經生效了

說明：

雖然Master支持這么做主從過濾規則，但是配置之后，就只能是配置的庫寫入或配置的庫不能寫入binlog中了，隨著業務變動，一些原來不需要復制同步的庫，現在也需要進行復制同步，那么就需要重啟Master數據庫，如果之后業務再變動，還需要重啟Master數據庫，顯然，這么做不夠靈活，而且重啟Master的代價肯定也比重啟Slave大的多的；另一方面，除非十分確定，Master的所有數據變更操作都應該記錄到binlog中，出了問題還能夠據此進行恢復，而不應該對Master做過濾，所以，一般情況下，選擇配置Slave的主從復制過濾規則。

Slave主機上配置主從復制過濾規則：

現在業務需求是，現在的Slave主機上只需要論壇（bbs）、和在線課堂的數據（edusoho_e）的數據

cat /home/data/mysql3306/my.cnf

replicate_do_db=bbs

replicate_do_db=edusoho_e（更多過濾規則請閱讀MySQL官網）

注意：需要重啟MySQL

4、準備復制數據

在Master主機上將bbs、edusoho_e數據備份后，傳輸到Slave主機，進行數據導入，使之和Master數據庫一致

筆者使用的是MySQL自帶的mysqldump工具，此工具，屬于溫備方式，即：備份過程中會鎖庫表，對業務會造成一定的影響，數據量越大，影響越大。筆者比較同意網上同行的經驗，50G以下還是可以用mysqldump工具，50G以上就應該考慮使用如：Xtrabackup等物理備份工具了

mysqldump -uroot -p --single-transaction --master-data=2 --databases bbs edusoho_e > `date +%F`.sql

--single-transaction 保證數據的讀一致性

--master-data=2 將CHANGE MASTER TO信息注釋

參數的具體含義，請mysqldump --help自行查閱

上傳到Slave主機：

可以采用scp、ftp、sz等方式，這里不多說了

創建同名數據庫：

mysql> create database bbs;

Query OK, 1 row affected (0.03 sec)

mysql> create database edusoho_e;

Query OK, 1 row affected (0.00 sec)

5、開啟數據復制

先進行數據導入

mysql -uroot -p < 2019-04-28.sql

再判斷從Master主機的哪里開始進行復制，還記得之前mysqldump的--master-data=2選項嗎，它記錄了我們需要從Master的哪里開始進行復制

more 2019-04-28.sql（注意：千萬別使用vim，如果sql文件大的話，足夠把你內存吃完，使用more分頁查看就已經足夠）

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=120（這是一個注釋信息的樣本）

查看CHANGE MASTER TO語法選項

mysql> help change master to;（不建議背命令，因為沒有必要）

mysql> CHANGE MASTER TO MASTER_HOST='192.168.32.3',MASTER_PORT=3306,MASTER_LOG_FILE='mysql-bin.000007',MASTER_LOG_POS=120;

Query OK, 0 rows affected (0.08 sec)

mysql> start slave user='repliter' password='123456';

這里可能會有人會有疑問，你為什么不在CHANGE MASTER TO的時候加入user和password直接連接呢？分開寫，不是多此一舉嗎？

原因就是：為了安全。

在CHANGE MASTER TO的時候，I/O thread負責維護master.info文件的更新，I/O thread會將Master主機的binlog file和position，還有其他信息，這其中就包括，Slave連接Master主機的用戶名和密碼，以此來實現主從數據同步，那么問題來了，如果CHANGE MASTER TO的時候直接寫user和password，那么同樣會寫進master.info文件中去，這樣大大增加了賬戶泄露的風險，因為此類的賬戶密碼只能是DBA知道，所以，為了賬戶安全，在start slave的時候才指定用戶密碼，這樣user和password信息就不會保存到master.info文件之中了

查看Slave的復制狀態：

mysql> show slave status\G;（對于參數項的具體含義，一定要看MySQL官網，因為網上很多資料都是人家按照自己理解翻譯的，難以有理解出入）這里只看I/O、SQL thread運行狀態

Slave_IO_State: Waiting for master to send event

                  xxx

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

                 xxx

      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

                 xxx

6、數據同步測試：

Master主機變更兩條數據：

INSERT INTO `bbs`.`myhash_0` (`c1`, `c2`, `c5`) VALUES ('1', '2', '3');

UPDATE `edusoho_e`.`biz_targetlog` SET `target_type` = 'trade.sucessfull' WHERE `id` = '5';

然后去看數據同步過來沒有。

題外：

雖然是在做測試，但是筆者認為測試的目的可不僅僅為了測試，測試的目的應該是為了應用到線上做的探路者、前鋒軍，所以，做測試的時候，應該盡可能的考慮，這么做，能否應用到線上？

而不應該圖省事，將過程簡化，如：授權復制連接用戶的時候，筆者見過 root@'%'的復制連接用戶，請問線上也是這么做的么？還有：mysqldump的時候，真的可以在命令行輸入明文密碼么？vim 一個幾十G的文件，真的沒有問題么？應盡可能使用最小權限，使用合適的命令，使云服務器先運行穩定，才是前提。

對于以上關于搭建基于binlog方式的主從架構詳細步驟，大家是不是覺得非常有幫助。如果需要了解更多內容，請繼續關注我們的行業資訊，相信你會喜歡上這些內容的。