*: a better design for concurrent access of GlobalConfig

[bb7133]

Enhancement

Currently, the GlobalConfig is loaded from the configuration file and can be modified('dynamic config') after that, several fields are wrapped with an atomic operation helper to avoid data race issues, for example:

• tidb/sessionctx/variable/sysvar.go

  Line 1608 in cec4acb

  atomic.StoreUint64(&config.GetGlobalConfig().Log.SlowThreshold, uint64(tidbOptInt64(val, logutil.DefaultSlowThreshold)))

But it can be vulnerable, for example:

#30345 is introduced by #29247 but it is really hard for the developers to realize the race issue. In order to solve it, an atomic wrapper is introduced in #30346.

IMO this may easily happen before we find a systematic way to solve it, possible alternatives are:

• Avoid changing the GlobalConfig after bootstrap by removing the 'dynamic configuration'(https://docs.pingcap.com/tidb/stable/dynamic-config#modify-tidb-configuration-online): if we want to change something, it can be archived by system variables.
• Make sure that GlobalConfig can be safely updated if we do keep the ability to change the fields on the fly.

[bb7133]

/cc @morgo Do you think it's a good idea to deprecate 'dynamic configuration' for TiDB-server?

[morgo]

I would love to deprecate dynamic config and eventually the toml config file. For most server options users prefer dynamic config and we can use sysvars. For the options they can't, we could use a mysql-style config file.

The underlying limitation is deciding on the behavior of instance-scoped variables. There are two options:

• This proposal: instance scoped variables
• Making a rule that a variable can be not be instance + global scoped. Only one or the other.

It is waiting for product management to decide.

[morgo]

I have proposed that we address this in refactoring in step 3 of this proposal: #30558