• Binbin's avatar
    Use shard-id of the master if the replica does not support shard-id (#12805) · 5a2f4a1e
    Binbin authored
    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.
    
    A cluster-wide consensus for the node's shard_id is not necessary. The key
    is maintaining consistency of the shard_id on each individual 7.2 node.
    As the cluster progressively upgrades to version 7.2, we can expect the
    shard_ids across all nodes to naturally converge and align.
    
    In this PR, when processing the gossip, if sender is a replica and does not
    support shard-id, set the shard_id to the shard_id of its master.
    
    (cherry picked from commit 4cae66f5)
    5a2f4a1e
cluster.h 22.3 KB