切换

切换可在不丢失数据的情况下改变主备方向。当当前主群集仍可访问，或需要移动流量进行维护时，请使用此功能。

本指南假定当前拓扑为

cluster-a (primary)  ->  cluster-b (standby)

切换后，拓扑结构变为

cluster-b (primary)  ->  cluster-a (standby)

何时使用切换

何时使用切换

• 您正在对当前主网络进行维护。
• 主服务器部分性能下降，但仍能响应请求。
• 需要 RPO = 0 且不能接受数据丢失。

如果主服务器完全不可用，请勿使用切换。在这种情况下，请使用故障切换。

开始前

开始前请检查以下内容：

• 两个群集均可访问。
• CDC 复制正常。
• CDC 滞后足够低，可满足恢复时间目标。
• 角色变更期间，应用程序写入可以暂停或重试。
• 您已准备好新的拓扑配置。

角色切换可保证不丢失数据，但操作时间取决于仍有多少数据需要复制。

构建新拓扑

创建完全替换配置，其中cluster-b 成为源，cluster-a 成为目标。

# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels

cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

switchover_config = {
    "clusters": [
        {
            "cluster_id": cluster_a_id,
            "connection_param": {
                "uri": cluster_a_addr,
                "token": cluster_a_token,
            },
            "pchannels": cluster_a_pchannels,
        },
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": cluster_b_id,
            "target_cluster_id": cluster_a_id,
        }
    ],
}

应用新拓扑

对两个群集应用相同的配置。先将请求发送到当前的主服务器，然后再发送到备用服务器。如果后来切换回主服务器，则顺序相反，因为cluster-b 是当前主服务器。

from pymilvus import MilvusClient

client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_a.update_replicate_configuration(**switchover_config)
    client_b.update_replicate_configuration(**switchover_config)
finally:
    client_a.close()
    client_b.close()

旧的主控降级为备用，并拒绝新的写入。旧的备用机等待剩余的复制数据，将自己提升为主用机，然后接受写入。

如果由于瞬时网络或服务错误导致请求失败，请使用相同配置重试。

重定向应用程序流量

cluster-b 成为主服务器后：

1. 将写流量指向cluster-b 。
2. 确认cluster-b 上的读写成功。
3. 确认cluster-a 不再接收应用程序写入。
4. 继续监控从cluster-b 复制到cluster-a 。

验证结果

验证cluster-b 是否作为新的主服务器，以及数据是否保持一致。常见检查包括

• 比较重要 Collections 的行计数。
• 查询两个群集中的已知主键。
• 在新主服务器和旧备用服务器上运行代表性搜索。
• 在cluster-b 上运行小规模写入，并确认复制到cluster-a 。

切换回

要稍后切换回，请再次应用原始拓扑：

cluster-a -> cluster-b

使用相同的切换流程。在切换回之前，请确保当前的主服务器是可访问的，并且复制是健康的。

常见问题

切换会丢失数据吗？

不会。切换会等待剩余数据复制完成后，备用数据才会成为主数据。

是否需要停止应用程序写入？

在角色转换期间，应暂停写入或使写入可重试。在主用程序降级后，发送到旧主用程序的写入将被拒绝。

为什么切换时间比预期长？

最常见的原因是 CDC 滞后。新的主节点必须先收到剩余数据，才能在 RPO = 0 的情况下安全接管。

可以重试失败的切换请求吗？

可以。使用相同的目标拓扑重试。

旧主设备会怎样？

旧主设备将成为备用设备。它不应再接收应用程序写入。