-
Notifications
You must be signed in to change notification settings - Fork 728
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config, cluster: add an option to halt the cluster scheduling #6498
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -213,6 +213,7 @@ const ( | |
defaultEnableGRPCGateway = true | ||
defaultDisableErrorVerbose = true | ||
defaultEnableWitness = false | ||
defaultHaltScheduling = false | ||
|
||
defaultDashboardAddress = "auto" | ||
|
||
|
@@ -684,6 +685,10 @@ type ScheduleConfig struct { | |
// v1: which is based on the region count by rate limit. | ||
// v2: which is based on region size by window size. | ||
StoreLimitVersion string `toml:"store-limit-version" json:"store-limit-version,omitempty"` | ||
|
||
// HaltScheduling is the option to halt the scheduling. Once it's on, PD will halt the scheduling, | ||
// and any other scheduling configs will be ignored. | ||
HaltScheduling bool `toml:"halt-scheduling" json:"halt-scheduling,string,omitempty"` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Previously, I am trying to introduce a scheduling mode to cover this case. For me, it's ok to use an individual config to control it. Maybe we can name it enable-scheduling or something else. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it's best to use a configuration name with a default value of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When I work on #6553, I found that maybe it's better to use one config for both unsafe recovery or halt, so that we can decouple the dependencies between cluster and coordinator. |
||
} | ||
|
||
// Clone returns a cloned scheduling configuration. | ||
|
@@ -820,6 +825,10 @@ func (c *ScheduleConfig) adjust(meta *configutil.ConfigMetaData, reloading bool) | |
configutil.AdjustString(&c.RegionScoreFormulaVersion, defaultRegionScoreFormulaVersion) | ||
} | ||
|
||
if !meta.IsDefined("halt-scheduling") { | ||
c.HaltScheduling = defaultHaltScheduling | ||
} | ||
|
||
adjustSchedulers(&c.Schedulers, DefaultSchedulers) | ||
|
||
for k, b := range c.migrateConfigurationMap() { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about putting is near "Scheduler is running"
But it makes sense where it is now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer leaving it here since it's more like a cluster-level status rather than the scheduler. Another reason is that if it is placed in the
Scheduler
panel, it may cause many changes to the Grafana JSON file. If it is only appended here, there will be fewer changes.