chenbt
chenbt
近期工作需要实现从codis集群将数据平滑迁移到zk版的pika中。 请问当前是否有工具或正在项目可以支持以下的迁移需求 **完整需求** 1.从源实例（codis - 分片模式）同步数据到目标实例（pika - 经典模式） 2.支持全量同步阶段和增量同步阶段 3.数据迁移同步时，支持codis的指定slot数据分布到pika集群的指定位置 4.稳定性，保证数据完整性 5.不影响当前的业务可用性，尽可能不影响业务性能 社区中当前的aof_to_pika工具，存在以下问题： > 1. 无法实现增量同步 > 2. 多次测试均发现，数据同步会异常中断，数据迁移不完整。目前不确定异常原因。 如下图，100w数据未完整同步，而实际生产环境的数据远大于此，因此aof_to_pika工具无法使用。
**是否支持AOF文件的增量同步** 没有看到详细的AOF增量同步的内容和原理，加之阿里云社区相关文档有些过时。 主要是想请教一下AOF增量的原理和机制。 **实际需求和遇到的问题** 我希望最终能实现业务无感知的迁移，也就是不中断业务的情况下操作。因此，启动redis-shark迁移时，仍然需要持续监听源端的aof文件，并将增量的部分迁移到目的端。 实际测试时，我发现该工具只能将rdb中的数据迁移过来，aof中的数据只有一小部分保存下来。 且aof相关的写入日志是突然中断，未给出其他日志信息。 （注： 为了实现个性化的迁移需求，我基于V3版本的redis-shark，尝试对rdb.go等模块进行了一些改动，改动不涉及aof的读写。目前使用redis-full-check验证，启动迁移程序后，源端不新增的数据的情况下迁移是完整的。） --- **源端** 版本：自建codis --- **目的端** 版本：自建pika
llama: model does not exist gpt: model does not exist gpt2: model does not exist stableLM: model does not exist The UI interface cannot be used, and the page cannot...
### Is this a regression? Yes ### Description **问题现象**：pika出现较多发生时刻接近的慢日志，例如Delete、Auth、Set等命令的执行记录。当新建连接较多时，会影响set、get、delete等请求执行情况，容易出现更多慢日志。 **问题分析**： 1.设备性能： > 96核 加速卡 ，单实例QPS 5k setex ，cpu使用率 5%，内存使用约5%，理论上无压力 2.网络： > 万兆网卡，流量很小，tcp连接数设置为最大，pika 配置client数2w、线程数8 3.磁盘性能： > 磁盘读写await都低于0.01ms **日志与监控分析**： 1.有的慢日志是因为前后在进行compaction 2.有的慢日志发生时，监控大盘无compact记录。但前1分钟的日志发现较多的连接close，后续又新增类似的conn。（经过确认为连接池释放空闲连接） **测试环境复现**...
about: https://github.com/OpenAtomFoundation/pika/issues/2542 改动：在读请求放入队列前，先进行判断是否在cache中读取 ## Summary by CodeRabbit - **New Features** - Introduced batch reading of commands from cache for improved performance. - Enhanced command flags to optimize command processing. -...
### Is this a regression? Yes ### Description 单实例，持续执行hset命令压测，2-4w的qps，一小时后内存占用100% 通过valgrind --leak-check=full --tool=memcheck --log-file=valgrind_output.txt ./pika程序 -c pika_9221.conf查看   ### Please provide a link to a minimal reproduction of the bug...
**修改内容** 1.新增keyspace_hits、keyspace_misses指标 2.修改了set相关命令的返回结果，使得keyspace_hits、keyspace_misses可以正确统计 3.新增了go测试 **需要审查的点** - [ ] 当前修改新增了kNoExists是否合理？ - [ ] 当前返回是否符合预期，尤其是异常列表中的情况能否接受？ **说明** 这次改动主要为了在pika支持keyspace hit相关参数。 关联的issue： https://github.com/OpenAtomFoundation/pika/issues/2423 参考redis的实现: redis在执行操作前会统一在内存查找key是否存在并统计 但在pika这一层，需要在各个命令执行阶段实现统计。 - 本次的改动默认s_ = db_->storage()返回的状态对象能够符合预期的返回s_.IsNotFound()==true。 即，当key不存在时s_.IsNotFound()==true。 - 管理命令、有部分的write命令无关key是否存在，因此这些命令将不会纳入keyspace_hit相关的统计。 - 对于执行报错的命令，不会纳入keyspace_hit相关的统计。...
### Is this a regression? Yes ### Description 后续补充截图。 测试设备 104核 256G 内存 单机部署6个pika实例，每个配置3db，进程数4，线程池大小8 纯读：hget p99 < 1ms ,hgetall p99 ~ 10ms 读写时，hset + hmset + hget + hgetall p99甚至大于1s...
### Is this a regression? Yes ### Description 215g数据启动时间大约需要15分钟 相同配置使用老版本就没有这个问题。 暂时没定位到具体原因 ### Please provide a link to a minimal reproduction of the bug _No response_ ### Screenshots or videos _No...
### Is this a regression? Yes ### Description ## 描述 线上主从的pika替换二进制原地升级后主从同步失败。 ## 背景 线上有一对352版本的主从当前希望升级为355版本。其中主节点负责全部读写，从作为备份。 先把从节点停止服务，替换二进制后启动后提示同步状态失败。 ### 从节点日志 W20250512 10:37:38.958766 10179 pika_repl_client_thread.cc:29] Master conn disconnect : 主节点:11221 try reconnect W20250512 10:37:38.958788...