You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#1638 记俊华之前修复的主从同步不一致的问题,之前解决的是对于操作多个key的命令,如果只根据第一个Key做 Hash 到不同的 Worker 线程的话可能会导致主从数据不一致的情况,后面经过把多 Key 的 Binlog 进行了拆分解决了这个问题,今天在测试主从同步的过程中发现,FlushDB 这种管理命令如果和 Set key value 在一起执行的话,顺序是不能保证的,举个例子:比如主节点顺序执行了 Set a b,Set a c,Flushdb,然后从节点那边 Set a b,Set a c 肯定是 Hash 到同一个线程里面执行的,但是 Flushdb 这个命令大概率不会 Hash 到 Set a b这个线程里面,如果此时 FlushDB 的这个线程优先执行完,那么从节点写 DB 的顺序就会变为 FlushDB -> Set a b -> Set a c,与主节点那边不一致。可能的一个改进办法是,在从节点端把写 DB 这个行为改为同步的,和写 Binlog 一致即可保证命令的顺序性。
The text was updated successfully, but these errors were encountered:
Bot detected the issue body's language is not English, translate it automatically.
Title: [Master-slave synchronization to be repaired] A management command such as flushdb is operated in pika. There are write commands. Due to improper binlog processing, master-slave inconsistency may occur.
Description
#1638 记俊华之前修复的主从同步不一致的问题,之前解决的是对于操作多个
key
的命令,如果只根据第一个Key
做Hash
到不同的Worker
线程的话可能会导致主从数据不一致的情况,后面经过把多Key
的Binlog
进行了拆分解决了这个问题,今天在测试主从同步的过程中发现,FlushDB
这种管理命令如果和Set key value
在一起执行的话,顺序是不能保证的,举个例子:比如主节点顺序执行了Set a b
,Set a c
,Flushdb
,然后从节点那边Set a b
,Set a c
肯定是Hash
到同一个线程里面执行的,但是Flushdb
这个命令大概率不会Hash
到Set a b
这个线程里面,如果此时FlushDB
的这个线程优先执行完,那么从节点写DB
的顺序就会变为FlushDB
->Set a b
->Set a c
,与主节点那边不一致。可能的一个改进办法是,在从节点端把写DB
这个行为改为同步的,和写Binlog
一致即可保证命令的顺序性。The text was updated successfully, but these errors were encountered: