If a key exists in the target node during a migration (BUSYKEY),
the value of the key on both nodes (source and target) will be compared.
If the key has the same value on both keys, the migration will be
automatically retried with the REPLACE argument in order to override
the target's key.
If the key has different values, the behaviour will depend on such
cases:
- In case of 'fix' command, the migration will stop and the user
will be warned to manually check the key(s).
- In other cases (ie. reshard), if the user launched the command
with the --cluster-replace option, the migration will be
retried with the REPLACE argument, elsewhere the migration will
stop and the user will be warned.
If a key exists in the target node during a migration (BUSYKEY),
the value of the key on both nodes (source and target) will be compared.
If the key has the same value on both keys, the migration will be
automatically retried with the REPLACE argument in order to override
the target's key.
If the key has different values, the behaviour will depend on such
cases:
- In case of 'fix' command, the migration will stop and the user
will be warned to manually check the key(s).
- In other cases (ie. reshard), if the user launched the command
with the --cluster-replace option, the migration will be
retried with the REPLACE argument, elsewhere the migration will
stop and the user will be warned.
When loading data, we call processEventsWhileBlocked
to process events and execute commands.
But if we are loading AOF it's dangerous, because
processCommand would call freeMemoryIfNeeded to evict,
and that will break data consistency, see issue #5686.
When loading data, we call processEventsWhileBlocked
to process events and execute commands.
But if we are loading AOF it's dangerous, because
processCommand would call freeMemoryIfNeeded to evict,
and that will break data consistency, see issue #5686.
Thanks to @soloestoy for discovering this issue in #5667.
This is an alternative fix in order to avoid both cycling the clients
and also disconnecting clients just having valid read-only transactions
pending.
Thanks to @soloestoy for discovering this issue in #5667.
This is an alternative fix in order to avoid both cycling the clients
and also disconnecting clients just having valid read-only transactions
pending.
