共计 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 keepalivedkeepalived.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 行业资讯频道。
