How to Use Tenant RC in TiDB

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: TIBD 的租户 RC 如何使用

| username: xiaoqiao

【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】V7.5.1
【Encountered Problem: Problem Phenomenon and Impact】I’ve been researching tenant resource isolation for a long time, but in the case of privatized deployment, the business is more interested in knowing their actual resource situation, such as CPU and memory. When DBAs apply for expansion, they report resources like CPU and memory as well. Currently, I don’t know how to use this multi-tenancy feature. In a privatized situation, there is more emphasis on controlling the specific resource allocation for each business in a large cluster. I wonder if any community members have best practices to share.

| username: hey-hoho | Original post link

You can run real business for a period of time, TiDB will determine how many RUs are needed based on the load.

| username: DBAER | Original post link

Mark, take a look and learn; they all use multi-tenancy.

| username: 随缘天空 | Original post link

Thumbs up

| username: Hacker_QGgM2nks | Original post link

It’s not feasible to go without multi-tenancy now, it’s a big trend. Doesn’t TiDB have the concept of RU later on? But it seems a bit difficult to understand.

| username: TiDBer_HErMeXDz | Original post link

I haven’t learned this yet. Implementing tenants for TiDB is too important.

| username: 友利奈绪 | Original post link

Squatting for a response

| username: RenlySir | Original post link

If you want to allocate based on CPU/memory/IO, it is recommended to record the CPU/memory/IO usage during stress testing in the test environment and compare it with the RU values used. You need to allocate RUs to application-side users based on the proportion.

However, the design of TiDB is actually to shield users from CPU/memory/IO considerations and directly use RUs to differentiate business priorities. For example, when classifying systems, typically one TiDB setup is allocated to 1 A-level, 2 B-level, and n C-level applications. This is relatively reasonable.

| username: xiaoqiao | Original post link

Routine management is not very convenient.

| username: changpeng75 | Original post link

If there are not many requirements for tenant isolation in a private deployment, you can completely treat multi-tenancy as single tenancy.