{"id":1364,"date":"2019-06-12T00:00:00","date_gmt":"2019-06-12T00:00:00","guid":{"rendered":"https:\/\/en.pingcap.com\/blog\/tidb-passes-jepsen-test-for-snapshot-isolation-and-single-key-linearizability\/"},"modified":"2024-08-22T07:45:32","modified_gmt":"2024-08-22T14:45:32","slug":"tidb-passes-jepsen-test-for-snapshot-isolation-and-single-key-linearizability","status":"publish","type":"post","link":"https:\/\/www.pingcap.com\/ko\/blog\/tidb-passes-jepsen-test-for-snapshot-isolation-and-single-key-linearizability\/","title":{"rendered":"TiDB Passes Jepsen Test for Snapshot Isolation and Single-Key Linearizability"},"content":{"rendered":"

Earlier this year, we reached out to Kyle Kingsbury, the creator of the Jepsen test suite, to conduct an official Jepsen test on TiDB. Even though we’ve done our own Jepsen test<\/a> before, we thought it was important and valuable to work with Kyle directly to put TiDB through the Jepsen wringer. The results would not only benefit our team as we continue to drive the development of TiDB, but also our users, partners, and community.<\/p>\n

After several months of close collaboration with Kyle, we are excited that TiDB’s first official Jepsen Test report is published. You can read it HERE<\/a>.<\/p>\n

tl;dr:<\/strong><\/em> Kyle tested the following versions of TiDB: 2.1.7, 2.1.8, 3.0.0-beta.1-40, and 3.0.0-rc.2. The latest version, 3.0.0-rc.2, passes Jepsen tests for snapshot isolation and single-key linearizability, and previous versions, TiDB 2.1.8 through 3.0.0-beta.1-40, also pass when the auto-retry mechanism is disabled, which was enabled by default. In 3.0.0-rc.2 and future versions of TiDB, the auto-retry mechanism is disabled<\/em> by default.<\/p>\n

See the discussion of TiDB’s results on Hacker News<\/a>.<\/em><\/p>\n

In this blog post, we would like to provide some additional context to the results and share our thoughts on what’s next.<\/p>\n

<\/span>To (Auto) Retry or Not (Auto) Retry?<\/span><\/h2>\n

Although TiDB tries to be as compatible with MySQL as possible, its nature of a distributed system results in certain differences<\/a>, one of which is the transaction-model<\/a>. On the one hand, TiDB adopts an optimistic transaction model that detects conflicts only when transactions are committing, and the transaction will be rolled back if any conflicts are detected. On the other, being a distributed database means that transactions in TiDB will also be rolled back in the event of failures such as network partitions. However, many of the clients that our current customers use to talk to the databases are tailored for traditional databases like MySQL and Oracle, where commits rarely fail at the default isolation level so retry mechanisms are not needed. For these clients, when commits fail, they abort with errors as this is rendered as rare exceptions in these databases. Unlike traditional databases such as MySQL, in TiDB, if users want to avoid massive commit failures, they need to add mechanisms in their own business logic of their applications to handle the related errors, which is the last thing some customers are willing to do.<\/p>\n

To help our customers solve this problem, we provide a retry mechanism for those failed commits, which automatically retry the conflicting transactions in TiDB. This, however, has its downsides, which we didn’t clearly document. Thanks to Kyle and Jepsen tests for pointing this out, we have updated our documentation<\/a> to keep the users aware of the difference and its possible consequences, and we disabled the transaction retry mechanism by default<\/a> by changing the default value of tidb_disable_txn_auto_retry<\/code> to on<\/code>.<\/p>\n

Regarding the decision on whether to enable or disable the retry mechanism by default, we had gone through some changes. For the 3.0.0 GA version, we had originally planned to change the behavior of tidb_disable_txn_auto_retry<\/code> to make it control the retry over transactions in write conflicts only, and we implemented the same in 3.0.0-beta.1-40. Unfortunately, though, we didn’t update the documentation to reflect the change in time. Thanks to Jepsen tests, we reflected on this change and believed this was not a good design. Therefore, in 3.0.0-rc2, we have adjusted the behavior of tidb_disable_txn_auto_retry<\/code> to what it used to be prior to 3.0.0-beta.1-40, which is consistent with the documentation<\/a>.<\/p>\n

To disable or enable the transaction retry, users can configure both tidb_retry_limit<\/code> \uadf8\ub9ac\uace0 tidb_disable_txn_auto_retry<\/code>, with the following differences:<\/p>\n