-
Notifications
You must be signed in to change notification settings - Fork 250
Description
What is the user interaction of your feature
A concise description of user interactions or user stories of your feature request
In the actual production environment, for example, when replacing an instance, to ensure service stability, we usually want to scale out a new instance first and then scale in an old one.
At present, for components, we can manually divide them into two steps, the first step is to perform the scale out opsrequest, and the second step is to perform the scale in opsrequest, to achieve the above goal.
However, for sharding API, it is temporarily impossible if you want to implement the scale-out first and then scale in an instance under a specified shard because we can't increase the number of cases by 1 and then decrease it by 1 for a particular shard.
In my opinion, there are two possible solutions here:
- Supports heterogeneous capabilities in the sharding dimension and supports configurations such as different replicas for each shard
- Similar to
maxsurge, it allows scaling out first and then scaling in while maintaining the same replica configuration.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
If this is a new feature, please describe the motivation and goals.
A clear and concise description of why you want to happen, link the design doc if possible
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.