JDBC Data Entry TiKV Error: Data Index Inconsistency, Error 8141

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

Original topic: jdbc 录入数据 tikv 报错 数据索引不一致 , error 8141

| username: TiDBer_uLkdXXxE

Hello teachers, in version 6.5.1, when using JDBC to insert data, TiDB reports a TiKV error 8141 indicating data index inconsistency. Is there a solution for this?

This table has a large amount of data and frequent inserts. The daily increase is about 200 million, with 2 million every 15 minutes. These 2 million records are roughly 5000 batches (one commit per batch) with approximately 20 concurrent threads.

| username: zhanggame1 | Original post link

How about rebuilding the index since the data is not much?

| username: TiDBer_uLkdXXxE | Original post link

Hello, teacher. The data volume in this environment is relatively large, and data entry will be quite frequent in the future. Could you suggest any cost-effective solutions?

| username: zhanggame1 | Original post link

It is best to find a maintenance window to stop the business and rebuild the index.

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

For 8141, you can set parameters to skip error checking.

| username: weixiaobing | Original post link

You can check if this parameter can solve the issue

idb_txn_assertion_level introduced since version v6.0.0

  • Persisted to cluster: Yes
  • Default value: FAST
  • Optional values: OFF, FAST, STRICT
  • This variable is used to set the assertion level. Assertion is a data index consistency check performed during transaction commit, which checks whether the key being written exists. If not, it indicates data index inconsistency and will cause the transaction to abort. For more details, see Data Index Consistency Errors.
  • For newly created clusters of version v6.0.0 and above, the default value is FAST. For upgraded clusters, if the version before the upgrade was below v6.0.0, the default value after the upgrade is OFF.
    • OFF: Disable this check.
    • FAST: Enable most checks with almost no impact on performance.
    • STRICT: Enable all checks, which has a slight impact on the performance of pessimistic transactions when the system load is high.