多级复制架构

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

对比一主多从的架构，多级复制仅仅是在主库 Master1 复制到从库 Slave1、Slave2、Slave3 的中间增加一个二级主库 Master2，这样，主库 Master1 只需要给一个从库 Master2 “推送” Binlog 日志皆可，减轻主库 Master1 推送的压力。二级主库 Master2 再“推送” Binlog 日志给从库 Slave1、Slave2、Slave3。

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

提示

可以通过在二级主库 Master2 上选择表引擎为 BLACKHOLE 来降低多级复制的延时。

顾名思义，BLACKHOLE 引擎是一个“黑洞”引擎，写入 BLACKHOLE 表的数据并不会写回到磁盘上，BLACKHOLE 表永远都是一个空表，INSERT/UPDATE/DELETE 操作仅仅在 Binlog 中记录事件。