主动/被动模式

在主动/被动拓扑中，应用将所有读取和写入都指向单个服务器。此外，还维护了少量不主动服务于任何应用程序流量的被动副本。

选择此模型的主要原因是：不用担心复制延迟的问题。由于所有读取都指向源服务器，因此可以防止应用程序不接受读取延迟数据的问题。

配置

在这个拓扑架构下，应该尽量让主节点和从节点在 CPU、内存等方面具有相同的配置。

当需要进行切换的时候，例如，例行维护、软件升级、打补丁或者硬件故障等，可以从当前正在运行的主节点切换到其中某个从节点上。因为副本上使用相同的硬件和软件配置，因此就可以确保能够支持切换之前的应用流量和吞吐量。

冗余

在物理硬件环境中，推荐使用至少三台服务器的 n+2 冗余。如果其中一台副本服务器发生硬件故障，还有一台额外的副本服务器用于故障切换。如果无法在主节点上进行备份操作，可以使用其中一个副本作为备份服务器。

在云环境中，如果数据足够少，或者可以轻松复制数据，也可以使用至少两台服务器的 n+1 冗余，否则还是建议 n+2。如果使用了 n+1 架构，云服务商的动态资源调配特性会让管理操作更容易。对于打补丁等维护事件，可以按需配置第三个副本，对其执行任何必要的操作（如升级内核或应用安全更新），然后替换另一个副本。最后再进行故障切换并在主节点上重复该过程。

在任何一种情况下，都可以将其中一个副本放置在地理位置较远的位置，不过需要关注复制延迟情况并确保其可用。副本应该是可恢复的，并且任何数据丢失都应符合预期的标准。