一主多从复制架构
在实际应用场景中，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引擎：
可以看到，存储引擎为blackhole的user表里没有数据。
多主与级联复制结合架构
结合多主与级联复制架构，这样解决了单点master的问题，解决了slave级联延迟的问题。
多主复制架构的搭建
主机规划：
- master1：docker，端口3314
- master2：docker，端口3315
master1的配置
配置文件my.cnf：
启动docker：
添加用于复制的用户并授权：
开启同步master1（这里的user来自master2）：
master2的配置
master2的配置与master1类似。
主要区别在于my.cnf中有一个属性需要不一致：
测试：
在master2创建表，并添加数据：
可以发现master2中id的步长为2，且从2开始自增。
然后在master1查询数据，并添加：
可以发现master1中id的步长为2，且从1开始自增，再去master2中查询能发现id为5的数据，说明主主复制配置没有问题。
为什么两个主中id自增的偏移量要不一致呢？当两个主同时接受到插入请求时就能保证id不冲突，其实这样只能保证插入数据不冲突，无法保证删除和修改导致的数据不一致。
所以在实际的应用场景中，只能暴露一个主给客户端才能保证数据的一致性。
mysql高可用的搭建
这里借助keepalived来对上面的多主复制架构改造来实现mysql的高可用。
keepalived的安装：
keepalived.conf
/etc/keepalived/chkmysql.sh
到此这篇关于mysql复制架构的文章就介绍到这了,更多相关mysql复制架构内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！