可以在任意个主库和备库之间建立复制，只有一个限制:每一个备库只能有一个主库，有很多复杂的拓扑结构，但即使是最简单的也可能会非常灵活。一种拓扑可以有多种用途。关于使用复制的不同方式可以很轻易地写一本书。

        我们已经讨论了如何为主库设置一个 备库，本节我们讨论其他比较普遍的拓扑结构以及它们的优缺点。记住下面的基本原则:

●一个MySQL 备库实例只能有一个主库。

●每个备库必须有一个唯一的服务器ID。

●一个主库可以有多个备库(或者相应的，一个备库可以有多个兄弟备库)。

●如果打开了log. slave_ updates 选项，一个备库可以把其主库上的数据变化传播到其他备库。

一主库多备库

        除了我们已经提过的两台服务器的主备结构外，这是最简单的拓扑结构。事实上一主多备的结构和基本配置差不多简单，因为备库之间根本没有交互，它们仅仅是连接到同一个主库上。在有少量写和大量读时，这种配置是非常有用的。可以把读分摊到多个备库上，直到备库给主库造成了太大的负担，或者主备之间的带宽成为瓶颈为止。你可以按照之前介绍的方法一次性设置多个备库，或者根据需要增加备库。

一主多备结构

        尽管这是非常简单的拓扑结构，但它非常灵话，能满足多种需求。下面是它的些用途:

●为不同的角色使用 不同的备库(例如添加不同的索引或使用不同的存储引擎)。

●把一台备库当作待用的主库， 除了复制没有其他数据传输。

●将一台备库放到远程数据中心，用作灾难恢复。

●延迟一个或多个备库，以备灾难恢复。

●使用其中一个备库，作为备份、 培训、开发或者测试使用服务器。

        这种结构流行的原因是它避免了很多其他拓扑结构的复杂性。例如:可以方便地比较不同备库重放的事件在主库二进制日志中的位置。换句话说，如果在同一个逻辑点停止所有备库的复制，它们正在读取的是主库上同一个日志文件的相同物理位置。这是个很好的特性，可以减轻管理员许多工作，例如把备库提升为主库。

        这种特性只存在于兄弟备库之间。在没有直接的主备或者兄弟关系的服务器上去比较日志文件的位置要复杂很多。之后我们会提到的许多拓扑结构，例如树形复制或分布式主库，很难计算出复制的事件的逻辑顺序。