メタデータロック

このドキュメントでは、TiDB のメタデータロックについて説明します。

コンセプト

TiDB は、オンライン非同期スキーマ変更アルゴリズムを使用して、メタデータオブジェクトの変更をサポートします。トランザクションが実行されると、トランザクションの開始時に対応するメタデータスナップショットが取得されます。トランザクション中にメタデータが変更された場合、データの一貫性を確保するために、TiDB はInformation schema is changedエラーを返し、トランザクションはコミットに失敗します。

この問題を解決するために、TiDB v6.3.0 では、オンライン DDL アルゴリズムにメタデータロックが導入されています。ほとんどの DML エラーを回避するために、TiDB はテーブルメタデータの変更中に DML と DDL の優先順位を調整し、実行中の DDL が古いメタデータを持つ DML がコミットされるまで待機するようにします。

シナリオ

TiDB のメタデータロックは、次のようなすべての DDL ステートメントに適用されます。

メタデータロックを有効にすると、TiDB での DDL タスクの実行にパフォーマンス上の影響が出る可能性があります。影響を軽減するために、メタデータロックを必要としないシナリオをいくつか次に示します。

自動コミットが有効になっているクエリはSELECT
ステイル読み取りが有効になっています
一時テーブルにアクセスする

使用法

v6.5.0 以降、TiDB はデフォルトでメタデータロックを有効にします。既存のクラスターを v6.4.0 以前から v6.5.0 以降にアップグレードすると、TiDB はメタデータロックを自動的に有効にします。メタデータロックを無効にするには、システム変数tidb_enable_metadata_lockをOFFに設定します。

インパクト

DML の場合、メタデータロックは実行をブロックせず、デッドロックも発生しません。
メタデータロックを有効にすると、トランザクション内のメタデータオブジェクトの情報は最初のアクセス時に決定され、その後は変更されません。

DDL の場合、メタデータの状態を変更すると、古いトランザクションによって DDL がブロックされる可能性があります。次に例を示します。

セッション 1	セッション2
`CREATE TABLE t (a INT);`
`INSERT INTO t VALUES(1);`
`BEGIN;`
	`ALTER TABLE t ADD COLUMN b INT;`
`SELECT * FROM t;` (テーブル`t`の現在のメタデータバージョンを使用します。5 `(a=1, b=NULL)`返し、テーブル`t`をロックします。)
	`ALTER TABLE t ADD COLUMN c INT;` (セッション 1 によってブロックされています)

繰り返し読み取り分離レベルでは、トランザクションの開始からテーブルのメタデータを決定する時点までの間に、インデックスの追加や列タイプの変更など、データの変更を必要とする DDL が実行されると、DDL は次のようにエラーを返します。

セッション 1	セッション2
`CREATE TABLE t (a INT);`
`INSERT INTO t VALUES(1);`
`BEGIN;`
	`ALTER TABLE t ADD INDEX idx(a);`
`SELECT * FROM t;` (インデックス`idx`は使用できません)
`COMMIT;`
`BEGIN;`
	`ALTER TABLE t MODIFY COLUMN a CHAR(10);`
`SELECT * FROM t;` ( `Error 8028: Information schema is changed`を返す)

可観測性

TiDB v6.3.0 では、現在ブロックされている DDL の情報を取得するのに役立つmysql.tidb_mdl_viewビューが導入されています。

注記：
mysql.tidb_mdl_viewビューを選択するには、 PROCESS権限必要です。

以下は、テーブルtにインデックスを追加する例です。DDL ステートメントALTER TABLE t ADD INDEX idx(a)があると仮定します。

SELECT * FROM mysql.tidb_mdl_view\G
*************************** 1. row ***************************
    JOB_ID: 141
   DB_NAME: test
TABLE_NAME: t
     QUERY: ALTER TABLE t ADD INDEX idx(a)
SESSION ID: 2199023255957
  TxnStart: 08-30 16:35:41.313(435643624013955072)
SQL_DIGESTS: ["begin","select * from `t`"]
1 row in set (0.02 sec)

上記の出力から、 SESSION IDが2199023255957であるトランザクションがADD INDEX DDL をブロックしていることがわかります。 SQL_DIGEST 、このトランザクションによって実行された SQL ステートメント["begin","select * from `t`"]を示しています。ブロックされた DDL の実行を継続するには、次のグローバルKILLステートメントを使用して2199023255957トランザクションを強制終了します。

mysql> KILL 2199023255957;
Query OK, 0 rows affected (0.00 sec)

トランザクションを強制終了した後、 mysql.tidb_mdl_viewビューを再度選択できます。この時点で、前のトランザクションは出力に表示されません。これは、DDL がブロックされていないことを意味します。

SELECT * FROM mysql.tidb_mdl_view\G
Empty set (0.01 sec)

原則

この件についての説明

TiDB の DDL 操作はオンライン DDL モードです。DDL ステートメントが実行されると、変更対象の定義済みオブジェクトのメタデータバージョンは、複数のマイナーバージョン変更を経る可能性があります。オンライン非同期メタデータ変更アルゴリズムは、隣接する 2 つのマイナーバージョンに互換性があることのみを確立します。つまり、2 つのバージョン間の操作によって、DDL によって変更されるオブジェクトのデータ整合性が損なわれることはありません。

テーブルにインデックスを追加すると、DDL ステートメントの状態は次のように変わります: なし -> 削除のみ、削除のみ -> 書き込みのみ、書き込みのみ -> 書き込み再編成、書き込み再編成 -> パブリック。

次のトランザクションのコミットプロセスは、前述の制約に違反します。

トランザクション	トランザクションで使用されるバージョン	クラスター内の最新バージョン	バージョンの違い
txn1	なし	なし	0
txn2	削除のみ	削除のみ	0
txn3	書き込み専用	書き込み専用	0
txn4	なし	書き込み専用	2
txn5	書き込み再編成	書き込み再編成	0
翻訳	書き込み専用	書き込み再編成	1
txn7	公共	公共	0

上の表では、 txn4コミットされたときに使用されるメタデータバージョンは、クラスター内の最新バージョンとは 2 バージョン異なります。これにより、データの不整合が発生する可能性があります。

実装の詳細

メタデータロックにより、TiDB クラスター内のすべてのトランザクションで使用されるメタデータバージョンが最大 1 バージョンしか異ならないことが保証されます。この目標を達成するために、TiDB は次の 2 つのルールを実装します。

DML を実行すると、TiDB は、テーブル、ビュー、対応するメタデータバージョンなど、トランザクションコンテキストで DML によってアクセスされたメタデータオブジェクトを記録します。これらのレコードは、トランザクションがコミットされるとクリーンアップされます。
DDL ステートメントの状態が変化すると、最新バージョンのメタデータがすべての TiDB ノードにプッシュされます。TiDB ノード上のこの状態変化に関連するすべてのトランザクションで使用されるメタデータバージョンと現在のメタデータバージョンの差が 2 未満の場合、TiDB ノードはメタデータオブジェクトのメタデータロックを取得したと見なされます。次の状態変化は、クラスター内のすべての TiDB ノードがメタデータオブジェクトのメタデータロックを取得した後にのみ実行できます。