年越し準備は万全でしょうか。
我が家大晦日の夕食は、息子のねだりでスシローになりそうです。

お待たせしました、分散トランザクションの検証を続けます。

検証シナリオ

A、B銀行間での口座振替を分散トランザクションに見立てます

1.　A銀行の口座からお金を引き出す
2.　B銀行の口座にお金を振り込む

口座振替を上記2つのオペレーションによる1セットとみなすと、
A銀行とB銀行二つのシステム(データベース)に処理が分散され、
どちらか一方だけでは振替が成立せず、分散トランザクションとみることができます。

検証準備

端末を三つ用意します

端末1:　TiDBクラスタを起動
端末2:　トランザクションを実行
端末3:　結果やステータスを確認

端末1から

TiDBクラスタを起動

$ tiup playground --db 2 --pd 3 --kv 3

端末2から

TiDBに接続

$ tiup client

A銀行データベースa_bank、口座テーブルaccountを作成

create database a_bank;
use a_bank;
create table account(name varchar(10) PRIMARY KEY,balance decimal(10,2));
insert into account values('foo',500000);

B銀行データベースb_bank、口座テーブルaccountを作成

create database b_bank;
use b_bank;
create table account(name varchar(10) PRIMARY KEY,balance decimal(10,2));
insert into account values('foo',0);

端末3から

TiDBに接続

$ tiup client

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

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

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

検証スタート

端末2から

トランザクション開始

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

同じセッションから、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)

トランザクションのステータスを確認すると、Idle状態で存在しているようです

select * from information_schema.tidb_trx\G
*************************** 1. row ***************************
ID: 430153886054744065
START_TIME: 2021-12-31T08:27:32.931+09:00
CURRENT_SQL_DIGEST: 
CURRENT_SQL_DIGEST_TEXT: 
STATE: Idle
WAITING_START_TIME: 
MEM_BUFFER_KEYS: 2
MEM_BUFFER_BYTES: 82
SESSION_ID: 7
USER: root
DB: b_bank
ALL_SQL_DIGESTS: ["f53534242526f5f17dd442bf4429823244510563047efdcc0679741ca5833ea6","df9f53eb4cb1672927cb6374dd27fa80a8124ec0186f390ea41cac113d8428ac","dc5f0aff8b925c386a79b6e33f64e79e814e2310a12f0d793fe9ab4c9c8c0eee","28eafac12d18f34fb1bd6a857b73b37fb446d04eacbc3e18834f07ac9eb3c352","e82a3bae628989f0af1c7ce80dd40ddb0eb532f0e4f245e3f07280da22509428","c4ef5a83e75b42191d7e4e51ff33f5a712b8b41e743952a668b405076ce134ac","d7815f6adab7ceebe67882038b7d29c081675c0e94751110ff74213523b6998e"]

端末3から

別セッションから、再度A、B銀行の口座残高を確認

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

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

なんだ、コミットされていたのではなく、下書き(Prewrite)されていただけか。

端末2から

このままコミットしても面白くないので、ロールバックしキャンセルしてみます

rollback;
ROLLBACK

同じセッションから、A、B銀行の口座残高を確認すると、元どおり戻りました

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

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

トランザクションも終了し、存在しません

select * from information_schema.tidb_trx\G

気を取り直し、再度正常系の振替を実施

トランザクション開始

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

コミットします

commit;
COMMIT

同じセッションから、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 * from information_schema.tidb_trx\G

端末3から

別セッションからも、再度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)

問題なし。

TiDBとMySQLの差異に注意

トランザクション処理において、TiDBとMySQLで差異が存在するようです。

スナップショットの取得タイミング

TiDBでは、BEGINやSTART TRANSACTION実行直後に、データベースのスナップショットを取得するのに対し、
MySQLでは、BEGINやSTART TRANSACTIONでトランザクション開始後、InnoDBからデータ取得する最初のSELECT(SELECT FOR UPDATEは対象外)が実行されたらスナップショットを取得する。

要するに、TiDBの
BEGIN,
START TRANSACTION,
START TRANSACTION WITH CONSISTENT SNAPSHOT
などのコマンドは、MySQLの
START TRANSACTION WITH CONSISTENT SNAPSHOT
コマンドに相当するらしいです。

一意制約のチェックタイミング

TiDBの楽観的トランザクションで、プライマリキーや一意制約のチェックタイミングは、DML実行時でなく、COMMIT時に行われる、がデフォルト設定のようです。

詳細は、PingCAP社のドキュメントをご参照ください。
https://docs.pingcap.com/tidb/stable/transaction-overview

終わりに

SQL操作からは、TiDBの方がMySQLのXAトランザクションに比べ、シンプルのようです。
次回は、TiDB分散トランザクションの特性を、いくつかの側面から検証してみます。
お楽しみに。