chenyang8094
chenyang8094
7.0 release notes: https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES
@jun1015 PLZ add tests for redis 7.0
把日志级别改下： log.level = debug 这是我用你的配置复现的日志(会看到ignore字样的日志)： ``` 2022/04/07 17:32:51 [INFO] DbSyncer[0] sync: +forwardCommands=1 +filterCommands=0 +writeBytes=4 2022/04/07 17:32:52 [INFO] DbSyncer[0] sync: +forwardCommands=0 +filterCommands=0 +writeBytes=0 2022/04/07 17:32:53 [INFO] DbSyncer[0] sync: +forwardCommands=0 +filterCommands=0 +writeBytes=0...
@opt-m 抱歉这个PR拖这么久，之前一直没时间细看。 我认为你描述的问题不止存在于db filter，你的复制场景问题(A-->B --> Shake)同样存在于正常的sync模式（甚至其他模式），这是一个级联复制下的bug。shake当前的确没有处理repl_stream_db信息（直接忽略），导致在级联复制时（作为slave的slave），会丢失自己master client当前db的信息（默认都会写到db 0，除非master上手动执行select不同的db）。 所以，我认为你的PR需要关注和处理这块，而不仅仅用于filter db。 我认为逻辑比较简单，sync RDB时提取repl_stream_db，并在之后的increasse sync阶段先设置selected db（并向target段发送一个select命令，如果该db没有被filter规则过滤），这样后续的同步和filter自然都能对的上了。
@Ashtonian Thanks, this is a larger format, I'm not sure what your formatting rules are, because we have a clang-format file in our repository to constrain our code style, maybe...
VER and ABS should not exists at the same time.
You mean the 120 ms latency caused by `exhgetallwithver` ?
Do you think all `exhgetallwithver` is accessing the same key? Maybe some `tairhash` is very big (bigkey) and `exhgetallwithver` is very slow. `exhgetallwithver` is an O(n) complexity command.
另外，你需要在.github里的workflows里加一下slab model的测试，否则目前的CI覆盖不了你的代码
 编译警告解决下