TiDB 検証ライフ(10-分散トランザクションの検証2) #TiDB

2021年は、皆様にとってどのような年だったでしょうか。
自分にとっては、殻を破るため冒険に出た激動の1年でした。

NewSQLのTiDBに触れ始め、ワクワクさせられながら1ヶ月経ちました。
今回は今年の最終回で、並行トランザクションの同時実行制御(デッドロック含)を検証してみます。
関連して、TiDBトランザクション分離レベルも少しみてみます。

検証環境は、前回TiDB 検証ライフ(9-分散トランザクションの検証1)の環境を続けて使用することにします。

同時実行制御の検証

同時実行制御って大事ですね、TiDBがどこまでやってくれるか気になります。
悩まず、とにかくやってみます。

検証シナリオ

僕がA銀行からB銀行へ、
妻がB銀行からA銀行へ、
同時に振替ボタンを押した、といったシナリオです。

(妻が怒っているように見えますが、フィクションです。とても仲よいです)

検証スタート(悲観的トランザクション)

前回と比べ、端末2、端末3の用途が変わります。

端末2:　僕の振替用セッション
端末3:　妻の振替用セッション

端末2のセッションから、僕が操作開始

A、B銀行の口座残高を確認します

select * from a_bank.account;
 name |  balance  
------+-----------
 foo  | 400000.00 
(1 row)

select * from b_bank.account;
 name |  balance  
------+-----------
 foo  | 100000.00 
(1 row)

トランザクションモードを確認

select @@tidb_txn_mode;
 @@tidb_txn_mode 
-----------------
 pessimistic 
(1 row)

デフォルトの悲観的モードになっています。

トランザクション開始

start transaction;
START TRANSACTION

A銀行から10万円引き出す

update a_bank.account set balance=balance-100000 where name='foo';
UPDATE 1

B銀行に10万円振り込む

update b_bank.account set balance=balance+100000 where name='foo';
UPDATE 1

ここで、端末3のセッションから、妻が操作開始

トランザクションモードを確認

select @@tidb_txn_mode;
 @@tidb_txn_mode 
-----------------
 pessimistic 
(1 row)

デフォルトの悲観的モードになっています。

A、B銀行の口座残高を確認します

select * from a_bank.account;
 name |  balance  
------+-----------
 foo  | 400000.00 
(1 row)

select * from b_bank.account;
 name |  balance  
------+-----------
 foo  | 100000.00 
(1 row)

トランザクション開始

start transaction;
START TRANSACTION

B銀行から10万円引き出す

update b_bank.account set balance=balance-100000 where name='foo';
（待ち状態。。。。。。）
error: mysql: 1205: Lock wait timeout exceeded; try restarting transaction

すると、UPDATEがロック待ちに入り、タイムアウトで失敗しました。
悲観的モードなので、相手の更新中は、ロック待ちに陥ってしまいますね。

じゃ、楽観的トランザクションではどうなるでしょうか。

検証やり直し(楽観的トランザクション)

端末2のセッションから、僕が操作開始

一旦、今までの処理をロールバック

rollback;
ROLLBACK

楽観的モードに切り替え

set @@tidb_txn_mode='optimistic';
SET

select @@tidb_txn_mode;
 @@tidb_txn_mode 
-----------------
 optimistic 
(1 row)

トランザクション開始

start transaction;
START TRANSACTION

A銀行から10万円引き出す

update a_bank.account set balance=balance-100000 where name='foo';
UPDATE 1

B銀行に10万円振り込む

update b_bank.account set balance=balance+100000 where name='foo';
UPDATE 1

ここで、端末3のセッションから、妻が操作開始

一旦、今までの処理をロールバック

rollback;
ROLLBACK

楽観的モードに切り替え

set @@tidb_txn_mode='optimistic';
SET

select @@tidb_txn_mode;
 @@tidb_txn_mode 
-----------------
 optimistic 
(1 row)

トランザクション開始

start transaction;
START TRANSACTION

B銀行から10万円引き出す

update b_bank.account set balance=balance-100000 where name='foo';
UPDATE 1

UPDATEがロック待機せず成功。
悲観的モードとは違う結果だ。

A銀行に10万円振り込む

update a_bank.account set balance=balance+100000 where name='foo';
UPDATE 1

ここも通った。

端末2から、トランザクションのステータスを確認

select * from information_schema.tidb_trx\G
*************************** 1. row ***************************
ID: 430159871769051137
START_TIME: 2021-12-31T14:48:06.619+09:00
CURRENT_SQL_DIGEST: 
CURRENT_SQL_DIGEST_TEXT: 
STATE: Idle
WAITING_START_TIME: 
MEM_BUFFER_KEYS: 4
MEM_BUFFER_BYTES: 158
SESSION_ID: 7
USER: root
DB: b_bank
ALL_SQL_DIGESTS: ["f53534242526f5f17dd442bf4429823244510563047efdcc0679741ca5833ea6","df9f53eb4cb1672927cb6374dd27fa80a8124ec0186f390ea41cac113d8428ac","dc5f0aff8b925c386a79b6e33f64e79e814e2310a12f0d793fe9ab4c9c8c0eee","d7815f6adab7ceebe67882038b7d29c081675c0e94751110ff74213523b6998e"]

Idel状態になっている。

端末3から、トランザクションのステータスを確認

select * from information_schema.tidb_trx\G
*************************** 1. row ***************************
ID: 430159928314822659
START_TIME: 2021-12-31T14:51:42.324+09:00
CURRENT_SQL_DIGEST: 
CURRENT_SQL_DIGEST_TEXT: 
STATE: Idle
WAITING_START_TIME: 
MEM_BUFFER_KEYS: 4
MEM_BUFFER_BYTES: 158
SESSION_ID: 7
USER: root
DB: 
ALL_SQL_DIGESTS: ["f53534242526f5f17dd442bf4429823244510563047efdcc0679741ca5833ea6","8e412fff994ffcdc77c6516ab298cc58851c07c354eb766a283a16bc997845ab","05704c1de71e0adc626cf220a7fbae005553d5ef74ed6bf44dec053cd656d474","d7815f6adab7ceebe67882038b7d29c081675c0e94751110ff74213523b6998e"]

端末2同様、Idle状態。

端末2から、トランザクションをコミット

commit;
COMMIT

コミット成功し、A、B銀行の口座残高も正常に更新されている。

select * from a_bank.account;
 name |  balance  
------+-----------
 foo  | 300000.00 
(1 row)

select * from b_bank.account;
 name |  balance  
------+-----------
 foo  | 200000.00 
(1 row)

端末3から、トランザクションをコミット

commit;
error: mysql: 9007: Write conflict, txnStartTS=430159928314822659, conflictStartTS=430159871769051137, conflictCommitTS=430160050056593410, key={tableID=66, handle=1} primary={tableID=66, handle=1} [try again later]

書き込みで競合発生し失敗。
楽観的モードで、コミット時に競合チェックするのである意味当然か。

この楽観的モードは、大規模な分散データベースとして、TiDBが採用しているストレージエンジンRocksDBが提供している機能らしいです。

トランザクションの分離レベル

並行トランザクション競合時の挙動は、理論上トランザクション分離レベルに依存するようです。
分離レベルは、同時「読み取り/書き込み」で競合発生時、どこまでデータ整合性を担保できるかを示してくれます。

ANSI SQL-92標準で定義されて四つの分離レベルです

Read Uncommitted
Read Committed
Repeatable Read
Serializable

TiDBの分離レベルは何よ

MySQLとの互換性のためRepeatable Readとして知られているSnapshot Isolation(SI)レベルの整合性を実装しているようです。これは、ANSI Repeatable Readレベルとも、MySQL Repeatable Readレベルとも、異なるようでご注意を。

※ PingCAP社のマニュアルから引用: https://docs.pingcap.com/tidb/stable/transaction-isolation-levels

デッドロックの検証

トランザクション間でデッドロックが起きたら、厄介ですね。
通常は外部からロック解除してあげないといけませんが、TiDBはどう対処するでしょうか。

検証シナリオ

僕と妻が、同じA銀行口座に対し、以下のように交互に行レベル操作を行う、といったシナリオです。

僕がfooレコードから1万円引く
妻がbarレコードから1万円引く
僕がbarレコードに1万円足す
妻がfooレコードに1万円足す

操作の肝は、

異なるトランザクションから
同じテーブルの複数行に対し
交互に同じ行の値を更新

