Tracking issue for the Keyspace Service Limit

[JmPotato]

Background

Service Limit will serve as the first layer boundary for resource control, ensuring that each TiDB Service (virtual cluster) in a multi-tenant (also known as multi-keyspace) environment operates within its allocated resources, preventing tasks from affecting each other, and achieving resource isolation and service stability. A Service Limit can be applied to multiple TiDB instances, and within a single Service Limit, users can continue to create different resource groups.

This is the tracking issue for the Keyspace Service Limit, which aims to:

• Implement RU/s limits for each TiDB Service to ensure fair resource usage.
• Supports multiple resource groups and sets priorities to meet business isolation and flexible scheduling.
• Provide firendly observability to ensure service experience.

Tasks

• Support resource group management at the keyspace level.
  • feat(resourcemanager): add keyspace support for resource group storage #9327
  • feat(resourcemanager): implement keyspace manager for resource groups #9331
• Implement the basic RU/s service limit for the resource groups within the same keyspace.
  • feat(resourcemanager): add service limit for keyspace #9354
• Support modify the service limit for a keyspace dynamically.
  • feat(resourcemanager): add service limit for keyspace #9354
  • feat(resourcemanager): persist the service limits for keyspaces #9413
• Implement a priority allocation mechanism for RU resources among different resource groups under the same service limit.
  • feat(resourcemanager): implement fill rate conciliation based on priority #9427
  • feat(resourcemanager): invalidate the burstable groups by overriding to service limit #9577
• Data collection, aggregation, and observability.
  • feat(resourcemanager): add keyspace name label to metrics #9338
• Client adoption.
  • feat(resourcemanager): add keyspace name label to metrics #9338
  • mcs: enforce keyspace for Resource Group CRUD #9342