chenbt

感谢回复，按这个思路我再看看 --- 目前在本地调试，自定义日志比较杂，因此暂时不放上来了 根据效果描述，就是本地的 data/*.aof 里面只记了一点点数据，甚至末尾的数据有时候是不完整的。因此导致后面写入不完整 > 请给出一些日志信息，不太明白这里的意思。 有可能是这个原因，为了方便改动，我目前将offset相关部分摘除了。本想自定义其他的channel用来发送执行信号。 > 请尝试使用未改动的版本测一下，看看还会出问题吗？可能你的改动会导致有些偏移的统计出现问题。

已解决。 1.自己改造部分引入问题。 2.测试的codis设置了client-output-buffer-limit，导致连接中断。

> 目前没有这样的工具。我觉着可以这样实现一个这样的功能。 > > 1. 创建一个sharding模式的pika-A，其中slot的数目与codis集群的数目相同。 > 2. pika-A 中的slot与codis中的所有slot建立主从关系。此时pika-A 获取集群中的所有数据，但是数据是被分片的。 > 3. pika-A 扫描sst文件的全量数据和binlog中的增量数据发送到pika-B 经典模式的pika中。 > 4. 监控codis集群中的lag信息，当lag较少时停止codis集群的写。 > 5. 等待pika-A中的增量同步完成。 > 基本逻辑参考了pika-port的功能。这里繁琐的操作的原因是rocksdb 做不到sst文件的合并，无法直接将slot的数据直接合并。 请问第三点的功能实现社区有没有开发计划？当前pika的相关工具实现都是以cpp为主， 如果当前没有相关规划，后续基于go或其他语言贡献社区这边有没有相关的规范要求呢？

如果社区能支持这个功能就太好了！ 预计社区什么时候会讨论并更新开发计划呢？

我司正在深入应用pika，对这个迁移功能关注度也很高。如果有帮得上忙的地方请联系我，我们愿意贡献自己的一份力。

> 我司正在深入应用pika，对这个迁移功能关注度也很高。如果有帮得上忙的地方请联系我，我们愿意贡献自己的一份力。 我这边基于阿里的redis-shake改造了一个go版本的迁移工具，目前正在公司内部测试使用。 ## 介绍 codis2pika工具是基于阿里开源的redisshake工具改造的数据迁移工具。 主要目的是实现，从sharding模式的codis向经典模式的pika进行数据同步的功能。 ## 目前实现功能： codis2pika理论上支持从redis/codis 向pika迁移。 codis2pika支持增量和全量同步。 codis2pika支持实时同步（延迟约2-3s）迁移。 codis2pika支持开关添加自定义key前缀和slot重分配功能植入。 @kernelai 你好，请问下社区对于这类通用工具有哪些要求？如果可以满足的话，我们也想把这个工具贡献出来。

大佬，已经在了

**基本的验证** >$redis-cli -p 9221 info stats |grep key keyspace_hits:19 keyspace_misses:0 is_scaning_keyspace:No 集成测试  

> 用当前 unstable 分支代码编译后再测试一遍 代码版本  unstable分支的测试结果  

情况总结： 1. block_size较大时（例如64G），会占用比较大的内存 2. info 使用内存统计可能忽略了block_size 3. 关闭block_size后测试，持续导入数据内存占用会缓慢增加，但是影响不大（约导入1T / 增加1G）但需要明确占用的原因 下一步是： 1. 完善 info 使用内存统计 2. 确定内存占用增长原因 3. 较长时间的验证