Skip to content
This repository has been archived by the owner on Jun 23, 2022. It is now read-only.

feat(update_replication_factor#7): replace cluster-level max_replicas_in_group with max_replica_count of each replica #1109

Merged

Conversation

empiredan
Copy link
Contributor

@empiredan empiredan commented May 21, 2022

This is a subtask of apache/incubator-pegasus#865.

There is an option max_replicas_in_group which restricts the max replica count of the whole cluster. It's a cluster-level option. However, now that it's allowed to update the replication factor of each table, this cluster-level option should be replaced.

Conceptually max_replicas_in_group is the total number of alive and dropped replicas. Its default value is 4. For a table that has replication factor 3, that max_replicas_in_group is set to 4 means 3 alive replicas plus a dropped replica.

max_replicas_in_group can also be loaded from configuration file, which means its default value will be overridden. The value of max_replicas_in_group will be assigned to another static variable MAX_REPLICA_COUNT_IN_GRROUP, whose default value is also 4.

For unit tests, MAX_REPLICA_COUNT_IN_GRROUP is set to the default value 4; for production environments, MAX_REPLICA_COUNT_IN_GRROUP is set to 3 since max_replicas_in_group is configured as 3 in .ini file.

Since the cluster-level option max_replicas_in_group contains the alive and dropped replicas, we can use the replication factor of each table as the number of alive replicas, and introduce another option
max_reserved_dropped_replicas representing the max reserved number allowed for dropped replicas.

If max_reserved_dropped_replicas is set to 1, there is at most one dropped replicas reserved; If it's set to 0, however, none of dropped replicas can be reserved.

Thus the default value of max_reserved_dropped_replicas is set to 1 to so that the unit tests can be passed.
For production environments, it should be set to 0 to be consistent with max_replicas_in_group, which also means, once the number of alive replicas reaches max_replica_count, at most one dropped replica can be reserved and others will be eliminated.

[meta_server]
+ max_reserved_dropped_replicas = 0

…_in_group with max_replica_count of each replica
…_in_group with max_replica_count of each replica
…_in_group with max_replica_count of each replica
Copy link
Member

@acelyc111 acelyc111 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

…_in_group with max_replica_count of each replica
@hycdong
Copy link
Contributor

hycdong commented May 23, 2022

New configuration added:

[meta_server]
+ max_reserved_dropped_replicas = 1

@hycdong hycdong added the type/config-change PR that made modification on configs, which should be noted in release note. label May 23, 2022
@hycdong hycdong merged commit c484c3e into XiaoMi:max_replica_count_dev May 23, 2022
acelyc111 pushed a commit that referenced this pull request Jun 1, 2022
…_in_group with max_replica_count of each replica (#1109)
acelyc111 pushed a commit that referenced this pull request Jun 6, 2022
…_in_group with max_replica_count of each replica (#1109)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/config-change PR that made modification on configs, which should be noted in release note.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants