Mirror Maker 2 - 從 Stanby 集群故障回復

Question

我們有 2 個集群 Apache Kafka 架構 - 主動-備用。 Mirror Maker 2 用於將所有數據從活動集群復制到備用集群。 如果活動集群出現故障，我們將故障轉移到備用集群並對其進行處理（連接生產者、消費者並發送新數據）。

問題是——從備用集群故障回復到活動集群的正確方法是什么？保留發送到備用集群活動時的所有數據？

我們是否需要以相反的方向運行 Mirror Maker 以將數據從備用集群復制到活動集群，並且一旦將數據復制到活動集群，則故障回復到活動集群？

我們如何阻止生產者向備用集群發送新數據以完成復制而不丟失任何數據？

您能否提一些建議？

Answer 1

我們如何阻止生產者向備用集群發送新數據以完成復制而不丟失任何數據？

根據我所看到的 Confluent 記錄，您將執行 DNS 重新映射到單個bootstrap.servers地址的活動集群，而不更改任何客戶端代碼。 當集群出現故障時，生產者需要預先配置重試，然后通過 DNS 查詢自動建立新連接，消費者將（理論上）自己進行定期元數據刷新/重新平衡。 否則，如果您停止生產者，您將丟失其當前未刷新的緩沖區，或阻止消費者處理/提交其當前批次。

在實踐中，我不確定這有多可靠，因為它需要在您的運行時環境中降低/禁用 DNS 緩存 TTL。

例如，在 Java

java.security.Security.setProperty("networkaddress.cache.ttl", "0"); 

我們是否需要反向運行 Mirror Maker 以將數據從 Standby 集群復制到 Active 集群

是的。 MirrorMaker2 具有循環檢測功能，但您需要讓您的消費者訂閱諸如my-topic(.replica)? 讀取任何直接生成的主題（在本地集群中）和來自遠程集群的鏡像主題。 理想情況下，您還可以實施只有 MirrorMaker 生產者客戶端才能寫入任何.replica主題的 ACL 策略。 請記住，當從多個主題消費時，消息排序將大部分丟失； 它只會在各個主題的各個分區中排序。