Redis上云迁移实践

Posted 2022-08-10 实验室清洁工

简介

随着云产品的完善，大多数公司已经开始使用云产品，云产品的确能够解决很多基础架构上的便利，提高业务架构的稳定性，如何将Redis数据在线迁移到云上，并且保证业务的无损，从迁移方案和工具选择必须要考虑如下几点：

兼容性：Redis社区版向下是兼容的，在上云的过程中，尽量保持大版本一致，以免版本不一致导致客户端不兼容的问题

迁移工具：充分考虑工具的功能性的同时，也要重点考虑便利和可运维性，工具需要有完整的日志和监控系统

数据完成性：数据大于一切，不能保证数据完整的情况下，切勿做相关的动作，Redis作为缓存数据变化较快，需实时进行数据较对相关工作

资源有效评估： 云上资源资源规格已标准化，在评估云上资源时，要充分参考自建机房实例，尽量高于自建资源

迁移流程

资源评估

• 充分考虑自建机房Redis实例的架构，从监控系统中提取实例QPS，内存大小，，连接数，带宽等三个指标，云上实例规格性能需与自建Redis对齐，云上实例对带宽有限制，这点需要注意
• 尽量采用自建实例的从库作为数据同步的数据源，以减少对业务访问主库的压力

兼容性评估

版本确认

云上实例尽量与自建实例保持大版本一致，目前比较主流的大版本是4.0

命令兼容性确认

云厂商为了支持一些特性，将一些命令进行了阉割，命令兼容性支持请查看云厂商文档

是否使用密码

某些老业务可能不支持密码，在上云的过程中，尽量保持免密，就算部分应用带有密码，也可以兼容

业务评估

是否使用lua脚本

检查原因：社区版4.0.2版本及以下版本都不会同步二级从库的lua脚本到三级从库，可对Redis进行monitor抓包查看
解决方法：同步主库

是否使用lua客户端

检查原因：部分应用应用lua客户端可能使用内置的域名解析，导致无法解析Redis域名

解决方法：修改内置域名解析或者使用系统域名解析

读写请求是否可拆

检查原因：主库读写无法拆开，无法保证应用一次读写请求请求迁移彻底，从而导致数据不一致性问题

解决方法：对主库使用代理，一般使用Haproxy

确认业务访问方

检查原因：防止业务漏迁，导致数据不一致

解决方法：定期开启redis monitor或tcpdump对主从实例进行抓包，了解业务访问方

确认业务是否有重连机制

检查原因：有研发确认

解决方法：应用端尽量保持重连机制，无重连机制，更改配置后，需重启业务应用

确定方案

制定了初步的迁移方案后，需跟业务研发负责人一起对接方案，避免有业务上有没有考虑到的问题，做好方案回滚预案

方案实施

• 搭建的数据同步工具，需要有完成的监控系统，源端实例和目标实例需要有完整的日志，并对实例进行定期实时抓包
• 迁移过程中，研发负责人和运维人员全程参入，避免不可预见问题
• 迁移时间，应当选择业务低峰期

迁移收尾

善后处理

迁移完成后，确认业务无异常后，尽量将源端实例进行关闭，及时发现问题，并实时对代理抓包，避免漏迁移导致的数据不一致

总结经验

总结迁移过程中出现的问题，并形成文档，方便后续迁移和总结

迁移方案

原理

本方案采用开源Redis-shake作为数据同步工具，haroxy作为代理。架构如下图：

阶段一（图一）：
主要为搭建redis-shake和代理节点，业务保持访问不变，代理配置为后端连接为自建redis实例

阶段二（图二）：
1、对源端和目标端进行数据对比
2、数据比对无误后，将应用配置有自建Redis地址改到haroxy代理地址
3、对自建Redis实例进行抓包，确认是否已无访问

阶段三（图三）：
1、自建Redis无访问后，将haproxy的后端连接地址改为云厂商地址
2、重启haproxy，确定业务情况
2、云厂商Redis是否所有访问来自haproxy地址

阶段四（图四）：
1、确定云redis是否访问来自haproxy地址
2、业务将应用配置有haproxy地址修改至云Redis地址
3、对haproxy进行实时抓包，避免漏迁

迁移方法

数据同步

可采用开源Redis数据同步工具，redis-shake的基本原理就是模拟一个从节点加入源redis集群，首先进行全量拉取并回放，然后进行增量的拉取（通过psync命令），具体配置请参考​​文档​​

数据比对

可采用开源数据对比工具，通过全量对比源端和目的端的redis中的数据的方式来进行数据校验，其比较方式通过多轮次比较：每次都会抓取源和目的端的数据进行差异化比较，记录不一致的数据进入下轮对比（记录在sqlite3 db中）。然后通过多伦比较不断收敛，减少因数据增量同步导致的源库和目的库的数据不一致。最后sqlite中存在的数据就是最终的差异结果。具体配置请参考​​文档​​

业务迁移

对于业务而已，只提供了redis地址和haproxy的地址，业务配置需要修改配置到haproxy地址，haproxy的配置如下：

global
    log 127.0.0.1 local1 notice
    daemon
    stats socket /tmp/haproxy.sock
    nbproc  5
    maxconn 40000

defaults
    log global
    mode tcp
    option tcplog
    option dontlognull
    retries 3
    option abortonclose
    maxconn 20000
    timeout connect 10s
    timeout client 3m
    timeout server 3m
    timeout check 10s
    balance static-rr

listen stats
    bind 127.0.0.1:11080
    mode http
    option httplog
    maxconn 20
    stats enable
    stats refresh 3s
    stats uri /stats
    stats realm DBA Haproxy
    stats auth *********
    stats auth *********
    stats hide-version
    stats admin if TRUE

listen redisRead
    bind 127.0.0.1:18982
    mode tcp
    option tcplog
    balance static-rr
#     server streamconf_6010 127.0.0.1:6010 check inter 2000 rise 3 fall 3 weight 10
     server streamconf_6010 10.255.10.1:6379 check inter 2000 rise 3 fall 3 weight 10

总结

• 迁移前一定要做好方案调研、资源评估，兼容性评估
• 监控是运维人员的眼睛，方案选型后，监控是必不可少的
• 业务迁移，尽量选择业务低峰期，并做好相关测试

参考

​​redis数据同步​​

​​redis 数据比对​​