From 19bd195bafb367d701a47683e581a6ea695dc77d Mon Sep 17 00:00:00 2001 From: Binbin Date: Thu, 23 Nov 2023 22:03:39 +0800 Subject: [PATCH] Use shard-id of the master if the replica does not support shard-id If there are nodes in the cluster that do not support shard-id, they will gossip shard-id. From the perspective of nodes that support shard-id, their shard-id is meaningless (since shard-id is randomly generated when we create a node.) Nodes that support shard-id will save the shard-id information in nodes.conf. If the node is restarted according to nodes.conf, the server will report a `corrupted cluster config file` error. Because auxShardIdSetter will reject configurations with inconsistent master-replica shard-ids. In this PR, when process the gossip, if sender is a replica and does not support shard-id, set the shard_id to the shard_id of its master. This fix #12761. --- src/cluster_legacy.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/cluster_legacy.c b/src/cluster_legacy.c index 0f20cbdbb12..2710dff0ecb 100644 --- a/src/cluster_legacy.c +++ b/src/cluster_legacy.c @@ -2596,11 +2596,16 @@ void clusterProcessPingExtensions(clusterMsg *hdr, clusterLink *link) { /* We know this will be valid since we validated it ahead of time */ ext = getNextPingExt(ext); } + /* If the node did not send us a hostname extension, assume * they don't have an announced hostname. Otherwise, we'll * set it now. */ updateAnnouncedHostname(sender, ext_hostname); updateAnnouncedHumanNodename(sender, ext_humannodename); + /* If the node did not send us a shard-id extension, it means the sender does not + * support it, node->shard_id is randomly generated. If sender is a replica, set + * the shard_id to the shard_id of its master. Otherwise, we'll set it now. */ + if (ext_shardid == NULL && sender->slaveof) ext_shardid = sender->slaveof->shard_id; updateShardId(sender, ext_shardid); }