Binbin ecbfb6a7ec
Fix reconfiguring sub-replica causing data loss when myself change shard_id (#944)
When reconfiguring sub-replica, there may a case that the sub-replica will
use the old offset and win the election and cause the data loss if the old
primary went down.

In this case, sender is myself's primary, when executing updateShardId,
not only the sender's shard_id is updated, but also the shard_id of
myself is updated, casuing the subsequent areInSameShard check, that is,
the full_sync_required check to fail.

As part of the recent fix of #885, the sub-replica needs to decide whether
a full sync is required or not when switching shards. This shard membership
check is supposed to be done against sub-replica's current shard_id, which
however was lost in this code path. This then leads to sub-replica joining
the other shard with a completely different and incorrect replication history.

This is the only place where replicaof state can be updated on this path
so the most natural fix would be to pull the chain replication reduction
logic into this code block and before the updateShardId call.

This one follow #885 and closes #942.

Signed-off-by: Binbin <binloveplay1314@qq.com>
Co-authored-by: Ping Xie <pingxie@outlook.com>
2024-08-29 22:39:53 +08:00
..
2024-06-03 12:22:06 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-06-07 01:40:55 +02:00
2024-05-22 23:24:12 -07:00
2024-07-18 19:21:45 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-05-22 23:24:12 -07:00
2024-06-07 01:40:55 +02:00
2024-05-22 23:24:12 -07:00
2021-07-10 10:04:54 -05:00
2024-08-27 16:11:33 +02:00
2024-05-22 23:24:12 -07:00
2024-08-27 16:11:33 +02:00