在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量的对实时性要求不是特别高的读请求通过负载均衡分部到多个从库上(对于实时性要求很高的读请求可以让从主库去读)，降低主库的读取压力，如下图所示。
在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务。
在主从复制场景下会出现主从延迟，想想该怎么解决？
一主多从的架构能够解决大部分读请求压力特别大的的场景的需求，考虑到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)复制架构适用于DBA做维护时需要主从切换的场景，通过双主复制架构避免了重复搭建从库的麻烦，双主复制架构如下图所示。
主库Master1和Master互为主从，所有Web Client的写请求都访问主库Master1或Master2。加入，DBA需要做日常维护操作，为了避免影响服务，需进行一下操作。
通过双主复制架构能够大大减轻一主多从架构下对主库进行维护带来的额外搭建从库的工作。
当然双主架构还能和主从复制联合起来使用：在Master2库下配置从库Slave1、Slave2等，这样既可通过从库Slave1等来分担读取压力，同时在DBA做维护的同时，避免了重建从库的额外工作，但需要注意从库的复制延迟。MySQL双主多级复制架构如下所示。
多源(Multi-Source)复制架构适用于复杂的业务需求，既可以支撑OLTP(联机事务处理),也可以满足OLAP(联机分析处理)。MySQL的多源复制架构我就暂时不画啦,等有空再画好补充上(画图也是个体力活呀)。有兴趣的可以看《深入浅出MySQL数据库开发、优化与管理维护》这本书。
关于MySQL主从延迟的具体信息，可以看我的另一篇文章聊聊MySQL主从复制的几种复制方式。
整理自：
《深入浅出MySQL数据库开发、优化与管理维护》这本书。
以上就是MySQL 4种常用的主从复制架构的详细内容，更多关于MySQL 主从复制架构的资料请关注脚本之家其它相关文章！
