MySQL：基于复制的架构方案
MySQL复制是一个非常简单而有方便进行架构扩展的功能，可以说是运维必备，我们通过对主从进行不同的组合，可以满足我们相应的需求。
分享目录：
-
一主一从，高可用
-
一主一从，读写分离
-
一主多从，读写分离
-
一主多从，负载均衡
-
主主复制，双写
-
主主复制，单写
-
双主双从
1.一主一从，高可用
架构说明：最传统的一主一从，如果主库发生故障，手动将从库提升为主库，从库仅用于故障恢复。
应用场景：我们公司的核心业务，我宁愿不能访问，也不能容忍主从不一致（比如 有MHA有但是不用）
2.一主一从，读写分离
架构说明：还是一主一从，在客户端实现读写分离，不过需要注意主从延时的情况。
小技巧：
- 在主库不建索引在从库建：大表有索引比如inser比较慢，不放心可以建两个从库
- 在写比较多的表上可以在Master不建立索引，而在Slave端来建立索引
3.一主多从，读写分离
架构说明：和一主一从类似，在读请求比较多的情况下，可以增加MySQL从节点。
小技巧：
可以在客户端实现多个从节点的轮询和权重的设置（PHP做一个简单的权重轮询）。
小规模架构不建议用负载均衡
4.一主多从，负载均衡
架构说明：在对读需求场景比较多的情况下，为了不频繁的对客户端进行配置变更，可以在从库前端放置负载均衡。不过在slave比较多的时候。主从复制也会给MySQLMaster带来一些性能上和带宽上的压力。
小技巧：给Slave分配不同的角色。例如之前公众号文章说的延迟从库、灾备从库、数据仓库等。
5.主主复制，双写
架构说明：主主复制其实就是MySQL的双向复制，两台机器互为主从，双主可以同时写，不过要处理好自增ID重复问题，例如设置使用奇偶插入 。
自增ID设置成奇偶插入
6.主主复制，单写
架构说明：还是主主复制，不过这次单写，也就是双主当主从。既可以保证写的高可用，又可以保证读的高可用。
小技巧：这个是两台机器的最佳方案哦。
7. 双主双从
架构说明：
在主主复制，单写的时候。如果一个主宕机，那么就读写另外一个主。可读的节点就剩下了一个。
对于读需求比较多的业务可能会有问题，那么双主双从就可以解决这个问题。
小技巧：复杂的架构带的肯定是运维的难题哦。
mmm
MHA
关于主从复制的一些疑问？
1、主从复制的主动和被动？
从库去拉去，不是主控硬塞给他的。
2、中继日志的作用？
- 类似与or的逻辑复制
- 我发日志给你不是发数据给你
- 有可能会造成不一致
1、从内存满了，数据没写进去，但是由于什么原因有好了
2、中间写的数据从来就没有涉及过，登录从库上改一个值，不会报错
3、做完主从第一步？
从库开启只读：开发写错了写到数据库上，这个锅谁背，你这个dba怎么干的？
4、为什么运维背黑锅是技术不行？
- 从库为什么能写？
- 即使开发错了会马上报错
- 从库写日志报错，老板会表扬你
5、复制的延迟能否彻底解决？
不能，可以缓解
- 从库是ssd硬盘
- 尽量避免主库大量的写入
- 主库和从库直接使用专用网络，高速互联
- 对于数据一致性要求严格的，不要查从库
- 减少从库压力，例如使用多个从库
好了，基于复制的扩展先写到这里，其实也可以使用MySQL Proxy替代客户端做的读写分离，不过一直没有生产使用过。今天北京天气不错，该出去转转了。如果觉得可以读，请转发和关注哦。
