redis在线快速迁移

怼烎@ 2022-03-19 05:58 285阅读 0赞

公司的redis服务器key的数量以达到千万级别，需要对redis进行实例拆分并线上迁移redis数据。

之前公司用的迁移脚本是基于一个key一个key的，速度非常慢，脚本如下：

#!/bin/bash
    
    #redis 源ip
    src_ip=192.168.1.1
    #redis 源port
    src_port=6379
    
    #redis 目的ip
    dest_ip=192.168.1.1
    #redis 目的port
    dest_port=9379
    
    #src redis pass
    src_auth_pass=Idianyou_Redis6379
    
    #dest redis pass
    dest_auth_pass=Idianyou_Redis6379
    #要迁移的key前缀
    key_prefix=circle
    #迁到那个db
    dest_db=0
    
    #设置ttl过期时间
    TTL=0
    
    i=1
    
    Cmd=/zywa/redis/bin
    Other_Cmd=/zywa/redis_9379/bin
    $Cmd/redis-cli -h $src_ip -p $src_port -n 0 -a $src_auth_pass keys "${key_prefix}*" | while read key
    do
        $Cmd/redis-cli -h $src_ip -p $src_port -n 0 -a $src_auth_pass --raw dump $key | perl -pe 'chomp if eof' | $Other_Cmd/redis-cli -h $dest_ip -p $dest_port  -a $dest_auth_pass -n $dest_db -x restore $key 0
        echo "$i migrate key $key"
        ((i++))
    done

于是，通过查阅资料，最后决定使用唯品会开发的开源的redis迁移工具：[redis-migrate-tool][]。该项目已在github上开源。一下称为RMT。

该工具的优势：

快速。  
多线程。  
基于redis复制。  
实时迁移。  
迁移过程中，源集群不影响对外提供服务。  
异构迁移。  
支持Twemproxy集群，redis cluster集群，rdb文件 和 aof文件。  
过滤功能。  
当目标集群是Twemproxy，数据会跳过Twemproxy直接导入到后端的redis。  
迁移状态显示。  
完善的数据抽样校验。  
        RMT支持异构redis相互之间的迁移，数据来源可以是：单独的redis实例，twemproxy集群，redis cluster，rdb文件，aof文件。目标可以是：单独的redis实例，twemproxy集群，redis cluster，rdb文件。

RMT启动后模拟成redis slave，请求master的全量数据和增量数据。RMT收到数据之后解析成redis协议格式的oplog（写操作），然后发送给目标库。有两种请求方式，source\_safe: true，对于同一ip上的redis，逐个的请求全量数据（RDB）；source\_safe: false，并行请求同步全量数据。source\_safe: false时，需要注意多个源redis所在的同一主机是否有足够的内存和RDB并发落盘时的IOPS性能。

RMT可以帮你从备份的AOF和RDB文件恢复到目标库。

### RMT安装步骤： ###

依赖：  
yum -y install automake  
yum -y install libtool  
yum -y install autoconf  
yum -y install bzip2

安装redis-migrate-tool  
unzip redis-migrate-tool-master.zip  
cd redis-migrate-tool-master  
autoreconf -fvi  
./configure  
make

检查安装是否成功，如下图所示即为正确  
src/redis-migrate-tool -h

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nyb25fenp4_size_16_color_FFFFFF_t_70][]

参数说明：  
\-d 以守护进程执行  
\-I 输出有用的信息  
\-n 不接收目标redis的回应  
\-v 设置日志等级，默认5，最小0，最大11  
\-o 输出到日志  
\-c 配置文件  
\-p 进程文件，默认没有  
\-m 存储器缓冲大小，默认512字节，和机器磁盘一个扇区一样，我猜的  
\-C 默认redis\_migrate，就是迁移命令  
\-r 源类型，默认single，还可以是twemproxy或者redis\_cluster  
\-R 目标类型，默认single，还可以是twemproxy或者redis\_cluster  
\-T 线程数，使用多少线程来跑这个job，默认1  
\-b 默认可以使用128T的缓存来运行这个job  
\-f 源ip:port  
\-t 目标ip:port  
\-S 默认1，用于解析请求的步骤，数值越大，迁移越快，内存占用也就越大

# 使用： #

cd   /root/redis-migrate-tool-master  
vim rmt.conf

[source]
    type: single
    servers :
    -192.168.1.11:6379
    redis_auth:数据库密码
    [target]
    type: single
    servers:
    -192.168.1.11:7379
    redis_auth:数据库密码
    [common]
    listen: 0.0.0.0:8888
    threads:8
    filter:test*

