发布于: Oct 30, 2022
云数据迁移是如何进行的呢？首先我们来了解一下为什么要将数据进行迁移，因为相对于 ElastiCache for Redis 管理服务，部分客户喜欢自建 Redis 平台，但是相对平台服务而言，有如下比较明显的缺点和难题需要解决：
- 难以管理：管理服务器配置、软件补丁、安装、配置与备份
- 难以实现高可用：需要快速执行错误检测与修复
- 难以扩展：在线扩展可能引发错误，且需要监控副本性能
- 成本高昂：人员、流程、硬件与软件需要占用大量资金
除了前面章节对比测试的性能和延时，以及成本优势外，使用 ElastiCache for Redis 的管理服务还有如下优势可以让客户直接开箱即用:
- 极致性能：提供小于 1ms 的响应时间；当前最大支持 500 个节点，340TB 存储的最大 Redis 集群；最大支持 3250 万连接数，满足极致场景的巅峰性能；
- 全托管：Amazon Web Services 管理所有的硬件以及软件的配置和监控；
- 易伸缩：通过副本提供读操作的弹性伸缩，通过分片提供写操作非中断的弹性伸缩；支持横向和纵向的弹性伸缩；
- 可靠性保障：多可用区（免跨AZ流量费）支持，深度和详细的监控和告警，自动故障转移（10-20s 内实现 Fail Over）；
- 安全和合规：通过 Amazon VPC 实现网络隔离和管理，符合 HIPAA，PCI 和 FedRAMP 等安全和合规要求，存储和传输中支持进行加密和身份认证；
- 兼容性：兼容多个 Redis 版本和客户端，支持导入导出，支持快照和恢复等；
比较传统的方式是把运行在 EC2（或者容器）里面的 Redis 数据做个备份导出（通过在 reids-cli 中使用阻塞式的 save 命令或者后台方式的 bgsave 命令），然后把导出文件存到 S3（当前只支持从 S3 导入），然后在 ElastiCache 控制台创建集群时选择导入位于 S3 的备份文件，在这种操作方式下，如果源还在继续使用可能会导致两边的数据不完全同步，如果源不操作等新集群可用户再切换的话，则会有一定的服务中断时间。
具体操作见从备份还原的 指引文档 ，本文不做额外的演示和说明。
Redis-migration-tool 是 github 上开源的一个 Redis 迁移工具，使用它可以在不同的 Redis 环境（如单机，集群等）实现同步和复制。
在 Amazon Linux 2 操作系统上可以使用如下方式使用 redis-migration-tool：
mkdir /opt/redis-migration-tool && cd /opt/redis-migration-tool git clone https://github.com/vipshop/redis-migrate-tool.git
因为这个工具有段时间没更新了，我们使用的是比较新的 Redis 6.0.5 版本，所以需要修改一下源码中关于 RDB 文件版本的定义。
修改“/opt/redis-migration-tool/redis-migrate-tool/src/rmt_redis.c”，把原来的 “#define REDIS_RDB_VERSION 7” 修改成 “#define REDIS_RDB_VERSION 10”，然后再编译：
cd /opt/redis-migration-tool/redis-migrate-tool autoreconf -fvi ./configure make #编译好的文件位于src/redis-migrate-tool
接着编辑对应的配置文件“/opt/redis-migration-tool/redis-migrate-tool/rmt.conf”，内容如下（记得修改对应的集群 endpoint）：
[source] type: single servers : - 127.0.0.1:6379 [target] type: redis cluster servers: - r6g-2xlarge-elasticache-for-redis-cluster-endpoint:6379 [common] listen: 0.0.0.0:8888
同时，我们此处使用之前的测试机（那个 m5.8xlarge 的 EC2）的机器当做源，然后通过脚本往里面压数据，命令如下（模拟一个并发，一个客户端，持续 180 秒的写入随机数据）：
同时，我们此处使用之前的测试机（那个 m5.8xlarge 的 EC2）的机器当做源，然后通过脚本往里面压数据，命令如下（模拟一个并发，一个客户端，持续 180 秒的写入随机数据）：
memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 1 -c 1 -p 6379 -s 127.0.0.1
原来在准备 redis-benchmark 工具的时候已经安装了 redis 服务，此处我们把服务启动，并确认数据内容，同时手工写入一个 key 做测试，如下：
systemctl enable redis systemctl start redis redis-cli # keys * # set owner "WeiqiongChen"
源如下所示（没有其他数据，只有我们手工写入的 key）：
图例：准备位于 EC2 的源 Redis（单机版）
目标如下所示（没有其他数据，也没有我们手工写入的 key，因为还没开始同步）：
图例：清理目标 ElastiCache for Redis 集群环境
在源通过如下命令开始生成数据
memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 1 -c 1 -p 6379 -s 127.0.0.1
如下：
图例：启动源
然后再启动同步（特意晚启动同步模拟客户真实的迁移场景）
cd /opt/redis-migration-tool/redis-migrate-tool ./src/redis-migrate-tool -c ./rmt.conf -o log &
如下所示：
图例：启动源到目的的同步
我们统计源注入的数据量，如下（此处为 473563 个 key）：
图例：查看源的数据量
对比查看目标库同步的数据量（因为目标卡集群分成三个片了，所以要统计三个分片的总数），如下（此处合并总数依然是 473563 个 key）：
图例：查看目标的数据量
注意：读者们可以在源多做几轮测试，验证同步结果是否符合预期（如果没有数据同步或者有异常，可以查看 redis-migration-tool 目录的 log 文件查看异常信息）。