MySQL主从复制的拓扑结构

复制拓扑

       *所有拓扑都应该遵循一个备库只能拥有一个主库，每个备库只能有一个server id的规则。

       *一主多备。简单的拓扑，但是能够满足大部分需求：1.为不同的角色使用不同的备库。2.选用一个备库当作待用主库，以备主备切换。3.可以用于灾难恢复。4.可以将一个备库用作测试。对于这种结构需要关注多个备库的延迟，对于延迟特别严重的需要进行一些处理。另外就是虽然多个备库可以缓解读压力，但是对于写压力仍然在主库上，并且随着备库的增多，主库需要增加更多的io线程来发送binlog给备库，这在扩展时需要注意。

       *主动-主动模式下的主主复制。这种将写入分配给了两台服务器，很容易造成冲突从而导致数据不一致。比如说主键自增冲突，两台主库同时插入一行，结果两台主库的行都会使用同一个主键，解决这个问题是设置auto increment increment和auto increment offset，给主备库主键设置一个offset来避免冲突。此外还有其他一些问题，比如两台服务器同时对一些数据进行操作，执行复制时可能因为两边语句执行顺序不一致导致问题。

       *主动-被动模式下的主主复制。这种复制解决了主动主动模式下的冲突问题。其中一台服务器可以写入，而另一台只读。这种模式下切换角色，进行故障转移等都很方便。这里有个细节就是，主动的语句复制到被动一方，被动一方执行后悔写入自己的binlog，这时主动一方又会读取被动一方的binlog，mysql在这里会忽略binlog中serverid跟自己相同的语句，这也是为什么要显式设置server id的原因。

       *环形结构。由三台主库相互顺序连接形成。这个结构出现问题的几率大于上一个模式，同时存在着一个问题就是如果其中一个主库崩溃了，那么这个主库所造成的修改的语句会在仍然存活的两个主库上无限循环。

       *分发主库。前面提到，如果备库数量过大，会使主库存在过多io线程进行binlog发送，这里有个解决方法就是设置一个分发主库，分发主库不存储数据，只存储日志，它接受主库传来的日志，然后将所有表都设置为blackhole引擎，这个引擎会吞噬所有数据而不进行实际操作，因而不耗什么时间，这样做实际上就是将主库的写入功能和分发日志功能分离以减轻主库压力。不过blackhole引擎仍然存在一些bug，比如有时会忘记将自增id写入binlog，使用需要慎重。

       *树或金字塔模式。这种模式也可以减轻主库的分发压力，将分发的压力下分给备库，不过存在一个问题就是如果中间层的备库出现问题，那么下面的备库都会跟着出现问题，对恢复造成困难。

       *部分数据备库（数据分离）。考虑写入压力特别大的情况，由于备库是单线程复制，这可能会造成很大的延迟。可以将主库的数据库分别分给每个备库，这样每个备库只拥有一部数据库，这减轻了主库的分发压力，每个线程只需传输一部分binlog，也减轻了每个备库的读取和重放压力，只用处理一部分binlog。

       *功能分离。比如可以将应用的OLTP查询和OLAP查询分配到不同的备库上，备库间存储相同的数据，但是使用不同的设置，参数，硬件，存储引擎等。

       *模拟多主库复制。虽然说mysql备库不支持多主库复制，但是可以通过一些技巧来达成伪多主库复制。一种方法是定时切换备库的主库，这适用于负载较低的情况。一种是使用主主结构并且配合blackhole引擎表。