【MySQL】主从复制架构方案

主从架构设计

查看binlog

show master status;
show BINLOG events in 'BUUUG-bin.000120';

主从同步需要考虑的风险

突然断电导致主从数据不一致
数据同步延迟问题（主库写，从库查）

如何避免

同步方式：
异步同步（保证性能不会受到同步的影响）
半同步：同步时等待，直到数据已经同步到relay binlog之后，才可以返回到Web/App Server
强制读主…等

不同的主从架构方案

1、一主一从
Slave可以用来做Master的备份。

2、一主多从（应用较广泛）
Master承载了大部分的写请求，Slave承载大部分的读请求。同时可以在Slave3中做备份节点，用于定时任务操作/线下查生产环境数据（哪怕是把数据改了，也不会影响线上）等。选一个Slave做Master的备份，当Master挂掉之后，使用Slave承担Master 的工作。

3、双主
适合写请求压力非常大的情况。比如对id取模，偶数写进一个节点，奇数写进另一个节点。缺点是如果其中一个挂了，整个系统就挂了。

4、级联同步
优点：如果Master挂掉，剩下的Slave是一个天然的主从架构。Master只和一个Slave同步，减轻Master的压力。

5、环形多主
早期淘宝使用过，Master上再接许多从库，形成数据库矩阵，用于提高承载性。
但是只要挂掉一个Master，整体就挂了。特殊情况使用。
现在很少使用了

使用Docker

不推荐在Docker容器中存放频繁读写的文件系统，因为Docker的文件系统是虚拟的，其增删改查操作相对于直接访问主机里的文件系统来说，速度会慢很多。

所以，为了提高性能，应该将Data目录以及配置文件挂载在容器外面。

MySQL主从架构的实现方案

将写请求发动到Master中，将读请求发送到Slave中
不推荐使用AOP进行insert/select分离，因为会增加整个业务系统的复杂性，需要进行修改程序、测试等一系列操作。AOP在调试的时候不是线性的调试，如果对别人写的AOP逻辑了解的话，不容易找到问题出在哪里。

有一些第三方的组件帮助我们进行读写分离，如 sharing-jdbc 等，是侵入式的方案。

使用中心代理节点的方案，对insert/select进行分发，可以屏蔽后端MySQL架构的复杂性，从而让MySQL后端架构对于开发人员来说是透明的。

可以使用MyCat或者Atlas

编写docker-compose.yml

主库的配置

配置完之后，重启数据库
dc restart master

再使用show master status;查看 Binlog_Do_DB，会发现多了一个库

从库的配置

配置完之后，重启数据库
dc restart slave1

需要配置主库信息，才能知道要从哪一个库同步

可以使用show slave status查看slave的同步状态

slave2的配置与slave1相同

Atlas的配置

全部启动