

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 使用複寫來提高跨區域的 Kafka 串流應用程式彈性
<a name="msk-replicator-increase-resiliency"></a>

您可以使用 MSK Replicator 來設定主動-主動或主動-被動叢集拓撲，以提高 Apache Kafka 應用程式跨 AWS 區域的彈性。在主動-主動式設定中，兩個 MSK 叢集都主動提供讀取和寫入。在主動-被動式設定中，一次只有一個 MSK 叢集主動提供串流資料，而另一個叢集處於待命狀態。

## 建置多區域 Apache Kafka 應用程式的考量事項
<a name="msk-replication-multi-region-kafka-applications"></a>

您的取用者必須能夠重新處理重複的訊息，且不影響下游。MSK Replicator 至少會複寫一次資料，這可能會導致待命叢集中出現重複項目。當您切換到次要 AWS 區域時，您的取用者可能會多次處理相同的資料。MSK Replicator 會將資料複製作業優先於取用者偏移，以取得更好的效能。容錯移轉之後，取用者可能會從較早的偏移開始讀取，進而導致重複處理。

生產者和取用者還必須容忍失去少量的資料。由於 MSK Replicator 會以非同步方式複寫資料，因此當主要 AWS 區域開始遇到故障時，無法保證所有資料都會複寫至次要區域。您可以使用複寫延遲，以判斷未複製到次要區域的資料大小上限。

## 主動-主動式與主動-被動式叢集拓撲比較
<a name="msk-replicator-active-versus-passive"></a>

主動-主動式叢集拓撲提供接近零的復原時間，而且可讓串流應用程式在多個 AWS 區域同時運作。當一個區域中的叢集受損時，連線到另一個區域中叢集的應用程式會繼續處理資料。

主動-被動式設定適用於一次只能在一個 AWS 區域中執行的應用程式，或當您需要對資料處理順序有更多的控制時。主動-被動式設定比主動-主動式設定需要更多的復原時間，因為您必須在次要區域啟動整個主動-被動式設定，包括您的生產者和取用者，才能在容錯移轉後恢復串流資料。

# 使用建議的主題命名組態建立主動-被動 Kafka 叢集設定
<a name="msk-replicators-active-passive-cluster-setup"></a>

對於主動-被動設定，我們建議您在兩個不同的 AWS 區域中操作類似的生產者、MSK 叢集和取用者設定 （使用相同的取用者群組名稱）。重要的是，兩個 MSK 叢集具有相同的讀取和寫入容量，以確保可靠的資料複寫。您需要建立 MSK Replicator，以持續從主要叢集將資料複製到待命叢集。您也需要設定生產者將資料寫入相同 AWS 區域中叢集上的主題。

對於主動-被動設定，請使用相同的主題名稱複寫 （在主控台中**保留相同的主題名稱**) 建立新的複寫器，以開始將資料從主要區域中的 MSK 叢集複寫到次要區域中的叢集。我們建議您在兩個區域中操作一組重複的生產者和消費者 AWS ，每個生產者和消費者都使用其引導字串連接到自己區域中的叢集。這可簡化容錯移轉程序，因為它不需要變更引導字串。為了確保消費者從他們離開的地方附近讀取，來源和目標叢集中的消費者應該具有相同的消費者群組 ID。

如果您為 MSK Replicator 使用相同的主題名稱複寫 （在主控台中**保留相同的主題名稱**)，則會使用與對應來源主題相同的名稱複寫您的主題。

