本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 在线迁移到 Amazon Keyspaces：策略和最佳实践
<a name="migrating-online"></a>

如果您在从 Apache Cassandra 迁移到 Amazon Keyspaces 的过程中需要保持应用程序的可用性，则可以通过实施本主题中讨论的关键组件来准备自定义的在线迁移策略。通过遵循在线迁移的这些最佳实践，您可以确保在整个迁移过程中保持应用程序写后读一致性，从而最大限度地减少对用户的影响。

在设计从 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.amazonaws.cn/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)中以供分析。
   + 消息收发层双重写入：或者，您可以将现有消息收发平台配置为利用其他使用者向 Cassandra 和 Amazon Keyspaces 发送写入内容。这会在两个数据库之间创建最终一致的视图。

1. **迁移历史数据**
   + 复制历史数据：您可以使用 Amazon Glue 或自定义提取、转换、加载（ETL）脚本将历史数据从 Cassandra 迁移到 Amazon Keyspaces。使用轻量级事务或时间戳等技术处理双重写入和批量加载之间的冲突解决方案。
   + 使用 Time-To-Live (TTL)：为了缩短数据保留期，您可以在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免上传不必要的历史数据。随着旧数据在 Cassandra 中过期，而新数据通过双重写入技术进行写入，Amazon Keyspaces 最终会赶上来，保持一致。

1. **验证数据**
   + 双重读取：实现对 Cassandra（主）数据库和 Amazon Keyspaces（辅助）数据库的双重读取，异步比较结果。差异会被记录下来或发送到 DLQ。
   + 样本读取：使用 Λ 函数定期对两个系统的数据进行采样和比较，将所有差异记录到 DLQ 中。

1. **迁移应用程序**
   + Blue-green 策略：只需一个步骤即可切换您的应用程序，将 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)