本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 建立遷移計畫，以從 Apache Cassandra 遷移至 Amazon Keyspaces
若要成功從 Apache Cassandra 遷移至 Amazon Keyspaces，建議您檢閱適用的遷移概念和最佳實務，以及可用選項的比較。
本主題概述遷移程序如何運作，方法是介紹幾個關鍵概念，以及您可以使用的工具和技術。您可以評估不同的遷移策略，以選取最符合您需求的遷移策略。
**Topics**
+ [功能相容性](#migrating-cassandra-compatibility)
+ [預估 Amazon Keyspaces 定價](#migrating-cassandra-sizing)
+ [選擇遷移策略](#migrating-cassandra-strategy)
+ [線上遷移至 Amazon Keyspaces：策略和最佳實務](migrating-online.md)
+ [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)
+ [使用混合遷移解決方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md)
## 功能相容性
在遷移之前，請仔細考慮 Apache Cassandra 和 Amazon Keyspaces 之間的功能差異。Amazon Keyspaces 支援所有常用的 Cassandra 資料平面操作，例如建立金鑰空間和資料表、讀取資料和寫入資料。
不過，Amazon Keyspaces 不支援一些 Cassandra APIs。如需支援 APIs的詳細資訊，請參閱 [支援的 Cassandra APIs、操作、函數和資料類型](cassandra-apis.md)。如需 Amazon Keyspaces 和 Apache Cassandra 之間所有功能差異的概觀，請參閱 [功能差異：Amazon Keyspaces 與 Apache Cassandra](functional-differences.md)。
若要比較您使用的 Cassandra APIs 和結構描述與 Amazon Keyspaces 中支援的功能，您可以執行 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) 上的 Amazon Keyspaces 工具組中提供的相容性指令碼。
**如何使用相容性指令碼**
1. 從 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) 下載相容性 Python 指令碼，並將其移至可存取現有 Apache Cassandra 叢集的位置。
1. 相容性指令碼使用與 類似的參數`CQLSH`。針對 `--host`和`--port`輸入 IP 地址，以及您用來連接和執行查詢到叢集中其中一個 Cassandra 節點的連接埠。
如果您的 Cassandra 叢集使用身分驗證，您也需要提供 `-username`和 `-password`。若要執行相容性指令碼，您可以使用下列命令。
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## 預估 Amazon Keyspaces 定價
本節提供從 Apache Cassandra 資料表收集所需資訊的概觀，以計算 Amazon Keyspaces 的預估成本。每個資料表都需要不同的資料類型、需要支援不同的 CQL 查詢，並維護獨特的讀取/寫入流量。
根據資料表來考慮您的需求，符合 Amazon Keyspaces 資料表層級的資源隔離和[讀取/寫入輸送量容量模式](ReadWriteCapacityMode.md)。使用 Amazon Keyspaces，您可以獨立定義資料表的讀取/寫入容量和[自動擴展政策](autoscaling.md)。
了解資料表需求可協助您根據功能、成本和遷移工作來排定遷移資料表的優先順序。
在遷移之前收集下列 Cassandra 資料表指標。此資訊有助於估算 Amazon Keyspaces 上的工作負載成本。
+ **資料表名稱** – 完整金鑰空間和資料表名稱的名稱。
+ **描述** – 資料表的描述，例如其使用方式，或其中存放的資料類型。
+ **每秒平均讀取**次數 – 在大型時間間隔內，相對於資料表的平均座標層級讀取次數。
+ **每秒平均寫入**次數 – 在大量時間間隔內，資料表的座標層級寫入平均次數。
+ 以**位元組為單位的平均資料列大小** – 以位元組為單位的平均資料列大小。
+ **以 GBs為單位的儲存體**大小 – 資料表的原始儲存體大小。
+ **讀取一致性明細** – 使用最終一致性 (`LOCAL_ONE` 或 `ONE`) 與強式一致性 () 的讀取百分比`LOCAL_QUORUM`。
此資料表顯示您在規劃遷移時需要彙整的資料表相關資訊範例。
****
| 資料表名稱 | Description | 每秒平均讀取數 | 每秒平均寫入數 | 平均資料列大小，以位元組為單位 | 儲存體大小，以 GBs為單位 | 讀取一致性明細 |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | 用來存放購物車歷史記錄 | 10,000 | 5,000 | 2，200 | 2,000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | 用來存放最新的設定檔資訊 | 20,000 | 1,000 | 850 | 1,000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### 如何收集資料表指標
本節提供如何從現有 Cassandra 叢集收集必要資料表指標的逐步說明。這些指標包括資料列大小、資料表大小和每秒讀取/寫入請求數 (RPS)。它們可讓您評估 Amazon Keyspaces 資料表的輸送量容量需求，並預估定價。
**如何在 Cassandra 來源資料表上收集資料表指標**
1. 判斷資料列大小
資料列大小對於判斷 Amazon Keyspaces 中的讀取容量和寫入容量使用率非常重要。下圖顯示 Cassandra 字符範圍內的典型資料分佈。
![\[圖表顯示使用murmur3分割區的 Cassandra 字符範圍的一般資料分佈。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
您可以使用 [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh) 上可用的資料列大小採樣器指令碼，收集 Cassandra 叢集中每個資料表的資料列大小指標。
指令碼會使用 `cqlsh`和 從 Apache Cassandra 匯出資料表資料，`awk`以計算資料列大小與可設定之資料表資料範例集之間的最小、最大、平均和標準差。資料列大小取樣器會將引數傳遞至 `cqlsh`，因此相同的參數可用於連接和讀取 Cassandra 叢集。
下列陳述式為範例。
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
如需如何在 Amazon Keyspaces 中計算資料列大小的詳細資訊，請參閱 [估計 Amazon Keyspaces 中的資料列大小](calculating-row-size.md)。
1. 決定資料表大小
使用 Amazon Keyspaces，您不需要預先佈建儲存體。Amazon Keyspaces 會持續監控資料表的計費大小，以判斷您的儲存費用。儲存空間按 GB 月計費。Amazon Keyspaces 資料表大小是根據單一複本的原始大小 （未壓縮）。
若要監控 Amazon Keyspaces 中的資料表大小，您可以使用指標 `BillableTableSizeInBytes`，該指標會針對 中的每個資料表顯示AWS 管理主控台。
若要預估 Amazon Keyspaces 資料表的計費大小，您可以使用下列兩種方法之一：
+ 使用平均資料列大小，並乘以數字或資料列。
您可以將平均資料列大小乘以 Cassandra 來源資料表中的資料列數，以估計 Amazon Keyspaces 資料表的大小。使用上一節的資料列大小範例指令碼來擷取平均的資料列大小。若要擷取資料列計數，您可以使用 等工具`dsbulk count`來判斷來源資料表中的資料列總數。
+ 使用 `nodetool`收集資料表中繼資料。
`Nodetool` 是 Apache Cassandra 分佈中提供的管理工具，可讓您深入了解 Cassandra 程序的狀態並傳回資料表中繼資料。您可以使用 `nodetool`來取樣資料表大小的中繼資料，並使用 來推斷 Amazon Keyspaces 中的資料表大小。
要使用的命令是 `nodetool tablestats`。Tablestats 會傳回資料表的大小和壓縮比。資料表的大小會儲存為資料表`tablelivespace`的 ，您可以將其除以 `compression ratio`。然後，將此大小值乘以節點數量。最後除以複寫係數 （通常是三個）。
這是計算的完整公式，您可以用來評估資料表大小。
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
假設您的 Cassandra 叢集有 12 個節點。執行 `nodetool tablestats`命令會傳回 `tablelivespace` 200 GB 的 和 0.5 `compression ratio`的 。金鑰空間的複寫係數為 3。
這是此範例的計算方式。
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. 擷取讀取和寫入次數
若要判斷 Amazon Keyspaces 資料表的容量和擴展需求，請在遷移之前擷取 Cassandra 資料表的讀取和寫入請求率。
Amazon Keyspaces 是無伺服器，您只需為使用量付費。一般而言，Amazon Keyspaces 中的讀取/寫入輸送量價格取決於請求的數量和大小。
Amazon Keyspaces 有兩種容量模式：
+ [隨需](ReadWriteCapacityMode.OnDemand.md) – 這是一個靈活的計費選項，能夠每秒處理數千個請求，而無需進行容量規劃。它提供讀取和寫入請求pay-per-request定價，因此您只需支付使用量的費用。
+ [佈建](ReadWriteCapacityMode.Provisioned.md) – 如果您選擇佈建輸送量容量模式，您可以指定應用程式所需的每秒讀取和寫入次數。這可協助您管理 Amazon Keyspaces 用量，以維持或低於定義的請求率，以維持可預測性。
佈建模式提供[自動擴展](autoscaling.md)功能，可自動調整佈建速率以擴展或縮減規模，以提升營運效率。如需無伺服器資源管理的詳細資訊，請參閱 [在 Amazon Keyspaces 中管理無伺服器資源 （適用於 Apache Cassandra)](serverless_resource_management.md)。
由於您在 Amazon Keyspaces 中分別佈建讀取和寫入輸送量容量，因此您需要獨立測量現有資料表中讀取和寫入的請求率。
若要從現有的 Cassandra 叢集收集最準確的使用率指標，請針對在單一資料中心所有節點上彙總的資料表，擷取長時間內協調器層級讀取和寫入操作的平均每秒請求數 (RPS)。
擷取至少數週內的平均 RPS 會擷取流量模式中的尖峰和山谷，如下圖所示。
![\[顯示兩週內每天每秒請求平均速率的圖表。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-rps.png)
您有兩個選項可判斷 Cassandra 資料表的讀取和寫入請求率。
+ 使用現有的 Cassandra 監控
您可以使用下表所示的指標來觀察讀取和寫入請求。請注意，指標名稱可能會根據您使用的監控工具而變更。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/migrating-cassandra.html)
+ 使用 `nodetool`
使用 `nodetool tablestats`和 從資料表`nodetool info`擷取平均讀取和寫入操作。 會`tablestats`傳回節點啟動後的總讀取和寫入計數。 會以秒為單位`nodetool info`提供節點的執行時間。
若要接收讀取和寫入的每秒平均值，請將讀取和寫入計數除以節點正常執行時間，以秒為單位。然後，對於讀取，您將除以一致性層級廣告，對於寫入，您將除以複寫係數。這些計算會以下列公式表示。
每秒平均讀取的公式：
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
每秒平均寫入的公式：
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
假設我們有 12 個節點叢集，已持續運作 4 週。 會`nodetool info`傳回 2，419，200 秒的正常運作時間，並`nodetool tablestats`傳回 10 億筆寫入和 20 億筆讀取。此範例將導致以下計算。
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. 判斷資料表的容量使用率
若要估計平均容量使用率，請從平均請求率和 Cassandra 來源資料表的平均資料列大小開始。
Amazon Keyspaces 使用*讀取容量單位* RCUs) 和*寫入容量單位* WCUs) 來測量資料表讀取和寫入的佈建輸送量容量。在此預估中，我們會使用這些單位來計算遷移後新 Amazon Keyspaces 資料表的讀取和寫入容量需求。
本主題稍後將討論佈建容量模式和隨需容量模式之間的選擇如何影響帳單。但是在此範例中，對於容量使用率的預估，我們假設資料表處於佈建模式。
+ **讀取** – 一個 RCU 代表最大 4 KB 的資料列一個`LOCAL_QUORUM`讀取請求或兩個`LOCAL_ONE`讀取請求。如果您需要讀取大於 4 KB 的資料列，則讀取操作會使用其他 RCUs。所需的 RCUs 總數取決於資料列大小，以及您是否要使用或`LOCAL_QUORUM``LOCAL_ONE`讀取一致性。
例如，讀取 8 KB 資料列需要 2 個使用`LOCAL_QUORUM`讀取一致性RCUs，如果您選擇`LOCAL_ONE`讀取一致性，則需要 1 個 RCU。
+ **寫入** – 一個 WCU 代表大小上限為 1 KB 的資料列一個寫入。所有寫入都使用`LOCAL_QUORUM`一致性，而且使用輕量型交易 (LWTs) 無需額外付費。
所需的 WCUs 總數取決於資料列大小。如果您需要寫入大於 1 KB 的資料列，則寫入操作會使用其他 WCUs。例如，如果您的資料列大小為 2 KB，則需要 2 WCUs 來執行一個寫入請求。
下列公式可用來預估所需的 RCUs 和 WCUs。
+ **RCUs中的讀取容量**可以透過將每秒讀取數乘以每個讀取的讀取資料列數乘以平均資料列大小除以 4KB 並四捨五入至最接近的整數來判斷。
+ **WCUs中的寫入容量**可以透過將請求數量乘以平均資料列大小除以 1KB 並四捨五入至最接近的整數來決定。
這在下列公式中表示。
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
例如，如果您在 Cassandra 資料表上執行的資料列大小為 2.5KB 的 4，960 個讀取請求，則需要 Amazon Keyspaces 中的 4，960 RCUs。如果您目前在 Cassandra 資料表上執行每秒 1，653 個寫入請求，且資料列大小為 2.5KB，則 Amazon Keyspaces 中需要每秒 4，959 個 WCUs。
此範例以下列公式表示。
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
使用 `eventual consistency`可讓您在每個讀取請求上儲存高達輸送量容量的一半。每個最終一致讀取最多可耗用 8KB。您可以計算最終一致性讀取，方法是將先前的計算乘以 0.5，如下列公式所示。
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. 計算 Amazon Keyspaces 的每月定價預估
若要根據讀取/寫入容量輸送量預估資料表的每月帳單，您可以使用不同的公式計算隨需和佈建模式的定價，並比較資料表的選項。
**佈建模式** – 讀取和寫入容量消耗會根據每秒容量單位的每小時費率計費。首先，將該速率除以 0.7，表示預設自動擴展目標使用率為 70%。然後乘以 30 個日曆天、每天 24 小時，以及區域費率定價。
此計算摘要於下列公式中。
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**隨需模式** – 讀取和寫入容量是以每個請求速率計費。首先，將請求率乘以 30 個日曆天和每天 24 小時。然後除以一百萬個請求單位。最後，將 乘以區域費率。
此計算摘要於下列公式中。
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## 選擇遷移策略
從 Apache Cassandra 遷移至 Amazon Keyspaces 時，您可以選擇下列遷移策略：
+ **線上** – 這是使用雙寫入開始同時將新資料寫入 Amazon Keyspaces 和 Cassandra 叢集的即時遷移。對於在遷移期間需要零停機時間並在寫入一致性後讀取的應用程式，建議使用此遷移類型。
如需如何規劃和實作線上遷移策略的詳細資訊，請參閱 [線上遷移至 Amazon Keyspaces：策略和最佳實務](migrating-online.md)。
+ **離線** – 此遷移技術涉及在停機時間期間將資料集從 Cassandra 複製到 Amazon Keyspaces。離線遷移可以簡化遷移程序，因為它不需要變更您的應用程式，或在歷史資料和新寫入之間解決衝突。
如需如何規劃離線遷移的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。
+ **混合** – 此遷移技術允許近乎即時地將變更複寫至 Amazon Keyspaces，但在寫入一致性後無需讀取。
如需如何規劃混合遷移的詳細資訊，請參閱 [使用混合遷移解決方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md)。
檢閱本主題中討論的遷移技術和最佳實務後，您可以在決策樹中放置可用的選項，以根據您的需求和可用的資源設計遷移策略。
# 線上遷移至 Amazon Keyspaces：策略和最佳實務
如果您需要在從 Apache Cassandra 遷移至 Amazon Keyspaces 期間維持應用程式的可用性，您可以實作本主題討論的關鍵元件，以準備自訂線上遷移策略。透過遵循線上遷移的這些最佳實務，您可以確保在整個遷移過程中維持應用程式可用性和read-after-write一致性，將對使用者的影響降至最低。
設計從 Apache Cassandra 到 Amazon Keyspaces 的線上遷移策略時，您需要考慮下列關鍵步驟。
1. **寫入新資料**
+ **Amazon Keyspaces 遷移的 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)
# 在線上遷移期間撰寫新資料
線上遷移計畫的第一步是確保應用程式寫入的任何新資料都存放在兩個資料庫、您現有的 Cassandra 叢集和 Amazon Keyspaces 中。目標是跨兩個資料存放區提供一致的檢視。您可以將所有新的寫入套用至兩個資料庫來執行此操作。若要實作雙寫入，請考慮下列三個選項之一。
+ **ZDM Dual Write Proxy for Amazon Keyspaces Migration** – 使用 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Proxy for Amazon Keyspaces，您可以將 Apache Cassandra 工作負載遷移至 Amazon Keyspaces，而不會造成應用程式停機。此增強型解決方案實作AWS最佳實務，並擴展官方 ZDM Proxy 功能。
+ 在 Apache Cassandra 和 Amazon Keyspaces 之間執行線上遷移。
+ 在不重構應用程式的情況下，同時將資料寫入來源和目標資料表。
+ 透過雙讀取操作驗證查詢。
解決方案提供下列增強功能，以使用 AWS和 Amazon Keyspaces。
+ **容器部署** – 使用來自 Amazon Elastic Container Registry (Amazon ECR) 的預先設定 Docker 映像進行 VPC 可存取的部署。
+ **基礎設施即程式碼** – 使用 AWS CloudFormation範本部署以自動設定AWS Fargate。
+ **Amazon Keyspaces 相容性** – 使用 Amazon Keyspaces 的自訂調整來存取系統資料表。
解決方案透過 Fargate 在 Amazon ECS 上執行，根據您的工作負載需求提供無伺服器可擴展性。網路負載平衡器會將傳入的應用程式流量分散到多個 Amazon ECS 任務，以獲得高可用性。
![\[實作 ZDM 雙寫入代理，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **應用程式雙重寫入** – 您可以利用現有的 Cassandra 用戶端程式庫和驅動程式，在應用程式程式碼變更最少的情況下實作雙重寫入。您可以在現有應用程式中實作雙寫入，或在架構中建立新的 layer 來處理雙寫入。如需詳細資訊，以及顯示如何在現有應用程式中實作雙重寫入的客戶案例研究，請參閱 [Cassandra 遷移案例研究](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/)。
實作雙重寫入時，您可以將一個資料庫指定為領導者，將另一個資料庫指定為跟隨者。這可讓您繼續寫入原始來源或領導資料庫，而不會讓後續的寫入失敗，或目的地資料庫中斷應用程式的關鍵路徑。
您可以使用 Amazon Simple Queue Service 在[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 中記錄失敗的寫入，而不是重試失敗的寫入至追隨者。DLQ 可讓您分析對追隨者的失敗寫入，並判斷為什麼在目的地資料庫中處理未成功。
如需更複雜的雙寫入實作，您可以遵循使用 [saga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html)設計一系列本機交易的AWS最佳實務。saga 模式可確保如果交易失敗，saga 會執行補償性交易，以還原先前交易所做的資料庫變更。
使用雙寫入進行線上遷移時，您可以依照 saga 模式設定雙寫入，以便每次寫入都是本機交易，以確保異質資料庫之間的原子操作。如需使用建議的 設計模式來設計分散式應用程式的詳細資訊AWS 雲端，請參閱[雲端設計模式、架構和實作](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)。
![\[從 Apache Cassandra 遷移至 Amazon Keyspaces 時，在應用程式層實作雙寫入。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **訊息層雙重寫入** – 您可以使用現有的訊息層對 Cassandra 和 Amazon Keyspaces 執行雙重寫入，而不是在應用程式層實作雙重寫入。
若要這樣做，您可以將其他消費者設定為您的簡訊平台，將寫入傳送至這兩個資料存放區。此方法使用訊息層提供簡單的低程式碼策略，在兩個資料庫之間建立兩個最終一致的檢視。
# 在線上遷移期間上傳歷史資料
實作雙重寫入以確保即時將新資料寫入兩個資料存放區後，遷移計劃的下一個步驟是評估您需要多少歷史資料才能從 Cassandra 複製或大量上傳至 Amazon Keyspaces。這可確保在您遷移應用程式之前，新資料和歷史資料都可以在新的 Amazon Keyspaces 資料庫中使用。
根據您的資料保留需求，例如，您需要根據組織政策保留多少歷史資料，您可以考慮以下兩個選項之一。
+ **大量上傳歷史資料** – 歷史資料從現有 Cassandra 部署遷移到 Amazon Keyspaces 可以透過各種技術實現，例如使用 AWS Glue或自訂指令碼來擷取、轉換和載入 (ETL) 資料。如需使用 AWS Glue上傳歷史資料的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。
規劃大量上傳歷史資料時，您需要考慮如何解決新寫入嘗試更新上傳過程中相同資料時可能發生的衝突。大量上傳預期最終會一致，這表示資料最終將到達所有節點。
如果因為新的寫入而同時發生相同資料的更新，您希望確保不會被歷史資料上傳覆寫。為了確保即使在大量匯入期間仍能保留資料的最新更新，您必須將衝突解決方法新增至大量上傳指令碼或應用程式邏輯中，以進行雙重寫入。
例如，您可以使用 [輕量型交易](functional-differences.md#functional-differences.light-transactions)(LWT) 來比較和設定操作。若要這樣做，您可以將代表修改或狀態時間的額外欄位新增至資料模型。
此外，Amazon Keyspaces 支援 Cassandra `WRITETIME`時間戳記函數。您可以使用 Amazon Keyspaces 用戶端時間戳記來保留來源資料庫時間戳記，並實作last-writer-wins衝突解決方案。如需詳細資訊，請參閱[Amazon Keyspaces 中的用戶端時間戳記](client-side-timestamps.md)。
+ **使用Time-to-Live(TTL)** – 對於少於 30、60 或 90 天的資料保留期，您可以在遷移期間在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免將不必要的歷史資料上傳到 Amazon Keyspaces。TTL 可讓您設定一段時間，之後資料會自動從資料庫移除。
在遷移階段，您可以設定 TTL 設定，讓歷史資料在舊系統 (Cassandra) 中自動過期，同時僅使用雙寫入方法將新寫入套用至 Amazon Keyspaces。隨著時間的推移，使用舊資料持續在 Cassandra 叢集中過期，並使用雙寫入方法寫入的新資料，Amazon Keyspaces 會自動追上 ，以包含與 Cassandra 相同的資料。
這種方法可以大幅減少要遷移的資料量，進而產生更有效率且簡化的遷移程序。您可以在處理具有不同資料保留需求的大型資料集時考慮此方法。如需 TTL 的詳細資訊，請參閱 [使用 Amazon Keyspaces 的存留時間 (TTL) 過期資料 （適用於 Apache Cassandra)](TTL.md)。
請考慮下列使用 TTL 資料過期從 Cassandra 遷移至 Amazon Keyspaces 的範例。在此範例中，我們將兩個資料庫的 TTL 設定為 60 天，並顯示遷移程序在 90 天期間如何進行。在此期間，兩個資料庫都會使用雙寫入方法來接收相同的新寫入資料。我們將查看遷移的三個不同階段，每個階段為期 30 天。
遷移程序在每個階段的運作方式會顯示在下列影像中。
![\[從 Apache Cassandra 遷移至 Amazon Keyspaces 時，使用 TTL 使歷史資料過期。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 在前 30 天之後，Cassandra 叢集和 Amazon Keyspaces 一直收到新的寫入。Cassandra 叢集也包含尚未達到 60 天保留的歷史資料，由叢集中 50% 的資料組成。
超過 60 天的資料會在 Cassandra 叢集中使用 TTL 自動刪除。此時，Amazon Keyspaces 包含存放在 Cassandra 叢集中的 50% 資料，由新寫入減去歷史資料組成。
1. 60 天後，Cassandra 叢集和 Amazon Keyspaces 都包含過去 60 天內寫入的相同資料。
1. 在 90 天內，Cassandra 和 Amazon Keyspaces 都包含相同的資料，並以相同的速率過期資料。
此範例說明如何使用過期日期設定為 60 天的 TTL 來避免上傳歷史資料的步驟。
# 驗證線上遷移期間的資料一致性
線上遷移程序的下一個步驟是資料驗證。雙重寫入正在將新資料新增至 Amazon Keyspaces 資料庫，而且您已完成使用大量上傳或資料過期搭配 TTL 遷移歷史資料。
現在，您可以使用驗證階段來確認兩個資料存放區實際上都包含相同的資料，並傳回相同的讀取結果。您可以選擇以下兩個選項之一，以驗證兩個資料庫都包含相同的資料。
+ **雙重讀取** – 若要驗證來源和目的地資料庫是否包含相同的一組新寫入和歷史資料，您可以實作雙重讀取。若要這樣做，您會從主要 Cassandra 和次要 Amazon Keyspaces 資料庫讀取，類似於雙重寫入方法，並以非同步方式比較結果。
來自主要資料庫的結果會傳回給用戶端，而來自次要資料庫的結果會用來驗證主要結果集。找到的差異可以記錄或傳送至[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 以供日後調校。
在下圖中，應用程式正在從主要資料存放區 Cassandra 執行同步讀取），並從次要資料存放區 Amazon Keyspaces 執行非同步讀取。
![\[在從 Apache Cassandra 線上遷移至 Amazon Keyspaces 期間，使用雙重讀取來驗證資料一致性。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **範例讀取** – 不需要變更應用程式程式碼的替代解決方案是使用 AWS Lambda函數，定期並隨機從來源 Cassandra 叢集和目的地 Amazon Keyspaces 資料庫取樣資料。
這些 Lambda 函數可設定為定期執行。Lambda 函數會從來源和目的地系統擷取資料的隨機子集，然後執行取樣資料的比較。兩個資料集之間的任何差異或不相符都可以記錄並傳送到專用[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 以供日後調校。
下表說明此程序。
![\[使用範例讀取來驗證從 Apache Cassandra 到 Amazon Keyspaces 的 和線上遷移期間的資料一致性。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# 在線上遷移期間遷移應用程式
在線上遷移的第四階段中，您要遷移應用程式，並轉換為 Amazon Keyspaces 做為主要資料存放區。這表示您將應用程式切換為直接從 Amazon Keyspaces 讀取和寫入。為了確保對使用者的干擾降到最低，這應該是妥善規劃和協調的程序。
提供兩種不同的應用程式遷移建議解決方案：藍色綠色切入策略和金絲雀切入策略。下列各節會更詳細地概述這些策略。
+ **藍色綠色策略** – 使用此方法，您可以切換應用程式，將 Amazon Keyspaces 視為主要資料存放區，並在單一步驟中將 Cassandra 視為次要資料存放區。您可以使用AWS AppConfig功能旗標來控制整個應用程式執行個體中主要和次要資料存放區的選擇。如需特徵標記的詳細資訊，請參閱在 [中建立特徵標記組態描述AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)檔。
讓 Amazon Keyspaces 成為主要資料存放區後，您可以監控應用程式的行為和效能，確保 Amazon Keyspaces 符合您的需求，且遷移成功。
例如，如果您為應用程式實作雙讀取，在應用程式遷移階段，您將主要讀取從 Cassandra 轉換為 Amazon Keyspaces，次要讀取從 Amazon Keyspaces 轉換為 Cassandra。轉換後，您可以繼續監控和比較[資料驗證](migration-online-validation.md)一節中所述的結果，以確保在停用 Cassandra 之前兩個資料庫之間的一致性。
如果您偵測到任何問題，您可以透過還原至 Cassandra 做為主要資料存放區，快速復原至先前的狀態。只有在 Amazon Keyspaces 符合您作為主要資料存放區的所有需求時，您才能繼續遷移的停用階段。
![\[使用藍色綠色策略，將應用程式從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Canary 策略** – 在此方法中，您會逐步將遷移推展到使用者或流量的子集。最初，您應用程式流量的一小部分，例如 5% 的所有流量會使用 Amazon Keyspaces 做為主要資料存放區路由至版本，而其餘流量則會繼續使用 Cassandra 做為主要資料存放區。
這可讓您使用實際流量徹底測試遷移的版本，並監控其效能、穩定性和調查潛在問題。如果您未偵測到任何問題，您可以逐步增加路由到 Amazon Keyspaces 的流量百分比，直到它成為所有使用者和流量的主要資料存放區為止。
此階段推展可將廣泛服務中斷的風險降至最低，並允許更受控制的遷移程序。如果在 Canary 部署期間發生任何重大問題，您可以使用 Cassandra 作為受影響流量區段的主要資料存放區，快速復原至先前的版本。只有在您驗證 Amazon Keyspaces 可如預期處理 100% 的使用者和流量之後，您才能繼續遷移的解除委任階段。
下圖說明 Canary 策略的個別步驟。
![\[使用 Canary 策略將應用程式從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# 線上遷移後停用 Cassandra
應用程式遷移完成後，您的應用程式會在 Amazon Keyspaces 上完全執行，而且您已驗證一段時間的資料一致性，您可以計劃停用 Cassandra 叢集。在此階段，您可以評估 Cassandra 叢集中剩餘的資料是否需要封存或可以刪除。這取決於您組織的資料處理和保留政策。
透過遵循此策略，並在規劃從 Cassandra 到 Amazon Keyspaces 的線上遷移時考慮本主題中描述的建議最佳實務，您可以確保無縫轉換至 Amazon Keyspaces，同時保持應用程式的read-after-write一致性和可用性。
從 Apache Cassandra 遷移到 Amazon Keyspaces 可以提供許多好處，包括降低營運開銷、自動擴展、改善安全性，以及協助您實現合規目標的架構。透過規劃具有雙重寫入、歷史資料上傳、資料驗證和漸進推展的線上遷移策略，您可以確保順暢的轉換，並將對應用程式及其使用者的干擾降至最低。
實作本主題中討論的線上遷移策略，可讓您驗證遷移結果、識別和解決任何問題，最終停用現有的 Cassandra 部署，以享有全受管 Amazon Keyspaces 服務。
# 離線遷移程序：Apache Cassandra 到 Amazon Keyspaces
當您可以負擔執行遷移的停機時間時，離線遷移是合適的。企業之間通常會有修補、大型版本或停機時間的維護時段，以進行硬體升級或主要升級。離線遷移可以使用此視窗來複製資料，並將應用程式流量從 Apache Cassandra 切換到 Amazon Keyspaces。
離線遷移可減少對應用程式的修改，因為它不需要同時與 Cassandra 和 Amazon Keyspaces 通訊。此外，在資料流程暫停的情況下，可以在不維護變動的情況下複製確切狀態。
在此範例中，我們使用 Amazon Simple Storage Service (Amazon S3) 做為離線遷移期間資料的預備區域，將停機時間降至最低。您可以使用 Spark Cassandra 連接器 和 ，將您以 Parquet 格式存放在 Amazon S3 中的資料自動匯入 Amazon Keyspaces 資料表AWS Glue。下一節將展示程序的高階概觀。您可以在 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue) 上找到此程序的程式碼範例。
使用 Amazon S3 從 Apache Cassandra 到 Amazon Keyspaces 的離線遷移程序，AWS Glue需要下列AWS Glue任務。
1. 擷取和轉換 CQL 資料並將其存放在 Amazon S3 儲存貯體的 ETL 任務。
1. 將資料從儲存貯體匯入 Amazon Keyspaces 的第二個任務。
1. 匯入增量資料的第三個任務。
**如何在 Amazon Virtual Private Cloud 中從在 Amazon EC2 上執行的 Cassandra 執行離線遷移至 Amazon Keyspaces Amazon Virtual Private Cloud**
1. 首先，使用 從 Cassandra 以 Parquet 格式AWS Glue匯出資料表資料，並將其儲存至 Amazon S3 儲存貯體。您需要使用連接至執行 Cassandra 之 Amazon EC2 執行個體所在 VPC 的AWS Glue連接器來執行AWS Glue任務。然後，使用 Amazon S3 私有端點，您可以將資料儲存到 Amazon S3 儲存貯體。
下圖說明這些步驟。
![\[使用 從 VPC 中執行的 Amazon EC2 將 Apache Cassandra 資料遷移至 Amazon S3 儲存貯體AWS Glue。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-export.png)
1. 隨機播放 Amazon S3 儲存貯體中的資料，以改善資料隨機化。平均匯入的資料允許目標資料表中的更多分散式流量。
從具有大型分割區 （超過 1000 個資料列的分割區） 的 Cassandra 匯出資料時需要此步驟，以避免將資料插入 Amazon Keyspaces 時出現熱鍵模式。熱鍵問題會在 Amazon Keyspaces `WriteThrottleEvents`中造成，並導致載入時間增加。
![\[AWS Glue任務會從 Amazon S3 儲存貯體隨機播放資料，並將其傳回至另一個 Amazon S3 儲存貯體。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. 使用另一個AWS Glue任務將資料從 Amazon S3 儲存貯體匯入 Amazon Keyspaces。Amazon S3 儲存貯體中的隨機資料會以 Parquet 格式儲存。
![\[AWS Glue匯入任務會從 Amazon S3 儲存貯體取得隨機資料，並將其移至 Amazon Keyspaces 資料表。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/migration-import.png)
如需離線遷移程序的詳細資訊，請參閱研討會 [ Amazon Keyspaces withAWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue)
# 使用混合遷移解決方案：Apache Cassandra 到 Amazon Keyspaces
下列遷移解決方案可視為線上和離線遷移之間的混合。透過這種混合方法，資料會以近乎即時的方式寫入目的地資料庫，而不會在寫入一致性後提供讀取。這表示新寫入的資料不會立即可用，且預期會發生延遲。如果您需要寫入一致性後的讀取，請參閱 [線上遷移至 Amazon Keyspaces：策略和最佳實務](migrating-online.md)。
若要從 Apache Cassandra 近乎即時地遷移至 Amazon Keyspaces，您可以選擇兩種可用的方法。
+ **CQLReplicator** – （建議） CQLReplicator 是 [Github](https://github.com/aws-samples/cql-replicator) 上提供的開放原始碼公用程式，可協助您近乎即時地將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。
為了判斷要傳播到目的地資料庫的寫入和更新，CQLReplicator 會掃描 Apache Cassandra 字符範圍，並使用 AWS Glue任務來移除重複的事件，並直接將寫入和更新套用至 Amazon Keyspaces。
+ **變更資料擷取 (CDC)** – 如果您熟悉 Cassandra CDC，則透過將遞交日誌複製到單獨的 CDC 目錄來允許擷取變更的 Apache Cassandra 內建 CDC 功能是實作混合遷移的另一個選項。
您可以將資料變更複寫至 Amazon Keyspaces，讓 CDC 成為資料遷移案例的替代選項。
如果您在寫入一致性後不需要讀取，則可以使用 CQLReplicator 或 CDC 管道，根據您的偏好和對工具的熟悉程度，將資料從 Apache Cassandra 遷移到 Amazon KeyspacesAWS 服務。使用這些方法來近乎即時地遷移資料，可視為遷移的混合方法，提供線上遷移的替代方案。
此策略被視為混合式方法，因為除了本主題中概述的選項之外，您還必須實作線上遷移進度的一些步驟，例如歷史資料複製和[線上遷移主題中討論的應用程式遷移](migrating-online.md)策略。
以下章節會詳細說明混合遷移選項。
**Topics**
+ [使用 CQLReplicator 遷移資料](migration-hybrid-cql-rep.md)
+ [使用變更資料擷取 (CDC) 遷移資料](migration-hybrid-cdc.md)
# 使用 CQLReplicator 遷移資料
使用 [CQLReplicator](https://github.com/aws-samples/cql-replicator)，您可以使用 CQL 查詢智慧掃描 Cassandra 字符環，近乎即時地從 Apache Cassandra 讀取資料。CQLReplicator 不使用 Cassandra CDC，而是實作快取策略，以減少完整掃描的效能懲罰。
為了減少目的地的寫入次數，CQLReplicator 會自動移除重複的複寫事件。使用 CQLReplicator，您可以調整從來源資料庫到目的地資料庫的變更複寫，以便近乎即時地將資料從 Apache Cassandra 遷移到 Amazon Keyspaces。
下圖顯示 CQLReplicator 任務使用的一般架構AWS Glue。
1. 若要允許存取在私有 VPC 中執行的 Apache Cassandra，請設定與AWS Glue連線類型 **Network** 的連線。
1. 若要使用 CQLReplicator 任務移除重複項目並啟用金鑰快取，請設定 Amazon Simple Storage Service (Amazon S3)。
1. CQLReplicator 任務會將已驗證的來源資料庫直接變更為 Amazon Keyspaces。
![\[使用 CQLReplicator 將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
如需使用 CQLReplicator 遷移程序的詳細資訊，請參閱下列文章：AWS資料庫部落格[使用 CQLReplicator 將 Cassandra 工作負載遷移至 Amazon Keyspaces](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/)，AWS以及[使用 將 Apache Cassandra 工作負載遷移至 Amazon KeyspacesAWS Glue](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html) 的規範指引。
# 使用變更資料擷取 (CDC) 遷移資料
如果您已經熟悉使用 [Debezium](https://debezium.io/) 設定變更資料擷取 (CDC) 管道，您可以使用此選項將資料遷移到 Amazon Keyspaces，作為使用 CQLReplicator 的替代方案。Debezium 是 CDC 的開放原始碼分散式平台，旨在監控資料庫並可靠地擷取資料列層級的變更。
[Apache Cassandra 的 Debezium 連接器](https://debezium.io/documentation/reference/stable/connectors/cassandra.html)會將變更上傳至 Amazon Managed Streaming for Apache Kafka (Amazon MSK)，讓下游消費者可以取用和處理這些變更，進而將資料寫入 Amazon Keyspaces。如需詳細資訊，請參閱[從 Apache Cassandra 到 Amazon Keyspaces 的持續資料遷移指南](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)。
若要解決任何潛在的資料一致性問題，您可以使用 Amazon MSK 實作程序，其中取用者會將 Cassandra 中的金鑰或分割區與 Amazon Keyspaces 中的金鑰或分割區進行比較。
若要成功實作此解決方案，建議您考慮下列事項。
+ 如何剖析 CDC 遞交日誌，例如如何移除重複的事件。
+ 如何維護 CDC 目錄，例如如何刪除舊日誌。
+ 如何處理 Apache Cassandra 中的部分故障，例如，如果寫入在三個複本中只有一個成功。
+ 如何處理資源配置，例如增加執行個體的大小，以考量節點上 CDC 程序的額外 CPU、記憶體、DIK 和 IO 需求。
此模式會將來自 Cassandra 的變更視為「提示」，表示金鑰可能已從先前的狀態變更。若要判斷是否有變更要傳播到目的地資料庫，您必須先使用 `LOCAL_QUORUM`操作從來源 Cassandra 叢集讀取，以接收最新的記錄，然後將其寫入 Amazon Keyspaces。
在範圍刪除或範圍更新的情況下，您可能需要對整個分割區執行比較，以判斷哪些寫入或更新事件需要寫入目的地資料庫。
如果寫入不等冪，您也需要在寫入 Amazon Keyspaces 之前，將寫入與目的地資料庫中已存在的寫入進行比較。
下圖顯示使用 Debezium 和 Amazon MSK 的 CDC 管道典型架構。
![\[使用變更資料擷取管道，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)