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

# 線上遷移至 Amazon Keyspaces：策略和最佳實務
<a name="migrating-online"></a>

如果您需要在從 Apache Cassandra 遷移至 Amazon Keyspaces 期間維持應用程式的可用性，您可以實作本主題討論的關鍵元件，以準備自訂線上遷移策略。透過遵循線上遷移的這些最佳實務，您可以確保在整個遷移過程中維持應用程式可用性和read-after-write一致性，將對使用者的影響降至最低。

設計從 Apache Cassandra 到 Amazon Keyspaces 的線上遷移策略時，您需要考慮下列關鍵步驟。

1. **寫入新資料**
   + **Amazon Keyspaces Migration 的 ZDM Dual Write Proxy** – 使用 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Dual Write Proxy 來執行從 Apache Cassandra 到 Amazon Keyspaces 的零停機時間遷移。ZDM Proxy 執行雙寫入，無需重構現有應用程式，並執行雙讀取以進行查詢驗證。
   + 應用程式雙寫入：您可以使用現有的 Cassandra 用戶端程式庫和驅動程式，在應用程式中實作雙寫入。指定一個資料庫做為領導者，另一個資料庫做為跟隨者。對跟隨者資料庫的寫入失敗會記錄在[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 中進行分析。
   + 訊息層雙寫入：或者，您可以設定現有的訊息平台，使用其他取用者將寫入傳送至 Cassandra 和 Amazon Keyspaces。這會在兩個資料庫之間建立最終一致的檢視。

1. **遷移歷史資料**
   + 複製歷史資料：您可以使用 AWS Glue 或自訂擷取、轉換和載入 (ETL) 指令碼，將歷史資料從 Cassandra 遷移到 Amazon Keyspaces。使用輕量型交易或時間戳記等技術來處理雙寫入和大量載入之間的衝突解決。
   + 使用Time-To-Live(TTL)：對於較短的資料保留期，您可以在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免上傳不必要的歷史資料。隨著 Cassandra 中的舊資料過期，並透過雙寫入寫入新資料，Amazon Keyspaces 最終會追上進度。

1. **驗證資料**
   + 雙重讀取：實作來自 Cassandra （主要） 和 Amazon Keyspaces （次要） 資料庫的雙重讀取，以非同步方式比較結果。差異會記錄或傳送至 DLQ。
   + 範例讀取：使用 Λ 函數定期取樣和比較兩個系統的資料，將任何差異記錄到 DLQ。

1. **遷移應用程式**
   + 藍綠策略：切換您的應用程式，在單一步驟中將 Amazon Keyspaces 視為主要資料存放區，並將 Cassandra 視為次要資料存放區。監控效能，並在發生問題時轉返。
   + Canary 部署：先逐步將遷移推展到一部分的使用者，並逐步增加 Amazon Keyspaces 作為主要使用者的流量，直到完全遷移為止。

1. **停用 Cassandra**

   一旦應用程式完全遷移至 Amazon Keyspaces 並驗證資料一致性，您就可以根據資料保留政策計劃停用 Cassandra 叢集。

透過使用這些元件規劃線上遷移策略，您可以順暢地轉換到全受管 Amazon Keyspaces 服務，並將停機時間或中斷降至最低。以下各節會更詳細地介紹每個元件。

**Topics**
+ [在線上遷移期間寫入新資料](migration-online-dw.md)
+ [在線上遷移期間上傳歷史資料](migration-online-historical.md)
+ [在線上遷移期間驗證資料一致性](migration-online-validation.md)
+ [在線上遷移期間遷移應用程式](migration-online-app-migration.md)
+ [線上遷移後停用 Cassandra](migration-online-decommission.md)