本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 创建从 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 数据面板操作，例如创建键空间和表、读取数据和写入数据。
但是，有些 Cassandra APIs 是 Amazon Keyspaces 不支持的。有关支持的更多信息 APIs，请参阅[支持 Cassandra APIs、操作、函数和数据类型](cassandra-apis.md)。有关 Apache 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)
**如何使用兼容性脚本**
1. 从下载兼容的 Python 脚本[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)并将其移动到可以访问现有 Apache Cassandra 集群的位置。
1. 兼容性脚本使用的参数与 `CQLSH` 类似。对于 `--host` 和 `--port`，输入用于连接集群中的一个 Cassandra 节点并对该节点运行查询的 IP 地址和端口。
如果您的 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 查询并保持独特的 read/write 流量。
根据表考虑您的需求，与 Amazon Keyspaces 表级资源隔离以及[读/写吞吐能力模式](ReadWriteCapacityMode.md)保持一致。借助 Amazon Keyspaces，您可以单独为表定义读/写容量和[自动扩缩策略](autoscaling.md)。
了解表的要求有助于您根据功能、成本和迁移工作量确定要迁移的表的优先级。
在迁移之前，请收集以下 Cassandra 表指标。这些信息有助于估算您在 Amazon Keyspaces 上的工作负载的成本。
+ **表名** - 完全限定键空间的名称和表名。
+ **描述** - 对表的描述，例如表的使用方式或其中存储的数据类型。
+ **每秒平均读取数** - 在较长时间间隔内对表进行的协调器级平均读取数。
+ **每秒平均写入数** - 在较长时间间隔内对表进行的协调器级平均写入数。
+ **平均行大小（以字节为单位）**- 以字节为单位的平均行大小。
+ **中的存储大小 GBs**-表的原始存储大小。
+ **读取一致性明细** - 使用最终一致性（`LOCAL_ONE` 或 `ONE`）与强一致性（`LOCAL_QUORUM`）的读取百分比。
下表显示了计划迁移时需要汇总的表信息的示例。
****
| 表名 | 说明 | 每秒平均读取数 | 每秒平均写入数 | 平均行大小（字节） | 存储空间大小 GBs | 读取一致性细分 |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | 用于存储购物车历史记录 | 10000 | 5000 | 2,200 | 2000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | 用于存储最新个人资料信息 | 20000 | 1000 | 850 | 1000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### 如何收集表指标
本节提供了有关如何从现有 Cassandra 集群中收集必要的表指标的分步说明。这些指标包括行大小、表大小和每秒 read/write 请求数 (RPS)。通过这些信息，您可以评估 Amazon Keyspaces 表的吞吐能力要求并估算定价。
**如何在 Cassandra 源表上收集表指标**
1. 确定行大小
行大小对于确定 Amazon Keyspaces 中的读取容量和写入容量利用率非常重要。下图显示了 Cassandra 令牌范围内的典型数据分布。
![\[使用 murmur3 分区程序显示 Cassandra 令牌范围内典型数据分布的示意图。\]](http://docs.aws.amazon.com/zh_cn/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` 和 `awk` 从 Apache Cassandra 导出表数据，来基于一组可配置的表数据样本计算行大小的最小值、最大值、平均值以及标准差。行大小采样器将参数传递给 `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`。然后将此大小值乘以节点数。最后除以复制因子（通常为 3）。
这是可用于评估表大小的完整计算公式。
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
假设你的 Cassandra 集群有 12 个节点。运行 `nodetool tablestats` 命令会返回 200GB 的 `tablelivespace` 和 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 的 read/write 吞吐量价格取决于请求的数量和大小。
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_cn/keyspaces/latest/devguide/images/migration/migration-rps.png)
您可以通过两个选项来确定 Cassandra 表的读取和写入请求速率。
+ 使用现有的 Cassandra 监控
您可以使用下表所示的指标来观察读/写请求。请注意，指标名称可能会因您使用的监控工具而有所差异。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/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` 会返回 2419200 秒的正常运行时间，`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 表的读取和写入容量需求。
在本主题的后面部分，我们将讨论在预置容量模式和按需容量模式之间的选择会对计费会有怎样的影响。但是在此示例中，为了估算容量利用率，我们假设该表处于预置模式下。
+ **读取** – 对于大小不超过 4 KB 的行，一个 RCU 代表一个 `LOCAL_QUORUM` 读取请求，或两个 `LOCAL_ONE` 读取请求。如果您需要读取大于 4 KB 的行，则读取操作会使用额外的 RCUs。 RCUs 所需的总数取决于行大小，以及您是要使用一致性`LOCAL_QUORUM`还是`LOCAL_ONE`读取一致性。
例如， RCUs 使用读取一致性读取 8 KB 的行需要 2 个，如果您选择`LOCAL_QUORUM``LOCAL_ONE`读取一致性，则需要 1 个 RCU。
+ **写入** – 对于大小不超过 1 KB 的行，一个 WCU 代表一次写入。所有写入操作都使用`LOCAL_QUORUM`一致性，使用轻量级事务 (LWTs) 不收取额外费用。
WCUs 所需的总数取决于行大小。如果您需要写入大于 1 KB 的行，则写入操作会使用额外的 WCUs。例如，如果您的行大小为 2 KB，则需要有 2 KB 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 表上执行 4,960 个读取请求，行大小为 2.5KB，则在 Amazon Keyspaces 中需要 4,960 个读取请求。 RCUs 如果您目前在 Cassandra 表上每秒执行 1,653 个写入请求，行大小为 2.5KB，则亚马逊密钥空间中每秒需要执行 4,9 WCUs 59 个写入请求。
此示例用以下公式表示。
```
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 的每月价格估算
要根据 read/write 容量吞吐量估算表的每月账单，您可以使用不同的公式计算按需模式和预置模式的定价，并比较表的选项。
**预置模式** - 读取和写入容量消耗按小时费率计费，基于每秒的容量单位数。首先，将该费率除以 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 小时。然后除以 100 万个请求单位。最后，乘以区域费率。
此计算总结为以下公式。
```
((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. **写入新数据**
+ **用于亚马逊密钥空间迁移的 ZDM 双写代理** — 使用 Github [上](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)提供的 ZDM 双写代理执行从 Apache Cassandra 到亚马逊密钥空间的零停机迁移。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 视为辅助数据存储。监控性能并在出现问题时进行回滚。
+ 金丝雀部署：首先向部分用户逐步推出迁移，逐步增加流向作为主数据库的 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 双写代理 — 使用 Github [上](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)提供的适用于亚马逊密钥空间**的 ZDM 代理，您可以将 Apache Cassandra 工作负载迁移到亚马逊密钥空间，而无需应用程序停机。此增强型解决方案实施了AWS最佳实践，并扩展了官方 ZDM 代理功能。
+ 在 Apache Cassandra 和 Amazon Keyspaces 之间进行在线迁移。
+ 无需重构应用程序，即可同时向源表和目标表写入数据。
+ 通过双读操作验证查询。
该解决方案为使用AWS和 Amazon Keyspaces 提供了以下增强功能。
+ **容器部署** — 使用来自亚马逊弹性容器注册表 (Amazon ECR) Registry 的预先配置的 Docker 镜像进行可访问 VPC 的部署。
+ **基础架构即代码** — 使用AWS CloudFormation模板进行部署以实现自动设置AWS Fargate。
+ **Amazon Keyspaces 兼容性 — 访问带有针对亚马逊密钥空间**的自定义改编版的系统表。
该解决方案在带有 Fargate 的 Amazon ECS 上运行，可根据您的工作负载需求提供无服务器可扩展性。网络负载均衡器将传入的应用程序流量分配到多个 Amazon ECS 任务中，以实现高可用性。
![\[实施 ZDM 双写代理，用于将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **应用程序双重写入** - 您可以使用现有的 Cassandra 客户端库和驱动程序实现双重写入，将对应用程序代码的更改降至最少。您可以在现有应用程序中实现双重写入，也可以在架构中创建新层来处理双重写入。有关更多信息以及展示如何在现有应用程序中实现双重写入的客户案例研究，请参阅 [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 让您可以分析跟随设备的写入失败操作，并确定目标数据库中处理未成功的原因。
对于更复杂的双写入实现，您可以遵循AWS最佳实践，使用 s [aga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html)设计一系列本地事务。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_cn/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，以避免将不必要的历史数据上传到亚马逊密钥空间。TTL 让您可以设置一个时间段，在此之后数据将自动从数据库中删除。
在迁移阶段，您无需将历史数据复制到 Amazon Keyspaces，而是可以配置 TTL 设置，让历史数据在旧系统（Cassandra）中自动过期，同时使用双重写入方法将新写入内容应用到 Amazon Keyspaces。久而久之，随着 Cassandra 集群中的旧数据不断过期，同时使用双重写入方法写入新数据，Amazon Keyspaces 会自动赶上来，最终包含与 Cassandra 相同的数据。
这种方法可以显著减少要迁移的数据量，从而提高迁移过程的效率和精简性。在处理具有不同数据留存要求的大型数据集时，可以考虑使用这种方法。有关 TTL 的更多信息，请参阅[使用 Amazon Keyspaces（Apache Cassandra 兼容）的生存时间（TTL）功能让数据过期](TTL.md)。
考虑以下使用 TTL 数据过期从 Cassandra 迁移到 Amazon Keyspaces 的示例。在此示例中，我们将两个数据库的 TTL 设置为 60 天，并显示 90 天内迁移过程的进展情况。在此期间，两个数据库都使用双重写入方法获得同样的新写入数据。我们将研究迁移的三个不同阶段，每个阶段为期 30 天。
下图显示了每个阶段的迁移过程的工作原理。
![\[从 Apache Cassandra 迁移到 Amazon Keyspaces 时，使用 TTL 使历史数据过期。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 在最初的 30 天之后，Cassandra 集群和 Amazon Keyspaces 一直都在获得新的写入内容。Cassandra 集群还包含留存期尚未达到 60 天的历史数据，这些历史数据占集群中数据的 50%。
将使用 TTL 自动删除 Cassandra 集群中超过 60 天的数据。此时，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_cn/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_cn/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# 在线迁移期间迁移应用程序
在线迁移的第四阶段，您将迁移应用程序并过渡到作为主数据存储的 Amazon Keyspaces。这表示您可以将应用程序切换为直接从 Amazon Keyspaces 读取数据和向其中写入数据。为确保最大限度地减少对用户的干扰，这应该是一个精心策划和协调的过程。
有两种不同的应用程序迁移推荐解决方案可供选择，蓝绿切换策略和金丝雀切换策略。以下各节对这两种策略进行了详述。
+ **蓝绿策略** - 使用这种方法，您只需一步即可切换应用程序，将 Amazon Keyspaces 视为主数据存储，将 Cassandra 视为辅助数据存储。为此，您可以使用AWS AppConfig功能标志来控制应用程序实例中主数据存储和辅助数据存储的选择。有关特征标志更多信息，请参阅 [Creating a feature flag configuration profile in 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_cn/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **金丝雀策略** - 通过这种方法，您可以逐步向部分用户或流量推出迁移。最初，您的应用程序流量的一小部分（例如，所有流量的 5%）被路由到使用 Amazon Keyspaces 作为主数据存储的版本，而其余流量则继续使用 Cassandra 作为主数据存储。
这让您可以使用真实流量对迁移版本进行全面测试，并监控其性能、稳定性以及调查潜在的问题。如果您未发现任何问题，则可以逐步增加路由到 Amazon Keyspaces 的流量百分比，直到它成为所有用户和流量的主数据存储。
这种分阶段部署可最大限度地降低广泛服务中断的风险，并且可以对迁移过程进行更严格的控制。如果在金丝雀部署期间出现任何严重问题，则可以将 Cassandra 作为受影响流量段的主数据存储，来快速回滚到先前的版本。只有在您确认 Amazon Keyspaces 按预期处理所有用户和流量之后，您再停止迁移。
下图展示了金丝雀策略的各个步骤。
![\[使用金丝雀策略将应用程序从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# 在线迁移后停用 Cassandra
应用程序迁移完成，即应用程序已完全在 Amazon Keyspaces 上运行且您已验证一段时间内的数据一致性后，便可以计划停用 Cassandra 集群了。在此阶段，您可以评估 Cassandra 集群中剩余的数据是否需要存档或是否可以删除。这取决于贵组织的数据处理和留存政策。
在计划从 Cassandra 到 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 连接器和 AWS Glue 将在 Amazon S3 中以 Parquet 格式存储的数据自动导入到 Amazon Keyspaces 表中。以下小节将简要概述此过程。您可以在 [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. 第三个作业是导入增量数据。
**如何在亚马逊虚拟私有云中从 EC2 在亚马逊上运行的 Cassandra 离线迁移到亚马逊密钥空间**
1. 首先AWS Glue，您可以使用从 Cassandra 以 Parquet 格式导出表格数据，然后将其保存到 Amazon S3 存储桶中。您需要使用指向运行 Cassandra 的 Amazon EC2 实例所在的 VPC 的AWS Glue连接器来运行AWS Glue作业。然后，使用 Amazon S3 私有端点，您可以将数据保存到 Amazon S3 存储桶。
下图说明了这些步骤。
![\[使用将 Apache Cassandra 数据从在 VPC 中 EC2 运行的亚马逊迁移到亚马逊 S3 存储桶。AWS Glue\]](http://docs.aws.amazon.com/zh_cn/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_cn/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_cn/keyspaces/latest/devguide/images/migration/migration-import.png)
有关离线迁移过程的更多信息，请参阅 [Amazon Key](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) spaces with 研讨会 AWS 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，那么 Apache Cassandra 内置的 CDC 特征允许通过将提交日志复制到单独的 CDC 目录来捕获更改，这是实现混合迁移的另一种选择。
为此，您可以将数据更改复制到 Amazon Keyspaces，让 CDC 成为数据迁移场景的替代方案。
如果您不需要连续写入后读取，则可以根据您的偏好和对工具的熟悉程度使用 CQLReplicator 或 CDC 管道将数据从 Apache Cassandra 迁移到 Amazon Keyspaces，并在每种解决方案中使用。AWS 服务使用这些方法近乎实时地迁移数据可以被视为一种混合迁移方法，其提供了在线迁移的替代方案。
此策略被视为一种混合方法，因为除了本主题中概述的选项外，您还必须执行在线迁移进度中的某些步骤，例如[在线迁移](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连接类型配置为网络。**
1. 要删除重复项并启用 CQLReplicator 任务的密钥缓存，请配置亚马逊简单存储服务 (Amazon S3) Service。
1. CQLReplicator 任务流经过验证的源数据库将直接更改为 Amazon Keyspaces。
![\[CQLReplicator 用于将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)
有关使用迁移过程的更多信息 CQLReplicator，请参阅AWS数据库博客 “使用将 Cassandra 工作负载[迁移到 Amazon Keyspaces” 上的以下文章以及 CQLReplicatorAWS使用将 Apache Cassandra 工作负载迁移到 Amazon Keyspac](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) [es 的规范性指南](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html)。AWS Glue
# 使用更改数据捕获（CDC）迁移数据
如果您已经熟悉如何使用 [Debezium](https://debezium.io/) 配置更改数据捕获 (CDC) 管道，则可以使用此选项将数据迁移到 Amazon Keyspaces，以此作为替代使用。 CQLReplicatorDebezium 是 CDC 的开源分布式平台，旨在监控数据库并可靠地捕获行级更改。
[Debezium Connector for Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) 将更改上传到 Amazon Managed Streaming for Apache Kafka（Amazon MSK），以便下游使用者可以使用和处理这些更改，而下游使用者反过来又可以将数据写入 Amazon Keyspaces。有关更多信息，请参阅 [Guidance for continuous data migration from Apache Cassandra to 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、内存、磁盘和 IO 的要求。
这种模式将来自 Cassandra 的更改视为“暗示”，即密钥相比之前的状态可能发生了变化。要确定是否有更改要传播到目标数据库，您必须首先使用 `LOCAL_QUORUM` 操作从源 Cassandra 集群读取最新记录，然后将其写入 Amazon Keyspaces。
如果是范围删除或范围更新，则可能需要对整个分区进行比较，以确定哪些写入或更新事件需要写入到目标数据库。
如果写入并非幂等性的，则在写入 Amazon Keyspaces 之前，您还需要将写入内容与目标数据库中已有的内容进行比较。
下图显示了使用 Debezium 和 Amazon MSK 的 CDC 管道的典型架构。
![\[使用更改数据捕获管道将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)