MySQL基于复制的架构方案

MySQL复制是一个非常简单而有方便进行架构扩展的功能，可以说是运维必备，我们通过对主从进行不同的组合，可以满足我们相应的需求。

分享目录：

一主一从，高可用
一主一从，读写分离
一主多从，读写分离
一主多从，负载均衡
主主复制，双写
主主复制，单写
双主双从

1.一主一从，高可用

架构说明：最传统的一主一从，如果主库发生故障，手动将从库提升为主库，从库仅用于故障恢复。

2.一主一从，读写分离

架构说明：还是一主一从，在客户端实现读写分离，不过需要注意主从延时的情况。

小技巧：在写比较度的表上可以在Master不建立索引，而在Slave端来建立索引。

3.一主多从，读写分离

架构说明：和一主一从类似，在读请求比较多的情况下，可以增加MySQL从节点。

小技巧：可以在客户端实现多个从节点的轮询和权重的设置。

4.一主多从，负载均衡

架构说明：在对读需求场景比较多的情况下，为了不频繁的对客户端进行配置变更，可以在从库前端放置负载均衡。不过在slave比较多的时候。主从复制也会给MySQLMaster带来一些性能上和带宽上的压力。

小技巧：给Slave分配不同的角色。例如之前公众号文章说的延迟从库、灾备从库、数据仓库等。

5.主主复制，双写

架构说明：主主复制其实就是MySQL的双向复制，两台机器互为主从，双主可以同时写，不过要处理好自增ID重复问题，例如设置使用奇偶插入。

6.主主复制，单写

架构说明：还是主主复制，不过这次单写，也就是双主当主从。既可以保证写的高可用，又可以保证读的高可用。

小技巧：这个是两台机器的最佳方案哦。

7. 双主双从

架构说明：在主主复制，单写的时候。如果一个主宕机，那么就读写另外一个主。可读的节点就剩下了一个。对于读需求比较多的业务可能会有问题，那么双主双从就可以解决这个问题。

小技巧：复杂的架构带的肯定是运维的难题哦。

好了，基于复制的扩展先写到这里，其实也可以使用MySQL Proxy替代客户端做的读写分离，不过一直没有生产使用过。北京天气不错，该出去转转了。如果觉得可以读，请转发和关注哦。

分享嘉宾

赵舜东

江湖人称赵班长，曾在武警某部负责指挥自动化的架构和运维工作，2008年退役后一直从事互联网运维工作。曾带团队负责国内某电商的运维工作，SaltStack中国用户组发起人、《saltstack入门与实践》作者，《运维知识体系》作者。

趁现在，关注我们

欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。

本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。

长按下方的二维码可以快速关注我们
如想加群讨论学习，请点击右下角的“加群学习”菜单入群。