怎么掌握MySQL復制架構

142次閱讀

沒有評論

共計 5081 個字符，預計需要花費 13 分鐘才能閱讀完成。

本文丸趣 TV 小編為大家詳細介紹“怎么掌握 MySQL 復制架構”，內容詳細，步驟清晰，細節處理妥當，希望這篇“怎么掌握 MySQL 復制架構”文章能幫助大家解決疑惑，下面跟著丸趣 TV 小編的思路慢慢深入，一起來學習新知識吧。

一主多從復制架構

在實際應用場景中，MySQL 復制 90% 以上都是一個 Master 復制到一個或者多個 Slave 的架構模式。

在主庫讀取請求壓力非常大的場景下，可以通過配置一主多從復制架構實現讀寫分離，把大量的對實時性要求不是特別高的讀請求通過負載均衡分部到多個從庫上（對于實時性要求很高的讀請求可以讓從主庫去讀），降低主庫的讀取壓力，如下圖所示。

缺點：

master 不能停機，停機就不能接收寫請求

slave 過多會出現延遲

由于 master 需要進行常規維護停機了，那么必須要把一個 slave 提成 master，選哪一個是一個問題？

某一個 slave 提成 master 了，就存在當前 master 和之前的 master 數據不一致的情況，并且之前 master 并沒有保存當前 master 節點的 binlog 文件和 pos 位置。

多主復制架構

多主復制架構解決了一主多從復制架構中 master 的單點故障問題。

可以配合一個第三方的工具，比如 keepalived 輕松做到 IP 的漂移，這樣 master 停機維護也不會影響寫操作。

級聯復制架構

一主多從中如果 slave 過多，會導致主庫的 I / O 壓力和網絡壓力會隨著從庫的增加而增長，因為每個從庫都會在主庫上有一個獨立的 BINLOG Dump 線程來發送事件，而級聯復制架構解決了一主多從場景下的，主庫額外的 I / O 和網絡壓力。

如下圖所示。

對比一主多從的架構，級聯復制僅僅是從主庫 Master 復制到少量的從庫，其他從庫再從這少量的從庫中復制數據，這樣就減輕了主庫 Master 的壓力。

當然也有缺點：MySQL 的傳統復制是異步的，級聯復制場景下主庫的數據是經歷兩次復制才到達其他從庫中，期間的延遲要比一主多從復制場景下只經歷一次復制的還大。

可以通過在二級 slave 上選擇表引擎為 BLACKHOLE 來降低級聯復制的延遲。顧名思義，BLACKHOLE 引擎是一個“黑洞”引擎，寫入 BLACKHOLE 表的數據并不會寫會到磁盤上，BLACKHOLE 表永遠都是空表，INSERT、UPDATE、DELETE 操作僅僅在 BINLOG 中記錄事件。

下面演示下 BLACKHOLE 引擎：

