Will a transaction be committed if TiKV and TiDB nodes crash after all transaction keys are successfully prewritten in the TiKV Percolator transaction model?

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

Original topic: TIKV Percolator 事务模型,事务 keys prewrite 全部成功后,tikv 和 tidb 节点挂了,这个事务后续还会被 commit 吗?

| username: ylldty

We know that in the Percolator transaction model, as long as the primary key commits successfully, even if all the nodes related to the transaction go down, the other keys can still be committed later without affecting the transaction.

But if the primary key goes down before committing and the corresponding TiDB node also goes down, and the lock TTL of all keys in the transaction has not expired.

At this time, will the resolve lock process of other transactions help commit this transaction? Or can it only choose to roll back after the lock TTL expires?

In the Async Commit transaction, since the primary key lock contains pointers to the secondary keys, the resolve lock should be able to help commit, right?

| username: 大飞哥online | Original post link

To roll back, the second phase requires obtaining the commit_ts.

| username: 春风十里 | Original post link

This is the state where the transaction has been updated but not committed. My understanding is that if the TiDB node executing this transaction crashes, or the session crashes, it will lead to a rollback because the transaction itself has not been successfully committed, and the above situations will cause it to never be committed. If only TiKV crashes, the session should report an error, and the transaction will roll back.

| username: 哈喽沃德 | Original post link

It is necessary to ensure that transactions can ultimately be correctly processed through fault handling and recovery mechanisms.

| username: wangccsy | Original post link

Learn from the experts.

| username: system | Original post link

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