故障移轉
當原始主機完全不可用時，故障移轉會將備用群集升級為獨立的主機。這是可用性第一的作業，可能會遺失故障前未複製的資料。
本指南假設原始拓樸是：
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()
調整集合名稱和模式欄位，以符合您的部署。
驗證結果
直接驗證已升級的群集：
- 在
cluster-b上寫入成功。 - 讀取返回預期的資料。
- 沒有應用程式元件寫入
cluster-a。
處理舊的 Primary
故障移轉後，請將cluster-a 視為過時。如果可以再次連線，請勿向其傳送應用程式寫入內容。它可能包含從未複製到cluster-b 的資料，而cluster-b 可能已經包含故障移轉後的新寫入。
請勿自動將cluster-a 重新連接到舊拓樸。重新引入舊的主要資料是一項獨立的復原工作，必須仔細規劃。
最小化資料遺失
您無法消除故障移轉造成的所有資料遺失風險，但您可以降低風險：
- 持續監控 CDC 滯後情況。
- 保持備用群集的配置，以處理主寫入速率。
- 保持較低的跨群集網路延遲和封包遺失。
- 讓應用程式寫入具有惰性。
- 在故障轉換後，重試不確定是否成功的寫入。
- 只要主機仍能回應，就優先進行切換。
常見問題
故障移轉是否總會遺失資料？
不會，但有可能。如果所有寫入在主機故障前已經複製，就不會遺失資料。如果 CDC 存在滯後情況，則滯後的資料可能會遺失。
故障移轉需要多長時間？
通常在幾秒鐘內完成，這取決於群集狀態和備用伺服器上控制平面的可用性。
我可以在主機上執行故障移轉嗎？
故障移轉適用於備用群集。如果目前的主機可用，請使用切換。
舊的主機可以自動重新加入嗎？
不可以。故障移轉後，舊的主機必須視為陳舊，並在再次參與複製之前退役或重建。
如何避免腦部分裂？
確保只有已升級的群集才會接收寫入。在舊的主機可以復原並接受流量之前，將它從所有寫入路徑中移除。