本篇文章給大家?guī)砹岁P(guān)于mysql的相關(guān)知識，其中主要介紹了關(guān)于復制架構(gòu)的相關(guān)問題，包括了主從復制架構(gòu)、聯(lián)級復制架構(gòu)、多主從復制架構(gòu)的搭建等等，希望對大家有幫助。

推薦學習：mysql視頻教程

一主多從復制架構(gòu)

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

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

缺點：

• master不能停機，停機就不能接收寫請求
• slave過多會出現(xiàn)延遲

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

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

多主復制架構(gòu)

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

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

級聯(lián)復制架構(gòu)

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

如下圖所示。

對比一主多從的架構(gòu)，級聯(lián)復制僅僅是從主庫Master復制到少量的從庫，其他從庫再從這少量的從庫中復制數(shù)據(jù)，這樣就減輕了主庫Master的壓力。

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

可以通過在二級slave上選擇表引擎為BLACKHOLE來降低級聯(lián)復制的延遲。顧名思義，BLACKHOLE引擎是一個“黑洞”引擎，寫入BLACKHOLE表的數(shù)據(jù)并不會寫會到磁盤上，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表里沒有數(shù)據(jù)。

多主與級聯(lián)復制結(jié)合架構(gòu)

結(jié)合多主與級聯(lián)復制架構(gòu)，這樣解決了單點master的問題，解決了slave級聯(lián)延遲的問題。

多主復制架構(gòu)的搭建

主機規(guī)劃：

• 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      # 要同步的數(shù)據(jù)庫

啟動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

添加用于復制的用戶并授權(quán)：

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類似。

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

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

測試：

在master2創(chuàng)建表，并添加數(shù)據(jù)：

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)

可以發(fā)現(xiàn)master2中id的步長為2，且從2開始自增。

然后在master1查詢數(shù)據(jù)，并添加：

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)

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

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

所以在實際的應(yīng)用場景中，只能暴露一個主給客戶端才能保證數(shù)據(jù)的一致性。

MySQL高可用的搭建

這里借助keepalived來對上面的多主復制架構(gòu)改造來實現(xiàn)MySQL的高可用。

keepalived的安裝：

$ sudo apt-get install -y keepalived

keepalived.conf

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

/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視頻教程