MySQL 4种常用的主从复制架构-巨人网络通讯

MySQL 4种常用的主从复制架构

一主多从复制架构

在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量的对实时性要求不是特别高的读请求通过负载均衡分部到多个从库上(对于实时性要求很高的读请求可以让从主库去读)，降低主库的读取压力，如下图所示。

在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务。

在主从复制场景下会出现主从延迟，想想该怎么解决？

多级复制架构

一主多从的架构能够解决大部分读请求压力特别大的的场景的需求，考虑到MySQL的复制需要主库发送BINLOG日志到从库的I/O线程，主库的I/O压力和网络压力会随着从库的增加而增长(每个从库都会在主库上有一个独立的BINLOG Dump线程来发送事件)，而多级复制架构解决了一主多从场景下的，主库额外的I/O和网络压力。MySQL的多级复制架构如下图所示。

对比一主多从的架构，多级复制仅仅是在主库Master1复制到从库Slave1、Slave2、Slave3的中间增加了一个二级主库Master2，这样，主库Master1只需要给一个从库Master2发送BINLOG日志即可，减轻了主库Master1的压力。二级主库Master2再发送BINLOG日志给所有的从库Slave1、Slave2和Slave3的I/O线程。

多级复制解决了一主多从场景下，主库的I/O负载和网络压力，当然也有缺点：MySQL的传统复制是异步的，多级复制场景下主库的数据是经历两次复制才到达从库Slave1、Slave2、Slave3的，期间的延迟要比一主多从复制场景下只经历一次复制的还大。

可以通过在二级主库Master2上选择表引擎为BLACKHOLE来降低多级复制的延迟。顾名思义，BLACKHOLE引擎是一个“黑洞”引擎，写入BLACKHOLE表的数据并不会写会到磁盘上，BLACKHOLE表永远都是空表，INSERT、UPDATE、DELETE操作仅仅在BINLOG中记录事件。

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;
INSERT INTO `user` (`name`,`age`) values("itbsl", "26");
SELECT * FROM `user`;

可以看到，存储引擎为BLACKHOLE的user表里没有数据。

BLACKHOLE引擎非常适合二级主库Masger2的场景:Master2并不承担读写请求，仅仅负责将BINLOG日志尽快传送给从库。

双主(Dual Master)复制架构

双主(Dual Master)复制架构适用于DBA做维护时需要主从切换的场景，通过双主复制架构避免了重复搭建从库的麻烦，双主复制架构如下图所示。

主库Master1和Master互为主从，所有Web Client的写请求都访问主库Master1或Master2。加入，DBA需要做日常维护操作，为了避免影响服务，需进行一下操作。

首先，在Master1库上停止Slave线程(STOP SLAVE)，避免后续对Master2库的维护操作操作被实时复制到Master1库上对服务造成影响。
其次，在Master2库上停止Slave线程(STOP SLAVE)，开始日常维护操作，例如修改varchar字段从长度10增加到200。
然后，在Master2库上完成维护操作之后，打开Master2库上的Slave线程(STRART SLAVE),让Master2的数据和Master1库同步，同步完成后，把应用的写操作切换到Master2库上。
最后，确认Master1库上没有应用访问后，打开Master1的Slave线程(START SLAVE)即可。

通过双主复制架构能够大大减轻一主多从架构下对主库进行维护带来的额外搭建从库的工作。

当然双主架构还能和主从复制联合起来使用：在Master2库下配置从库Slave1、Slave2等，这样既可通过从库Slave1等来分担读取压力，同时在DBA做维护的同时，避免了重建从库的额外工作，但需要注意从库的复制延迟。MySQL双主多级复制架构如下所示。