New Version Hot Table Cache Issue

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

Original topic: 新版本热点表缓存问题

| username: Jolyne

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
[Encountered Issue: Issue Phenomenon and Impact]
The cache table is placed under tidbserver, and the value of tidb_table_cache_lease is set. You have to wait until this value expires before you can write. I would like to ask how much interval there is between the expiration of this value and the next value taking effect, and whether it is related to writing.
[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]

| username: tidb菜鸟一只 | Original post link

Here is my understanding:
The value of tidb_table_cache_lease is the lease time for the cached table. Theoretically, if you modify a cached table, you might have to wait for this duration at most.
For example, you have three TiDB nodes A, B, and C, and a cached table t with a lease time of 10 seconds. Node A has cached t for 4 seconds, B for 3 seconds, and C has just cached it, i.e., 0 seconds. The remaining lease times for table t on nodes A, B, and C are 6, 7, and 10 seconds, respectively. If you modify table t on any node at this point, you need to wait for the lease time to expire on all three nodes before the modification can succeed. This means you must wait for the remaining 10 seconds on node C before you can modify the table.

| username: Jolyne | Original post link

I know this. What I want to know is the interval between the expiration of the lease and the next lease. Is it related to parameters? Does the next lease start immediately if the lease expires and there is no write? Then wouldn’t I have to time my data writes to this table precisely? :rofl:

| username: tidb菜鸟一只 | Original post link

The lease will be renewed immediately upon expiration. However, if you modify the table while waiting for all nodes’ leases to expire, the renewal action for all nodes will be blocked by your modification. They can only read the data of this table from TiKV and cannot renew the lease for this table. Therefore, if a table needs frequent modifications, it is better not to cache it.

| username: Jolyne | Original post link

Then it should be this mechanism: writing during modification will be blocked, and then it will be written after the lease expires, which is equivalent to always queuing up. If it is not blocked, it will be written immediately. This is just tested in a test environment. Some associated tables that are not frequently modified need to be placed in the cache table.

| username: zzzzzz | Original post link

| username: 裤衩儿飞上天 | Original post link

Tables that are frequently modified are not suitable for caching.