chejinge
chejinge
baitao
> > 前的设计是没问题的，因为同 db（那肯定也包含同 key）的 binlog 会被分到相同的 worker 中，因为这个 worker 是 binlog worker，它只有一个 bg_thread 对任务进行取出和应用，所以不存在一致性的问题。调用顺序 > > 这里是写binlog的一致性的原因，key一致性的保证在PikaReplClient::ScheduleWriteDBTask的实现里面，取出redis_command的第一个操作对象作hash散列到write_db_workers_中，这样保证了写单key一定被同一个线程write_db_workers_执行，保证了一致性。 但是有个疑问，这里感觉只保证了Set, Del这种操作的一致性，但如果是SUnionStore这种呢？考虑以下场景： > > 1. SAdd set1 "1" > 2. SAdd set2...
故障自愈的case: 1.主节点故障后，从节点自动升主，新的从节点做全量复制后或者下线后重新接一个从实例 2.从节点故障后，主从重新建立连接，数据能够正常的写入，如果从节点长时间不恢复的话，将从节点下线 3.主节点故障后，从节点升主，测试主从数据的一致性 4.从节点长时间没写成功失败了或者下线了，移除出该集群 5.从节点长时间没响应，接入新的从节点，做完全量复制后，主从集群恢复 6.主节点因为网络等问题没有返回且从节点没有写入成功（数据不完整），主从均不可对外提供服务
https://github.com/OpenAtomFoundation/pikiwidb/issues/3001 参考这个issue可以自行打包ARM版本
Rtc不可能支持redis的所有命令吧，这样会导致上层网络框架堵塞的
创建了新的分支，pr就不会有这么多文件修改和冲突，功能完成之后编译出二进制再放入migrate_tool，已经新建分支
建立新的分支 将这个工具的代码放在这个分支 编译成功后把二进制塞进发布包中，不要把所有的代码放到主干分支
3.5.5 4.0
kill -9 pika 进程的时候 可能会损失一部分的数据，这里建议使用shutdown或者 kill
主从切换的时候可能会数据丢失或者主从不一致