本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 在线迁移到 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 服务。