TiKV Error: TiKV max timestamp is not synced

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

Original topic: TiKV 报错:TiKV max timestamp is not synced

| username: zouyl

[Test Environment] Testing environment, single-node deployment
[TiDB Version] 7.1

[Encountered Issue: Phenomenon and Impact] Simple small table queries are very slow
[Resource Configuration]

[Attachments: Screenshots/Logs/Monitoring]
2023-11-14 15:16:27 (UTC+08:00)

TiDB 192.168.1.50:4000

[backoff.go:158] [“maxTsNotSynced backoffer.maxSleep 80000ms is exceeded, errors:\nmax timestamp not synced, ctx: region ID: 596255, meta: id:596255 start_key:"t\200\000\000\000\000\000\000\025" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\007\227O" region_epoch:<conf_ver:1 version:12 > peers:<id:596256 store_id:1 > , peer: id:596256 store_id:1 , addr: 192.168.1.50:20160, idx: 0, reqStoreType: TiKvOnly, runStoreType: tikv at 2023-11-14T15:16:25.902875865+08:00\nmax timestamp not synced, ctx: region ID: 596255, meta: id:596255 start_key:"t\200\000\000\000\000\000\000\025" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\007\227O" region_epoch:<conf_ver:1 version:12 > peers:<id:596256 store_id:1 > , peer: id:596256 store_id:1 , addr: 192.168.1.50:20160, idx: 0, reqStoreType: TiKvOnly, runStoreType: tikv at 2023-11-14T15:16:26.403465329+08:00\nmax timestamp not synced, ctx: region ID: 596255, meta: id:596255 start_key:"t\200\000\000\000\000\000\000\025" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\007\227O" region_epoch:<conf_ver:1 version:12 > peers:<id:596256 store_id:1 > , peer: id:596256 store_id:1 , addr: 192.168.1.50:20160, idx: 0, reqStoreType: TiKvOnly, runStoreType: tikv at 2023-11-14T15:16:26.904038348+08:00\nlongest sleep type: maxTsNotSynced, time: 76010ms”]

2023-11-14 15:16:27 (UTC+08:00)

TiDB 192.168.1.50:4000

[session.go:967] [“can not retry txn”] [label=internal] [error=“[tikv:9011]TiKV max timestamp is not synced”] [IsBatchInsert=false] [IsPessimistic=true] [InRestrictedSQL=true] [tidb_retry_limit=10] [tidb_disable_txn_auto_retry=true]

2023-11-14 15:16:27 (UTC+08:00)

TiDB 192.168.1.50:4000

[session.go:983] [“commit failed”] [“finished txn”=“Txn{state=invalid}”] [error=“[tikv:9011]TiKV max timestamp is not synced”]

2023-11-14 15:16:27 (UTC+08:00)

TiDB 192.168.1.50:4000

[session.go:2239] [“run statement failed”] [schemaVersion=457732] [error=“previous statement: delete from mysql.analyze_options where table_id = 888009: [tikv:9011]TiKV max timestamp is not synced”] [session=“{\n "currDBName": "",\n "id": 0,\n "status": 2,\n "strictMode": true,\n "user": null\n}”]

| username: zouyl | Original post link

Additional resource configuration:

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

Are you using a virtual machine? Check the time on the virtual machine.

| username: Fly-bird | Original post link

Try restarting. Since you are using a single-node version, check the system time and logs. It seems to be a cluster time issue, but since you are on a single-node version, try restarting.

| username: zouyl | Original post link

Yes, I have checked the time on the virtual machine, and there is no problem.

| username: zouyl | Original post link

Restart the virtual machine?

| username: andone | Original post link

I have encountered the same problem.

| username: oceanzhang | Original post link

It’s hard to imagine how such an issue could arise over time.

| username: oceanzhang | Original post link

Did restarting solve the issue?

| username: TiDBer_lBAxWjWQ | Original post link

Rebooting breaks all methods

| username: zouyl | Original post link

Restarting the server resolved the issue.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.