切換

交換功能可在不遺失資料的情況下改變主備方向。當目前的主要群集仍可存取，或需要移動流量進行維護時，請使用此功能。

本指南假設目前的拓樸為

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 是否作為新的主要資料，以及資料是否保持一致。常見的檢查包括

• 比較重要集合的行數。
• 從兩個群集查詢已知的主索引鍵。
• 在新的主機和舊的備用機上執行代表性搜尋。
• 在cluster-b 上執行小型寫入，並確認它已複製到cluster-a 。

切回

若要稍後切回，請再次套用原始拓樸：

cluster-a -> cluster-b

使用相同的切換流程。切回之前，請確定目前的主機是可接達且複製是健康的。

常見問題

切換會遺失資料嗎？

不會。切換會等待剩餘資料複製完成後，備用才會成為主用。

我需要停止應用程式寫入嗎？

您應該在角色轉換期間暫停寫入或讓寫入可以重試。在主機降級後，傳送到舊主機的寫入內容會被拒絕。

為什麼切換時間比預期長？

最常見的原因是 CDC 滯後。新的主機必須先接收剩餘資料，才能在 RPO = 0 的情況下安全接管。

我可以重試失敗的切換請求嗎？

可以。使用相同的目標拓樸重試。

舊的主機會如何？

舊的主機變成備用。它不應再接收應用程式寫入。