chejinge
chejinge
您好 这个问题可以先用diskrecovery恢复数据写，等到恢复后看看能不能把与数据无关的日志或者什么删除一下，或者尝试做配置低峰期及时做compact及时清除碎片化数据的操作，这个删除数据这个事情，我们需要讨论在开发下看怎么做
这个问题的原因是从节点apply binlog的时候不能保证顺序，所以有可能flushdb先于set执行 导致从有脏数据，和缓存没有关系，解决办法，在flushdb前后都检查一下
思路没问题 需要注意的是 pika和codis都需要修改config配置，另外迁移数据需要打开slotmigrate及slotsreload
没有看明白具体是什么场景下需要加锁，可以大致解释一下么
https://github.com/OpenAtomFoundation/pika/issues/2297
https://github.com/OpenAtomFoundation/pika/wiki/3.2.x-Performance 性能压测最好可以被社区用户方便的复现。目前缺少 pika.conf 的信息
352环境上依然存在 chejinge跟进
主要是下面这几个点： 1 网络层 & proxy：长链接超时探测、常驻内存 buffer配置、tcp等待队列、剔除不可用节点的探测时间。 2 compaction：改了一些rocksdb的参数：max_bytes_for_level_base target_file_size_multiplier level0_file_num_compaction_trigger max_background_compactions， 并且调整了全量 compaction的周期 3 压缩： 调了一些snappy 的压缩等级 4 write buffer相关的参数： 这个就是max_write_buffer_size 之类的了 另外有一个比较值得关注的点 是减少小文件的频繁合并可以让磁盘利用更充分、iops 也更好看一些
和谦祥讨论过 这里会前后不兼容 ，不修改比较好，但是可以在会冲突的地方加日志，出现这个问题后修改端口，这个问题只会在启动的时候出现，只要启动了一般都不会在触发