以上文件说明：将192.168.1.11上端口为6379的redis中  以test开头的key迁移至端口为7379的redis中。

执行程序：

cd  /root/redis-migrate-tool-master

./src/redis-migrate-tool  -c rmt.conf  -o log -d && date

执行  taif  log

\[2019-02-20 10:13:56.801\] rmt\_redis.c:1623 MASTER <-> SLAVE sync: RDB data for node\[192.168.1.11:6379\] is received, used: 166 s  
\[2019-02-20 10:13:56.802\] rmt\_redis.c:1643 rdb file node192.168.1.11:6379-1550628670699842-6771.rdb write complete  
\[2019-02-20 10:14:00.188\] rmt\_redis.c:6601 Rdb file for node\[192.168.1.11:6379\] parsed finished, use: 2 s.  
\[2019-02-20 10:14:00.397\] rmt\_redis.c:6709 All nodes' rdb file parsed finished for this write thread(0).

出现以上信息时，说明迁移完成。

状态查看：通过redis-cli连接redis-migrate-tool监控的端口，运行info命令

redis-cli -h 192.168.1.11 -p 8888

# 验证： #

抽样验证

./src/redis-migrate-tool  -c rmt.conf  -o log  -C redis\_check 10000    \#默认抽样1000个key

Check job is running...

Checked keys: 1000  
Inconsistent value keys: 0  
Inconsistent expire keys : 0  
Other check error keys: 0  
Checked OK keys: 1000

All keys checked OK!  
Check job finished, used 9.755s

### **注意事项：** ###

1、重要的事说三遍，RMT迁移数据到twemproxy，需要保持rmt.conf 中 \[target\]  hash、distribution、servers 三个参数和目标集群的twemproxy配置严格一致。

2、迁移中和业务切换之前，请反复观察“-o rmt.log”日志信息，确认是否有异常。

3、业务切换之前，请充分检查，特别是数据的一致性。

4、RMT 建议部署在单独空闲机器上，同目的集群在同一个网段（跨机房迁移数据，可以提高迁移速度）。千万不要部署在源集群所在的机器，防止资源不足，比如内存，带宽，IOPS。

5、注意RDB传输是否超时；

6、redis client buf中的slave项，设置足够大的buffer size和超时时间。

# 升级改造1（改变target的db库号）： #

此工具会将source的所有库（db0-db115）的被过滤的key都迁移到taraget的0号库。显然是由问题的，可能会造成一些key的覆盖。通过查阅资料，现在只能修改target的库号。

修改rmt\_core.c文件，在426行添加如下代码：

log_stdout("---------> write select command to target");
    rmt_send_sync_cmd_read_line(tc->sd, "SELECT", "10", NULL);   // the target redis db

然后重新 make，会将所有选定的key迁移到target的10库中。

# 升级改造2（将指定前缀的key从source的对应库号迁移到target的对应库号）： #

将之前的redis-migrate-too彻底删除，然后从以下地址重新下载并重新按之前的步骤解压安装即可。

[https://github.com/silence0607/redis-migrate-tool][https_github.com_silence0607_redis-migrate-tool]

效率测试结果：

用最早之前的脚本，迁移是基于一个一个迁移的。几百万的key一次迁移要花费6个小时以上。使用RMT迁移工具，54万的key只需要三分钟即可迁移完毕。完成效率根本不在一个级别。

参考博客：

[http://www.mamicode.com/info-detail-2437802.html][http_www.mamicode.com_info-detail-2437802.html]

github开源地址：

[https://github.com/vipshop/redis-migrate-tool][redis-migrate-tool]

# 升级改造3（RMT工具对redis4.X以后的支持性不太好，可以使用阿里的开源工具redis-shake）： #

[https://blog.51cto.com/lee90/2400721?source=dra][https_blog.51cto.com_lee90_2400721_source_dra]

github地址：

[https://github.com/alibaba/RedisShake][https_github.com_alibaba_RedisShake]

[redis-migrate-tool]: https://github.com/vipshop/redis-migrate-tool
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Nyb25fenp4_size_16_color_FFFFFF_t_70]: /images/20220319/d5a06c860fd949999895419367b1fd94.png
[https_github.com_silence0607_redis-migrate-tool]: https://github.com/silence0607/redis-migrate-tool
[http_www.mamicode.com_info-detail-2437802.html]: http://www.mamicode.com/info-detail-2437802.html
[https_blog.51cto.com_lee90_2400721_source_dra]: https://blog.51cto.com/lee90/2400721?source=dra
[https_github.com_alibaba_RedisShake]: https://github.com/alibaba/RedisShake