で、金額を引いたか足したかは、どうでもよいです。

検証スタート

1. 端末2のセッションから、僕が操作開始

一旦、今までの処理をロールバック

rollback;
ROLLBACK

悲観的モードに切り替え

set @@tidb_txn_mode='pessimistic';
SET

select @@tidb_txn_mode;
 @@tidb_txn_mode 
-----------------
 pessimistic 
(1 row)

A銀行口座にbarレコードを追加

insert into a_bank.account values('bar',800000);
INSERT 1

select * from a_bank.account;
 name |  balance  
------+-----------
 bar  | 800000.00 
 foo  | 300000.00 
(2 rows)

これで、A銀行口座に、foo、barの2レコード存在します。

トランザクション開始

start transaction;
START TRANSACTION

A銀行口座のfooから1万円引く

update a_bank.account set balance=balance-10000 where name='foo';
UPDATE 1

2. 端末3のセッションから、妻が操作開始

一旦、今までの処理をロールバック

rollback;
ROLLBACK

悲観的モードに切り替え

set @@tidb_txn_mode='pessimistic';
SET

select @@tidb_txn_mode;
 @@tidb_txn_mode 
-----------------
 pessimistic 
(1 row)

トランザクション開始

start transaction;
START TRANSACTION

A銀行口座のbarから1万円引く

update a_bank.account set balance=balance-10000 where name='bar';
UPDATE 1

3. 端末2のセッションから、僕が操作

A銀行口座のbarに1万円足す

update a_bank.account set balance=balance+10000 where name='bar';
UPDATE 1

4. 端末3のセッションから、妻が操作

A銀行口座のfooに1万円足す

update a_bank.account set balance=balance+10000 where name='foo';
error: mysql: 1213: Deadlock found when trying to get lock; try restarting transaction

ここで、すぐデッドロックが検知され、処理中断されました。
延々にロック待ちに陥るようなことはなさそうです、すごい!

DEADLOCKS表から詳細情報を確認

select * from information_schema.deadlocks\G
*************************** 1. row ***************************
DEADLOCK_ID: 1
OCCUR_TIME: 2021-12-31T16:48:06.575191+09:00
RETRYABLE: 0
TRY_LOCK_TRX_ID: 430161722650394625
CURRENT_SQL_DIGEST: 05704c1de71e0adc626cf220a7fbae005553d5ef74ed6bf44dec053cd656d474
CURRENT_SQL_DIGEST_TEXT: update `a_bank` . `account` set `balance` = `balance` + ? where `name` = ? ;
KEY: 7480000000000000455F698000000000000001016261720000000000FA
KEY_INFO: {"db_id":57,"db_name":"a_bank","table_id":69,"table_name":"account","index_id":1,"index_name":"PRIMARY","index_values":["bar"]}
TRX_HOLDING_LOCK: 430161741511655425
*************************** 2. row ***************************
DEADLOCK_ID: 1
OCCUR_TIME: 2021-12-31T16:48:06.575191+09:00
RETRYABLE: 0
TRY_LOCK_TRX_ID: 430161741511655425
CURRENT_SQL_DIGEST: 05704c1de71e0adc626cf220a7fbae005553d5ef74ed6bf44dec053cd656d474
CURRENT_SQL_DIGEST_TEXT: update `a_bank` . `account` set `balance` = `balance` + ? where `name` = ? ;
KEY: 7480000000000000455F69800000000000000101666F6F0000000000FA
KEY_INFO: {"db_id":57,"db_name":"a_bank","table_id":69,"table_name":"account","index_id":1,"index_name":"PRIMARY","index_values":["foo"]}
TRX_HOLDING_LOCK: 430161722650394625

デッドロックの詳細情報を確認できます。

発生時間
ロック(待たせる側、待たされる側)
SQL文
レコードのキー

これで、原因調査を行い、再発防止策を立てられそうです。

終わりに

なんとか年越す前に、トランザクション検証を終えることができました。
TiDBの魅力に徐々に引き込まれていきそうです。

2022年は、技術とメンタル両面で自分を磨き上げ強くなりたい、
と心に決めながら、今年の検証ライフを締めさせていただきます。

ご多用中お付き合いいただき、ありがとうございました。
良いお年をお迎えください、来年もどうぞよろしくお願いいたします。