建議您為目標叢集上的用戶端設定叢集層級設定和許可。您不需要設定主題層級設定和常值讀取 ACLs因為如果您已選取複製存取控制清單的選項，MSK Replicator 會自動將其複製。請參閱 [中繼資料複寫](msk-replicator-how-it-works.md#msk-replicator-metadata-replication)。

# 容錯移轉至次要 AWS 區域
<a name="msk-replicator-when-planned-failover"></a>

建議您 AWS 使用 Amazon CloudWatch 監控次要區域中的複寫延遲。在主要 AWS 區域中的服務事件期間，複寫延遲可能會突然增加。如果延遲持續增加，請使用 AWS 服務運作狀態儀表板來檢查主要 AWS 區域中的服務事件。如果有事件，您可以容錯移轉至次要 AWS 區域。

# 執行計劃容錯移轉至次要 AWS 區域
<a name="msk-replicator-perform-planned-failover"></a>

您可以執行計劃的容錯移轉，以針對主要 AWS 區域中具有來源 MSK 叢集的意外事件測試應用程式的彈性。計劃的容錯移轉不應導致資料遺失。

如果您使用的是相同的主題名稱複寫組態，請遵循下列步驟：

1. 關閉連線至來源叢集的所有生產者和取用者。

1. 建立新的 MSK Replicator，以使用相同的主題名稱複寫 (**在主控台中保留相同的主題名稱），**將資料從次要區域中的 MSK 叢集複寫到主要區域中的 MSK 叢集。如果需要將要寫入次要區域的資料複寫回主要區域，以便在意外事件結束後容錯恢復至主要區域，就需要此操作。

1. 啟動連接到次要 AWS 區域中目標叢集的生產者和消費者。

如果您使用的是字首主題名稱組態，請依照下列步驟進行容錯移轉：

1. 關閉連線至來源叢集的所有生產者和取用者。

1. 建立新的 MSK Replicator，從次要區域中的 MSK 叢集將資料複寫至主要區域中的 MSK 叢集。如果需要將要寫入次要區域的資料複寫回主要區域，以便在意外事件結束後容錯恢復至主要區域，就需要此操作。

1. 在次要 AWS 區域的目標叢集上啟動生產者。

1. 根據應用程式的訊息順序要求而定，依照下列其中一個索引標籤中的步驟進行操作。

------
#### [ No message ordering ]

   如果您的應用程式不需要訊息排序，請在從本機 （例如主題） 和複寫主題 （例如 `<sourceKafkaClusterAlias>.topic`) 讀取的次要 AWS 區域中，使用萬用字元運算子 （例如 ) 啟動消費者`.*topic`。

------
#### [ Message ordering ]

   如果您的應用程式需要訊息排序，請僅針對目標叢集 (例如 `<sourceKafkaClusterAlias>.topic`) 上的複寫主題，而非本機主題 (例如，`topic`) 啟動取用者。

------

1. 等待目標 MSK 叢集上複寫主題的所有取用者完成處理所有資料，取用者延遲為 0，且處理的記錄數量也為 0。然後，停止目標叢集上複製主題的取用者。此時，已取用從來源 MSK 叢集複寫到目標 MSK 叢集的所有記錄。

1. 啟動目標 MSK 叢集上本機主題 (例如 `topic`) 的取用者。

# 執行意外容錯移轉至次要 AWS 區域
<a name="msk-replicator-perform-unplanned-failover"></a>

當主要 AWS 區域中具有來源 MSK 叢集的服務事件，且您想要暫時將流量重新導向至具有目標 MSK 叢集的次要區域時，您可以執行意外容錯移轉。當 MSK Replicator 非同步複寫資料時，意外容錯移轉可能會導致部分資料遺失。您可以使用 中的指標來追蹤訊息延遲[監控複寫](msk-replicator-monitor.md)。

如果您使用的是相同的主題名稱複寫組態 (**在主控台中保留相同的主題名稱），**請依照下列步驟執行：

1. 嘗試關閉連線至主要區域中來源 MSK 叢集的所有生產者和取用者。由於該區域中的受損，此操作可能不會成功。

1. 啟動連線至次要 AWS 區域中目標 MSK 叢集的生產者和消費者，以完成容錯移轉。由於 MSK Replicator 也會複寫中繼資料，包括讀取 ACLs 和取用者群組位移，因此您的生產者和取用者將順暢地從在容錯移轉之前離開的地方繼續處理。

如果您使用的是`PREFIX`主題名稱組態，請依照下列步驟進行容錯移轉：

1. 嘗試關閉連線至主要區域中來源 MSK 叢集的所有生產者和取用者。由於該區域中的受損，此操作可能不會成功。

1. 啟動連線至次要 AWS 區域中目標 MSK 叢集的生產者和消費者，以完成容錯移轉。由於 MSK Replicator 也會複寫中繼資料，包括讀取 ACLs 和取用者群組位移，因此您的生產者和取用者將順暢地從在容錯移轉之前離開的地方繼續處理。

1. 根據應用程式的訊息順序要求而定，依照下列其中一個索引標籤中的步驟進行操作。

------
#### [ No message ordering ]

   如果您的應用程式不需要訊息排序，請使用萬用字元運算子 （例如 `topic`)，在同時讀取本機 （例如 ) 和複寫主題 （例如 `<sourceKafkaClusterAlias>.topic`) 的目標 AWS 區域中啟動取用者`.*topic`。

