<返回更多

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

2021-07-26    Java码农之路
加入收藏

目录

复制的4中常见架构有一主多从复制架构多级复制架构双主(Dual Master)复制架构多源(Multi-Source)复制架构

一主多从复制架构

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

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

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

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

 

多级复制架构

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

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

 

对比一主多从的架构,多级复制仅仅是在主库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`;
MySQL常用的4种主从复制架构

 

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

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

双主(Dual Master)复制架构

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

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

 

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

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

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

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

 

多源(Multi-Source)复制架构

多源(Multi-Source)复制架构适用于复杂的业务需求,既可以支撑OLTP(联机事务处理),也可以满足OLAP(联机分析处理)。MySQL的多源复制架构我就暂时不画啦,等有空再画好补充上(画图也是个体力活呀)。有兴趣的可以看《深入浅出MySQL数据库开发、优化与管理维护》这本书。

如何优化主从延迟问题?

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>