楽観的なトランザクションでの書き込みの競合のトラブルシューティング

このドキュメントでは、楽観的なトランザクションで競合を書き込む理由と解決策を紹介します。

TiDB v3.0.8より前では、TiDBはデフォルトで楽観的なトランザクションモデルを使用していました。このモデルでは、TiDBはトランザクションの実行中に競合をチェックしません。代わりに、トランザクションが最終的にコミットされている間に、2フェーズコミット（2PC）がトリガーされ、TiDBチェックで書き込みの競合が発生します。書き込みの競合が存在し、自動再試行メカニズムが有効になっている場合、TiDBは限られた時間内にトランザクションを再試行します。再試行が成功するか、再試行時間の上限に達した場合、TiDBはトランザクション実行の結果をクライアントに返します。したがって、TiDBクラスタに多くの書き込みの競合が存在する場合、期間が長くなる可能性があります。

書き込みの競合の理由

TiDBは、パーコレータートランザクションモデルを使用してトランザクションを実装します。 percolatorは一般的に2PCの実装です。詳細な2PCプロセスについては、 TiDBオプティミスティックトランザクションモデルを参照してください。

クライアントがTiDBにCOMMITの要求を送信した後、TiDBは2PCプロセスを開始します。

TiDBは、トランザクションのすべてのキーから1つのキーをトランザクションの主キーとして選択します。
TiDBは、このコミットに関係するすべてのTiKVリージョンにprewriteのリクエストを送信します。 TiKVは、すべてのキーが正常にプレビューできるかどうかを判断します。
TiDBは、 prewriteの要求すべてが成功したという結果を受け取ります。
TiDBはPDからcommit_tsを取得します。
TiDBは、トランザクションの主キーを含むTiKVリージョンにcommitの要求を送信します。 TiKVはcommitリクエストを受信した後、データの有効性をチェックし、 prewriteステージに残っているロックをクリアします。
commitの要求が正常に返された後、TiDBは成功をクライアントに返します。

書き込みの競合はprewrite段階で発生します。別のトランザクションが現在のキーを書き込んでいることをトランザクションが検出すると（ data.commit_ts > txn.start_ts ）、書き込みの競合が発生します。

書き込みの競合を検出する

TiDB Grafanaパネルで、 KVエラーの下にある次の監視メトリックを確認します。

KVバックオフOPSは、TiKVによって返される1秒あたりのエラーメッセージの数を示します。
txnlockメトリックは、書き込みと書き込みの競合を示します。 txnLockFastメトリックは、読み取りと書き込みの競合を示します。
Lock Resolve OPSは、1秒あたりのトランザクション競合に関連するアイテムの数を示します。
- not_expiredは、ロックのTTLが期限切れになっていないことを示します。競合トランザクションは、TTLが期限切れになるまでロックを解決できません。
- wait_expiredは、トランザクションがロックの有効期限が切れるのを待つ必要があることを示します。
- expiredは、ロックのTTLが期限切れになったことを示します。次に、競合トランザクションはこのロックを解決できます。
KV再試行期間は、KV要求を再送信する期間を示します。

TiDBログで検索するキーワードとして[kv:9007]Write conflictを使用することもできます。キーワードは、書き込みの競合がクラスタに存在することも示します。

書き込みの競合を解決する

クラスタに多くの書き込み競合が存在する場合は、書き込み競合キーとその理由を確認してから、書き込み競合を回避するためにアプリケーションロジックを変更することをお勧めします。クラスタに書き込みの競合が存在する場合、TiDBログファイルに次のようなログが表示されます。

[2020/05/12 15:17:01.568 +08:00] [WARN] [session.go:446] ["commit failed"] [conn=3] ["finished txn"="Txn{state=invalid}"] [error="[kv:9007]Write conflict, txnStartTS=416617006551793665, conflictStartTS=416617018650001409, conflictCommitTS=416617023093080065, key={tableID=47, indexID=1, indexValues={string, }} primary={tableID=47, indexID=1, indexValues={string, }} [try again later]"]

上記のログの説明は次のとおりです。

[kv:9007]Write conflict ：書き込みと書き込みの競合を示します。
txnStartTS=416617006551793665 ：現在のトランザクションのstart_tsを示します。 pd-ctlツールを使用して、 start_tsを物理時間に変換できます。
conflictStartTS=416617018650001409 ：書き込み競合トランザクションのstart_tsを示します。
conflictCommitTS=416617023093080065 ：書き込み競合トランザクションのcommit_tsを示します。
key={tableID=47, indexID=1, indexValues={string, }} ：書き込み競合キーを示します。 tableIDは、書き込み競合テーブルのIDを示します。 indexIDは書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログはhandle=xを出力し、どのレコード（行）に競合があるかを示します。 indexValuesは、競合するインデックスの値を示します。
primary={tableID=47, indexID=1, indexValues={string, }} ：現在のトランザクションの主キー情報を示します。

pd-ctlツールを使用して、タイムスタンプを読み取り可能な時間に変換できます。

tiup ctl pd -u https://127.0.0.1:2379 tso {TIMESTAMP}

tableIDを使用して、関連するテーブルの名前を見つけることができます。

curl http://{TiDBIP}:10080/db-table/{tableID}

indexIDとテーブル名を使用して、関連するインデックスの名前を見つけることができます。

SELECT * FROM INFORMATION_SCHEMA.TIDB_INDEXES WHERE TABLE_SCHEMA='{db_name}' AND TABLE_NAME='{table_name}' AND INDEX_ID={indexID};

さらに、TiDB v3.0.8以降のバージョンでは、ペシミスティックトランザクションがデフォルトモードになります。ペシミスティックトランザクションモードでは、トランザクションの事前書き込み段階での書き込みの競合を回避できるため、アプリケーションを変更する必要はありません。ペシミスティックトランザクションモードでは、各DMLステートメントは、実行中に関連するキーにペシミスティックロックを書き込みます。この悲観的なロックは、他のトランザクションが同じキーを変更するのを防ぐことができるため、トランザクション2PCのprewriteのステージで書き込みの競合が発生しないようにします。

このページの内容

書き込みの競合の理由
書き込みの競合を検出する
書き込みの競合を解決する