mysql  CREATE TABLE `user` (
 -  `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
 -  `name` varchar(255) NOT NULL DEFAULT  ,
 -  `age` tinyint unsigned NOT NULL DEFAULT 0
 -  )ENGINE=BLACKHOLE charset=utf8mb4;Query OK, 0 rows affected (0.00 sec)mysql  INSERT INTO `user` (`name`,`age`) values(itbsl ,  26 Query OK, 1 row affected (0.00 sec)mysql  select * from user;Empty set (0.00 sec)

可以看到，存儲引擎為 BLACKHOLE 的 user 表里沒有數據。

多主與級聯復制結合架構

結合多主與級聯復制架構，這樣解決了單點 master 的問題，解決了 slave 級聯延遲的問題。

多主復制架構的搭建

主機規劃：

master1：docker，端口 3314

master2：docker，端口 3315

master1 的配置

配置文件 my.cnf：

$ cat /home/mysql/docker-data/3315/conf/my.cnf
[mysqld]
character_set_server=utf8
init_connect= SET NAMES utf8 
symbolic-links=0
lower_case_table_names=1
server-id=1403314
log-bin=mysql-bin
binlog-format=ROW
auto_increment_increment=2 #  幾個主庫，這里就配幾
auto_increment_offset=1 #  每個主庫的偏移量需要不一致
gtid_mode=ON
enforce-gtid-consistency=true
binlog-do-db=order #  要同步的數據庫

啟動 docker：

$ docker run --name mysql3314 -p 3314:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3314/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3314/data/:/var/lib/mysql -v /home/mysql/docker-data/3314/logs/:/var/log/mysql -d mysql:5.7

添加用于復制的用戶并授權：

mysql  GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO  repluser @ %  IDENTIFIED BY  123456 
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql  FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

開啟同步 master1（這里的 user 來自 master2）：

mysql  change master to master_host= 172.23.252.98 ,master_port=3315,master_user= repluser ,master_password= 123456 ,master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.03 sec)
mysql  start slave;
Query OK, 0 rows affected (0.00 sec)

master2 的配置

master2 的配置與 master1 類似。

主要區別在于 my.cnf 中有一個屬性需要不一致：

auto_increment_offset=2 #  每個主庫的偏移量需要不一致

測試：

在 master2 創建表，并添加數據：

mysql  create table t_order(id int primary key auto_increment, name varchar(20));
Query OK, 0 rows affected (0.01 sec)
mysql  insert into t_order(name) values( A 
Query OK, 1 row affected (0.01 sec)
mysql  insert into t_order(name) values( B 
Query OK, 1 row affected (0.00 sec)
mysql  select * from t_order;
+----+------+
| id | name |
+----+------+
| 2 | A |
| 4 | B |
+----+------+
2 rows in set (0.00 sec)

可以發現 master2 中 id 的步長為 2，且從 2 開始自增。

然后在 master1 查詢數據，并添加：

mysql  select * from t_order;
+----+------+
| id | name |
+----+------+
| 2 | A |
| 4 | B |
+----+------+
2 rows in set (0.00 sec)
mysql  insert into t_order(name) values( E 
Query OK, 1 row affected (0.00 sec)
mysql  select * from t_order;
+----+------+
| id | name |
+----+------+
| 2 | A |
| 4 | B |
| 5 | E |
+----+------+
3 rows in set (0.00 sec)

可以發現 master1 中 id 的步長為 2，且從 1 開始自增，再去 master2 中查詢能發現 id 為 5 的數據，說明主主復制配置沒有問題。

為什么兩個主中 id 自增的偏移量要不一致呢？當兩個主同時接受到插入請求時就能保證 id 不沖突，其實這樣只能保證插入數據不沖突，無法保證刪除和修改導致的數據不一致。

所以在實際的應用場景中，只能暴露一個主給客戶端才能保證數據的一致性。

MySQL 高可用的搭建

這里借助 keepalived 來對上面的多主復制架構改造來實現 MySQL 的高可用。

keepalived 的安裝：

$ sudo apt-get install -y keepalived

keepalived.conf

$ cat /etc/keepalived/keepalived3314.conf! Configuration File for keepalived# 簡單的頭部，這里主要可以做郵件通知報警等的設置，此處就暫不配置了；global_defs { #notificationd LVS_DEVEL}# 預先定義一個腳本，方便后面調用，也可以定義多個，方便選擇；vrrp_script chk_haproxy {
 script  /etc/keepalived/chkmysql.sh  # 具體腳本路徑
 interval 2 # 腳本循環運行間隔 }#VRRP 虛擬路由冗余協議配置 vrrp_instance VI_1 { #VI_1  是自定義的名稱； state BACKUP #MASTER 表示是一臺主設備，BACKUP 表示為備用設備【我們這里因為設置為開啟不搶占，所以都設置為備用】 nopreempt # 開啟不搶占
 interface eth0 # 指定 VIP 需要綁定的物理網卡
 virtual_router_id 11 #VRID 虛擬路由標識，也叫做分組名稱，該組內的設備需要相同
 priority 130 # 定義這臺設備的優先級  1-254；開啟了不搶占，所以此處優先級必須高于另一臺
 advert_int 1 # 生存檢測時的組播信息發送間隔，組內一致
 authentication { # 設置驗證信息，組內一致
 auth_type PASS # 有 PASS  和  AH  兩種，常用  PASS
 auth_pass asd # 密碼
 }
 virtual_ipaddress {
 172.23.252.200 # 指定 VIP 地址，組內一致，可以設置多個 IP
 }
 track_script { # 使用在這個域中使用預先定義的腳本，上面定義的
 chk_haproxy }
 #notify_backup  /etc/init.d/haproxy restart  # 表示當切換到 backup 狀態時, 要執行的腳本
 #notify_fault  /etc/init.d/haproxy stop  # 故障時執行的腳本 }

/etc/keepalived/chkmysql.sh

$ cat /etc/keepalived/chkmysql.s.sh#!/bin/bashmysql -uroot -proot -P 3314 -e  show status;    /dev/null 2 1if [ $? == 0 ];then
 echo  $host mysql login successfully 
 exit 0else
 echo  $host login failed 
 killall keepalived exit 2fi

讀到這里，這篇“怎么掌握 MySQL 復制架構”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注丸趣 TV 行業資訊頻道。

正文完