------
#### [ Message ordering ]

   1. 請僅針對目標叢集 (例如 `<sourceKafkaClusterAlias>.topic`) 上的複寫主題，而非本機主題 (例如，`topic`) 啟動取用者。

   1. 等待目標 MSK 叢集上複寫主題的所有取用者完成處理所有資料，偏移延遲為 0，且處理的記錄數量也為 0。然後，停止目標叢集上複製主題的取用者。此時，已取用從來源 MSK 叢集複寫到目標 MSK 叢集的所有記錄。

   1. 啟動目標 MSK 叢集上本機主題 (例如 `topic`) 的取用者。

------

1. 一旦服務事件在主要區域中結束，請建立新的 MSK Replicator，以將資料從次要區域中的 MSK 叢集複寫到主要區域中的 MSK 叢集，並將複寫器開始位置設定為*最早*。如果需要將要寫入次要區域的資料複寫回主要區域，以便在服務事件結束後容錯恢復至主要區域，就需要此操作。如果您未將複寫器開始位置設定為*最早*，則在主要區域中的服務事件期間產生到次要區域中叢集的任何資料都不會複製回主要區域中的叢集。

# 執行容錯移轉至主要 AWS 區域
<a name="msk-replicator-perform-failback"></a>

您可以在該 AWS 區域中的服務事件結束後，容錯移轉回主要區域。

如果您使用的是相同的主題名稱複寫組態，請遵循下列步驟：

1. 建立新的 MSK Replicator，您的次要叢集做為來源，而主要叢集做為目標，開始位置設定為*最早*和相同的主題名稱複寫 (**在主控台中保留相同的主題名稱**)。

   這將開始複製容錯移轉回主要區域後寫入次要叢集的所有資料的程序。

1. 在 `MessageLag` Amazon CloudWatch 中監控新複寫器上的指標，直到達到 `0`，這表示所有資料已從次要複寫到主要。

1. 複寫所有資料後，停止連線至次要叢集的所有生產者，並啟動連線至主要叢集的生產者。

1. 等待連線至次要叢集的消費者成為 `MaxOffsetLag` 指標`0`，以確保他們已處理所有資料。請參閱 [監控消費者延遲](consumer-lag.md)。

1. 處理所有資料後，停止次要區域的取用者，並啟動連線至主要叢集的取用者以完成容錯回復。

1. 刪除您在將資料從次要叢集複寫至主要叢集的第一個步驟中建立的複寫器。

1. 確認您現有的複寫器將資料從主要叢集複製到次要叢集，在 Amazon CloudWatch 中狀態為「RUNNING」和`ReplicatorThroughput`指標`0`。

   請注意，當您建立新的複寫器，其起始位置為*最早*容錯回復時，它會開始讀取次要叢集主題中的所有資料。根據您的資料保留設定，您的主題可能會有來自來源叢集的資料。雖然 MSK Replicator 會自動篩選這些訊息，但您仍需支付次要叢集中所有資料的資料處理和傳輸費用。您可以使用 追蹤複寫器處理的資料總數`ReplicatorBytesInPerSec`。請參閱 [MSK Replicator 指標](msk-replicator-monitor.md#msk-replicator-metrics)。

如果您使用的是字首主題名稱組態，請遵循下列步驟：

只有在從次要區域中的叢集複寫到主要區域中的叢集已趕上且 Amazon CloudWatch 中的 MessageLag 指標接近 0 之後，您才應該啟動容錯回復步驟。計劃的容錯恢復不會導致任何資料遺失。

1. 關閉連線至次要區域中 MSK 叢集的所有生產者和取用者。

1. 對於主動-被動式拓撲，刪除從次要區域中叢集將資料複寫到主要區域的複寫器。您不需要刪除主動-主動式拓撲的複寫器。

1. 啟動連線至主要區域中 MSK 叢集的生產者。

1. 根據應用程式的訊息順序要求而定，依照下列其中一個索引標籤中的步驟進行操作。

------
#### [ No message ordering ]

   如果您的應用程式不需要訊息排序，請在主要 AWS 區域中使用萬用字元運算子 （例如 `topic`) 從本機 （例如 ) 和複寫主題 （例如 `<sourceKafkaClusterAlias>.topic`) 讀取的消費者`.*topic`。本機主題 (例如：topic) 上的取用者將從容錯移轉之前取用者取用的最後一個偏移恢復。如果在容錯移轉之前有任何未處理的資料，則將會立即處理該資料。如果是計劃的容錯移轉，應該沒有此類記錄。

