故障转移
当原主集群完全不可用时，故障转移会将备用集群升级为独立的主集群。这是一种可用性优先的操作符，可能会丢失故障前未复制的数据。
本指南假定原始拓扑结构是：
cluster-a (primary) -> cluster-b (standby)
故障转移后，cluster-b 成为独立的主节点：
cluster-b (primary)
何时使用故障转移
仅在以下情况下使用故障转移
- 原主设备无法响应请求。
- 主节点无法在可接受的时间内恢复。
- 恢复写可用性比等待旧主节点更重要。
如果主服务器仍然可以访问，请使用切换。切换可避免数据丢失。
数据丢失风险
故障切换不会等待原主设备。任何写入旧主设备但尚未复制到备用设备的数据都可能丢失。
可能的数据丢失由主用不可用时的 CDC 滞后决定。
在运行故障转移之前，请了解其中的利弊得失：
| 目标 | 切换 | 故障切换 |
|---|---|---|
| 在主服务器不可用时恢复写入 | 是 | 是 |
| 避免数据丢失 | 是 | 不保证 |
| 需要旧主设备响应 | 是 | 是 |
开始之前
确认以下内容：
- 原主机不可用。
- 您已决定不等待主系统恢复。
- 应用程序流量可以重定向到备用。
- 如果主用恢复，流量自动化将不会将写入发送回旧主用。
- 您拥有备用群集 ID、地址、令牌和 pchannels。
最重要的安全要求是防止大脑分裂。故障切换后，只有已升级的备用群集才能接受应用程序写入。
构建故障切换配置
构建一个只包含备用群集而不包含复制拓扑的配置。设置force_promote=True 。
# If you followed Set Up CDC Replication, cluster B is the original target cluster.
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
failover_config = {
"clusters": [
{
"cluster_id": cluster_b_id,
"connection_param": {
"uri": cluster_b_addr,
"token": cluster_b_token,
},
"pchannels": cluster_b_pchannels,
}
],
"cross_cluster_topology": [],
"force_promote": True,
}
升级备用
向备用群集发送请求。
from pymilvus import MilvusClient
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)
try:
client_b.update_replicate_configuration(**failover_config)
finally:
client_b.close()
如果请求成功，cluster-b 将成为独立的主服务器，并可接受写入。
重定向应用程序流量
升级后：
- 将写流量重定向到
cluster-b。 - 从写入端点、负载平衡器、DNS 记录和自动化中删除
cluster-a。 - 验证
cluster-b是否接受写入。 - 保持
cluster-a隔离，直至其退役或明确重建。
写入验证示例：
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)
try:
client_b.insert(
collection_name="test_collection",
data=[{"id": 1, "vector": [0.1] * 128}],
)
finally:
client_b.close()
调整 Collections 名称和 Schema 字段以匹配您的部署。
验证结果
直接验证已推广的群集：
- 在
cluster-b上写入成功。 - 读取返回预期数据。
- 没有应用程序组件写入
cluster-a。
处理旧主集群
故障转移后，将cluster-a 视为过时。如果可以再次访问，请勿向其发送应用程序写入内容。它可能包含从未复制到cluster-b 的数据，而cluster-b 可能已经包含故障切换后的新写入。
不要将cluster-a 自动重新连接到旧拓扑。重新引入旧的主服务器是一项单独的恢复任务，必须仔细规划。
尽量减少数据丢失
您无法消除故障转移带来的所有数据丢失风险，但可以降低风险：
- 持续监控 CDC 滞后。
- 保持备用群集的配置，以处理主写入率。
- 保持较低的跨群集网络延迟和数据包丢失。
- 使应用程序写入具有惰性。
- 在故障切换后重试成功率不确定的写入。
- 只要主集群仍能响应，就优先进行切换。
常见问题
故障切换是否总是会丢失数据？
不会，但有可能。如果在主系统故障前所有写入都已复制，则不会丢失数据。如果 CDC 存在滞后，滞后数据可能会丢失。
故障转移需要多长时间？
通常在几秒钟内完成，具体取决于群集状态和备用机上控制平面的可用性。
能否在主服务器上运行故障切换？
故障转移适用于备用群集。如果当前主服务器可用，请使用切换。
旧主集群能否自动重新加入？
不能。故障切换后，旧主集群必须被视为过时集群并退出运行或重建，然后才能再次参与复制。
如何避免大脑分裂？
确保只有被升级的群集才能接收写入。在旧主节点恢复并接受流量之前，将其从所有写入路径中移除。