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

分享目录：

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

1.一主一从，高可用


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

2.一主一从，读写分离


架构说明：还是一主一从，在客户端实现读写分离，不过需要注意主从延时的情况。小技巧：在写比较度的表上可以在Master不建立索引，而在Slave端来建立索引。

3.一主多从，读写分离


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

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

4.一主多从，负载均衡


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

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

5.主主复制，双写


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


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

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

7. 双主双从



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

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

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