完全掌握MySQL複製架構-mysql教程-PHP中文網

本篇文章為大家帶來了關於mysql的相關知識，其中主要介紹了關於複製架構的相關問題，包括了主從複製架構、聯級複製架構、多主從複製架構的搭建等等，希望對大家有幫助。

完全掌握MySQL複製架構

推薦學習：mysql影片教學

#一主多從複製架構

在實際應用情境中，MySQL複製90%以上都是一個Master複製到一個或多個Slave的架構模式。

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

完全掌握MySQL複製架構

缺點：

master不能停機，停機就不能接收寫入請求
slave過多會延遲

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

某一個slave提成master了，就存在當前master和之前的master資料不一致的情況，並且之前master並沒有保存當前master節點的binlog檔案和pos位置。

多主複製架構

多主複製架構解決了第一主多從複製架構中master的單點故障問題。

完全掌握MySQL複製架構

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

級聯複製架構

一主多從中如果slave過多，會導致主庫的I/O壓力和網路壓力會隨著從庫的增加而增長，因為每個從函式庫都會在主函式庫上有一個獨立的BINLOG Dump執行緒來傳送事件，而級聯複製架構解決了一主多從場景下的，主函式庫額外的I/O和網路壓力。

如下圖所示。

完全掌握MySQL複製架構

對比一主多從的架構，級聯複製只是從主庫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級聯延遲的問題。

完全掌握MySQL複製架構

多主複製架構的建置

主機規劃：

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高可用的搭建

完全掌握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视频教程

以上是完全掌握MySQL複製架構的詳細內容。更多資訊請關注PHP中文網其他相關文章！