第二十章 镜像架构和规划 - 限制对备份故障转移成员的访问

第二十章 镜像架构和规划 - 限制对备份故障转移成员的访问

虽然托管镜像备份故障转移成员的系统可能有未使用的资源或容量，或者可能希望在其镜像数据库上运行只读查询，但 推荐的最佳实践是将主机专用于其角色，仅作为备份镜像成员。对备份的任何镜像相关或非镜像使用都会产生以下影响：

• 如果备份性能的降低导致其确认从主服务器接收到日志数据的速度变慢，则访问主服务器上镜像数据库的应用程序用户可能会遇到性能下降的情况。任何必须等待主节点确认的应用程序交互，包括那些涉及显式日志同步以及同步提交事务和 ECP 活动的应用程序交互，都可能以这种方式受到影响。
• 如果备份的确认延迟到足以防止它在 QoS 超时内发生，则主要撤销备份的活动状态，导致自动故障转移变得更加困难或不可能，具体取决于主要中断的性质。
• 如果确实发生自动故障转移，备份现在支持其现有资源使用和主要用户应用程序资源使用。如果可能的话，备份主机必须有能力处理这两种负载。

出于这些原因，如果必须从主成员卸载用户活动，则应使用异步成员而不是备份成员。

在单个主机上安装多个镜像成员

构成镜像的 IRIS 实例通常安装在单独的物理或虚拟主机上，但这不是必需的。假设系统的容量足以处理所涉及的资源负载而不会导致性能下降，则可以在同一台主机上安装多个镜像成员，包括多个镜像的整体；个人情况将决定这是否可行，以及可以共存多少个镜像或镜像成员。

共同托管多个故障转移成员时，请记住故障转移镜像假设成员是同等的；没有首选的主要成员。出于这个原因，将故障转移成员实例放置在不同主机上时的最佳做法是使主机尽可能相似且容量大致相等。 Cohosting 故障转移成员有可能超出此模型的范围。例如，如果在五个不同的主机上创建了五个镜像，然后将一个主机上的五个 IRIS 实例作为第二个故障转移成员添加到镜像中，则这些镜像最初可能会在不同的主机上使用主服务器运行，而所有备份则共同托管在一个系统上。但是，如果有两个同时或几乎同时的中断导致故障转移，则单个系统现在托管两个主要系统和三个备份系统，这可能是一个太大的负载，无法以足够的性能处理。

当属于一个或多个镜像的多个 IRIS 实例共同托管时，它们共享一个 ISCAgent。

共同托管多个镜像成员时，请记住以下网络注意事项：

• 必须确保每个镜像在每台机器上使用一组唯一的端口（请参阅镜像成员网络地址），并确保未共同托管的其他镜像成员（如果有）使用相同的端口。例如，在两个不同的主机上运行的两个主节点可能都使用端口 1972，但如果它们都可能被共同托管的 DR 异步替换，如前一项所述，则新的主节点（以前的 DR 异步）将具有冲突的端口分配.如果一个主服务器使用端口 1972 和另一个 1973，并且在异步服务器上配置了这些相同的端口，则异步服务器已准备好同时升级，当发生这种情况时，客户端可以使用与中断前相同的端口访问镜像。
• 每个镜像的故障转移和 DR 异步成员（无论是完全或部分与其他镜像或其成员共同托管）必须有自己的子网，并且每个镜像都有自己的 VIP（如果使用 VIP）。这可能或多或少复杂，具体取决于所涉及的环境，并且需要共同托管镜像成员的节点具有多个 NIC 以支持多个子网。
• 镜像成员的共同托管对每个镜像的仲裁器的网络位置没有影响，如定位仲裁器以优化镜像可用性中所述。所涉及的镜像可以共享一个仲裁器或使用单独的仲裁器，只要故障转移成员和仲裁器位于适当的位置即可。