------
#### [ Message ordering ]

   1. 請僅針對主要區域 (例如 `<sourceKafkaClusterAlias>.topic`) 上的複寫主題，而非本機主題 (例如，`topic`) 啟動取用者。

   1. 等待主要區域中叢集上複寫主題的所有取用者完成處理所有資料，偏移延遲為 0，且處理的記錄數量也為 0。然後，停止在主要區域中叢集上複製主題的取用者。此時，容錯移轉後在次要區域中產生的所有記錄皆已在主要區域中取用。

   1. 啟動主要區域中叢集上本機主題 (例如 `topic`) 的取用者。

------

1. 確認從主要 叢集到次要 叢集的現有複寫器處於 RUNNING 狀態，並使用 `ReplicatorThroughput`和 延遲指標如預期般運作。

# 使用 MSK Replicator 建立主動-主動設定
<a name="msk-replicator-active-active"></a>

如果您想要建立主動-主動設定，其中兩個 MSK 叢集都在主動提供讀取和寫入，建議您使用具有字首主題名稱複寫的 MSK Replicator （在主控台中**將字首新增至主題名稱**)。不過，這需要您重新設定取用者以讀取複寫的主題。

依照下列步驟，在來源 MSK 叢集 A 與目標 MSK 叢集 B 之間設定主動-主動式拓樸。

1. 建立 MSK Replicator，將 MSK 叢集 A 作為來源，MSK 叢集 B 作為目標。

1. 成功建立上述 MSK Replicator 之後，請建立以叢集 B 作為來源，建立叢集 A 作為目標的複寫器。

1. 建立兩組生產者，兩組生產者可同時將資料寫入在與生產者相同區域中叢集的本機主題 (例如 "topic")。

1. 建立兩組取用者，每個取用者使用萬用字元訂閱 （例如「.\$1topic」) 從與取用者相同 AWS 區域中的 MSK 叢集讀取資料。這樣，您的取用者將自動從本機主題 (例如，`topic`) 中讀取在區域中本機產生的資料，以及從其他區域帶有字首 `<sourceKafkaClusterAlias>.topic` 的主題中複寫的資料。這兩組取用者應具有不同的取用者群組 ID，以便在 MSK Replicator 將取用者群組複製到另一個叢集時，不會覆寫取用者群組偏移。

如果您想要避免重新設定用戶端，而不是字首主題名稱複寫 (**在主控台中將字首新增至主題名稱**)，您可以使用相同的主題名稱複寫 （在主控台中**保留相同的主題名稱） **建立 MSK 複寫器，以建立主動-主動設定。不過，您將為每個複寫器支付額外的資料處理和資料傳輸費用。這是因為每個複寫器都需要處理一般資料量的兩倍，一次用於複寫，另一次用於防止無限迴圈。您可以使用 `ReplicatorBytesInPerSec` 指標追蹤每個複寫器處理的資料總量。請參閱 [監控複寫](msk-replicator-monitor.md)。此指標包含複寫至目標叢集的資料，以及 MSK Replicator 篩選的資料，以防止將資料復原至其源自的相同主題。

**注意**  
如果您使用相同的主題名稱複寫 （在主控台中**保留相同的主題名稱**) 來設定主動-主動拓撲，請在刪除主題後等待至少 30 秒，再以相同名稱重新建立主題。此等待期間有助於防止重複的訊息複寫回來源叢集。您的取用者必須能夠重新處理重複的訊息，且不影響下游。請參閱 [建置多區域 Apache Kafka 應用程式的考量事項](msk-replicator-increase-resiliency.md#msk-replication-multi-region-kafka-applications)。