TiDB データ移行で失敗した DDL ステートメントを処理する

このドキュメントでは、TiDB データ移行 (DM) ツールを使用してデータを移行するときに失敗した DDL ステートメントを処理する方法を紹介します。

現在、TiDB はすべての MySQL 構文と完全に互換性があるわけではありません ( TiDB によってサポートされる DDL ステートメントを参照)。したがって、DM が MySQL から TiDB にデータを移行していて、TiDB が対応する DDL ステートメントをサポートしていない場合、エラーが発生して移行プロセスが中断される可能性があります。この場合、DM のbinlogコマンドを使用して移行を再開できます。

制限

次の状況ではこのコマンドを使用しないでください。

  • 実際の本番環境では、失敗した DDL ステートメントがダウンストリーム TiDB でスキップされることは受け入れられません。
  • 失敗した DDL ステートメントを他の DDL ステートメントで置き換えることはできません。
  • 他の DDL ステートメントをダウンストリーム TiDB に挿入しないでください。

たとえば、 DROP PRIMARY KEY 。このシナリオでは、(DDL ステートメントの実行後) 新しいテーブル スキーマを使用してダウンストリームに新しいテーブルを作成し、すべてのデータをこの新しいテーブルに再インポートすることのみが可能です。

サポートされているシナリオ

移行中に、TiDB でサポートされていない DDL ステートメントが上流で実行され、下流に移行されるため、移行タスクが中断されます。

  • この DDL ステートメントがダウンストリーム TiDB でスキップされることが許容される場合は、 binlog skip <task-name>を使用してこの DDL ステートメントの移行をスキップし、移行を再開できます。
  • この DDL ステートメントが他の DDL ステートメントに置き換えられることが許容される場合は、 binlog replace <task-name>を使用してこの DDL ステートメントを置き換え、移行を再開できます。
  • 他の DDL ステートメントがダウンストリーム TiDB に挿入されることが許容される場合は、 binlog inject <task-name>を使用して他の DDL ステートメントを挿入し、移行を再開できます。

コマンド

dmctl を使用して失敗した DDL ステートメントを手動で処理する場合、一般的に使用されるコマンドにはquery-statusbinlogがあります。

クエリステータス

query-statusコマンドは、各 MySQL インスタンスのサブタスクや中継ユニットなどの現在のステータスをクエリするために使用されます。詳細はクエリステータスを参照してください。

binlog

binlogコマンドは、 binlog操作を管理および表示するために使用されます。このコマンドは、DM v6.0 以降のバージョンでのみサポートされます。以前のバージョンの場合は、 handle-errorコマンドを使用します。

binlogの使い方は以下の通りです。

binlog -h
manage or show binlog operations Usage: dmctl binlog [command] Available Commands: inject inject the current error event or a specific binlog position (binlog-pos) with some ddls list list error handle command at binlog position (binlog-pos) or after binlog position (binlog-pos) replace replace the current error event or a specific binlog position (binlog-pos) with some ddls revert revert the current binlog operation or a specific binlog position (binlog-pos) operation skip skip the current error event or a specific binlog position (binlog-pos) event Flags: -b, --binlog-pos string position used to match binlog event if matched the binlog operation will be applied. The format like "mysql-bin|000001.000003:3270" -h, --help help for binlog Global Flags: -s, --source strings MySQL Source ID. Use "dmctl binlog [command] --help" for more information about a command.

binlog次のサブコマンドをサポートします。

  • inject : DDL ステートメントを現在のエラー イベントまたは特定のbinlog位置に挿入します。binlogの位置を指定するには、 -b, --binlog-posを参照してください。
  • list : 現在のbinlog位置または現在のbinlog位置以降の有効なinjectskip 、およびreplaceの操作をすべてリストします。binlogの位置を指定するには、 -b, --binlog-posを参照してください。
  • replace : 特定のbinlog位置の DDL ステートメントを別の DDL ステートメントに置き換えます。binlogの位置を指定するには、 -b, --binlog-posを参照してください。
  • revert : 前の操作が有効でない場合にのみ、指定されたbinlog操作でinjectskip 、またはreplace操作を元に戻します。binlogの位置を指定するには、 -b, --binlog-posを参照してください。
  • skip : 特定のbinlog位置で DDL ステートメントをスキップします。binlogの位置を指定するには、 -b, --binlog-posを参照してください。

binlog次のフラグをサポートします。

  • -b, --binlog-pos :

    • タイプ: 文字列。
    • binlogの位置を指定します。 binlogイベントの位置がbinlog-pos一致すると、操作が実行されます。これが指定されていない場合、DM は現在失敗した DDL ステートメントに自動的にbinlog-pos設定します。
    • 形式: binlog-filename:binlog-pos 、たとえばmysql-bin|000001.000003:3270
    • 移行がエラーを返した後、 query-statusによって返されたstartLocation分のpositionからbinlogの位置を取得できます。移行でエラーが返される前に、上流の MySQL インスタンスでSHOW BINLOG EVENTSを使用してbinlogの位置を取得できます。
  • -s, --source :

    • タイプ: 文字列。
    • プリセット操作を実行する MySQL インスタンスを指定します。

使用例

移行が中断された場合は DDL をスキップする

移行が中断されたときに DDL ステートメントをスキップする必要がある場合は、次のbinlog skipコマンドを実行します。

binlog skip -h
skip the current error event or a specific binlog position (binlog-pos) event Usage: dmctl binlog skip [flags] Flags: -h, --help help for skip Global Flags: -b, --binlog-pos string position used to match binlog event if matched the binlog operation will be applied. The format like "mysql-bin|000001.000003:3270" -s, --source strings MySQL Source ID.

非シャードマージシナリオ

アップストリーム テーブルdb1.tbl1をダウンストリーム TiDB に移行する必要があると仮定します。初期テーブルのスキーマは次のとおりです。

SHOW CREATE TABLE db1.tbl1;
+-------+--------------------------------------------------+ | Table | Create Table | +-------+--------------------------------------------------+ | tbl1 | CREATE TABLE `tbl1` ( `c1` int(11) NOT NULL, `c2` decimal(11,3) DEFAULT NULL, PRIMARY KEY (`c1`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------+

ここで、次の DDL ステートメントがアップストリームで実行され、テーブル スキーマが変更されます (つまり、c2 の DECIMAL(11, 3) が DECIMAL(10, 3) に変更されます)。

ALTER TABLE db1.tbl1 CHANGE c2 c2 DECIMAL (10, 3);

この DDL ステートメントは TiDB でサポートされていないため、DM の移行タスクは中断されます。 query-status <task-name>コマンドを実行すると、次のエラーが表示されます。

ERROR 8200 (HY000): Unsupported modify column: can't change decimal column precision

実際の本番環境では、この DDL ステートメントがダウンストリーム TiDB で実行されない (つまり、元のテーブル スキーマが保持される) ことが許容されると想定します。その後、 binlog skip <task-name>を使用してこの DDL ステートメントをスキップし、移行を再開できます。手順は次のとおりです。

  1. 現在失敗している DDL ステートメントをスキップするには、 binlog skip <task-name>を実行します。

    » binlog skip test
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "worker1" } ] }
  2. query-status <task-name>を実行してタスクのステータスを表示します。

    » query-status test
    実行結果を参照してください。
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-01", "worker": "worker1", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "test", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10", "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4", "blockingDDLs": [ ], "unresolvedGroups": [ ], "synced": true, "binlogType": "remote", "totalRows": "4", "totalRps": "0", "recentRps": "0" } } ] } ] }

    タスクが正常に実行され、間違った DDL がスキップされていることがわかります。

シャードマージシナリオ

アップストリームの次の 4 つのテーブルをマージして、ダウンストリームの 1 つの同じテーブル`shard_db`.`shard_table`に移行する必要があるとします。タスクモードは「悲観的」です。

  • MySQL インスタンス 1 には、 shard_table_1shard_table_2テーブルを含むshard_db_1スキーマが含まれています。
  • MySQL インスタンス 2 には、 shard_table_1shard_table_2テーブルを含むshard_db_2スキーマが含まれています。

初期テーブルのスキーマは次のとおりです。

SHOW CREATE TABLE shard_db.shard_table;
+-------+-----------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+-----------------------------------------------------------------------------------------------------------+ | tb | CREATE TABLE `shard_table` ( `id` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin | +-------+-----------------------------------------------------------------------------------------------------------+

ここで、上流のすべてのシャードテーブルに対して次の DDL ステートメントを実行して、文字セットを変更します。

ALTER TABLE `shard_db_*`.`shard_table_*` CHARACTER SET LATIN1 COLLATE LATIN1_DANISH_CI;

この DDL ステートメントは TiDB でサポートされていないため、DM の移行タスクは中断されます。 query-statusコマンドを実行すると、 shard_db_1によって報告される次のエラーが表示されます。 shard_table_1 MySQL インスタンスのテーブル 1 とshard_db_2shard_table_1 MySQL インスタンス 2 のテーブル:

{ "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_1` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8" }
{ "Message": "cannot track DDL: ALTER TABLE `shard_db_2`.`shard_table_1` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8" }

実際の本番環境では、この DDL ステートメントがダウンストリーム TiDB で実行されない (つまり、元のテーブル スキーマが保持される) ことが許容されると想定します。その後、 binlog skip <task-name>を使用してこの DDL ステートメントをスキップし、移行を再開できます。手順は次のとおりです。

  1. binlog skip <task-name>を実行して、MySQL インスタンス 1 および 2 で現在失敗している DDL ステートメントをスキップします。

    » binlog skip test
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "worker1" }, { "result": true, "msg": "", "source": "mysql-replica-02", "worker": "worker2" } ] }
  2. query-statusコマンドを実行すると、 shard_db_1によって報告されたエラーが表示されます。 shard_table_2 MySQL インスタンスのテーブル 1 とshard_db_2shard_table_2 MySQL インスタンス 2 のテーブル:

    { "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_2` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8" }
    { "Message": "cannot track DDL: ALTER TABLE `shard_db_2`.`shard_table_2` CHARACTER SET UTF8 COLLATE UTF8_UNICODE_CI", "RawCause": "[ddl:8200]Unsupported modify charset from latin1 to utf8" }
  3. binlog skip <task-name>を再度実行して、MySQL インスタンス 1 および 2 で現在失敗している DDL ステートメントをスキップします。

    » handle-error test skip
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "worker1" }, { "result": true, "msg": "", "source": "mysql-replica-02", "worker": "worker2" } ] }
  4. タスクのステータスを表示するにはquery-status <task-name>を使用します。

    » query-status test
    実行結果を参照してください。
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-01", "worker": "worker1", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "test", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10", "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4", "blockingDDLs": [ ], "unresolvedGroups": [ ], "synced": true, "binlogType": "remote", "totalRows": "4", "totalRps": "0", "recentRps": "0" } } ] }, { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-02", "worker": "worker2", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "test", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10", "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4", "blockingDDLs": [ ], "unresolvedGroups": [ ], "synced": true, "binlogType": "remote", "totalRows": "4", "totalRps": "0", "recentRps": "0" } } ] } ] }

    タスクがエラーなしで正常に実行され、4 つの間違った DDL ステートメントがすべてスキップされていることがわかります。

移行が中断された場合は DDL を置き換えます

移行が中断されたときに DDL ステートメントを置き換える必要がある場合は、次のコマンドbinlog replaceを実行します。

binlog replace -h
replace the current error event or a specific binlog position (binlog-pos) with some ddls Usage: dmctl binlog replace ... [flags] Flags: -h, --help help for replace Global Flags: -b, --binlog-pos string position used to match binlog event if matched the binlog operation will be applied. The format like "mysql-bin|000001.000003:3270" -s, --source strings MySQL Source ID.

非シャードマージシナリオ

アップストリーム テーブルdb1.tbl1をダウンストリーム TiDB に移行する必要があると仮定します。初期テーブルのスキーマは次のとおりです。

SHOW CREATE TABLE db1.tbl1;
+-------+-----------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+-----------------------------------------------------------------------------------------------------------+ | tb | CREATE TABLE `tbl1` ( `id` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin | +-------+-----------------------------------------------------------------------------------------------------------+

ここで、アップストリームで次の DDL 操作を実行して、UNIQUE 制約を持つ新しい列を追加します。

ALTER TABLE `db1`.`tbl1` ADD COLUMN new_col INT UNIQUE;

この DDL ステートメントは TiDB でサポートされていないため、移行タスクは中断されます。 query-statusコマンドを実行すると、次のエラーが表示されます。

{ "Message": "cannot track DDL: ALTER TABLE `db1`.`tbl1` ADD COLUMN `new_col` INT UNIQUE KEY", "RawCause": "[ddl:8200]unsupported add column 'new_col' constraint UNIQUE KEY when altering 'db1.tbl1'", }

この DDL ステートメントは、2 つの同等の DDL ステートメントに置き換えることができます。手順は次のとおりです。

  1. 間違った DDL ステートメントを次のコマンドに置き換えます。

    » binlog replace test "ALTER TABLE `db1`.`tbl1` ADD COLUMN `new_col` INT;ALTER TABLE `db1`.`tbl1` ADD UNIQUE(`new_col`)";
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "worker1" } ] }
  2. タスクのステータスを表示するにはquery-status <task-name>を使用します。

    » query-status test
    実行結果を参照してください。
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-01", "worker": "worker1", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "test", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10", "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4", "blockingDDLs": [ ], "unresolvedGroups": [ ], "synced": true, "binlogType": "remote", "totalRows": "4", "totalRps": "0", "recentRps": "0" } } ] } ] }

    タスクが正常に実行され、間違った DDL ステートメントが新しい DDL ステートメントに置き換えられ、正常に実行されることがわかります。

シャードマージシナリオ

アップストリームの次の 4 つのテーブルをマージして、ダウンストリームの 1 つの同じテーブル`shard_db`.`shard_table`に移行する必要があるとします。タスクモードは「悲観的」です。

  • MySQL インスタンス 1 には、2 つのテーブルshard_table_1およびshard_table_2を持つスキーマshard_db_1があります。
  • MySQL インスタンス 2 には、2 つのテーブルshard_table_1およびshard_table_2を持つスキーマshard_db_2があります。

初期テーブルのスキーマは次のとおりです。

SHOW CREATE TABLE shard_db.shard_table;
+-------+-----------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+-----------------------------------------------------------------------------------------------------------+ | tb | CREATE TABLE `shard_table` ( `id` int(11) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin | +-------+-----------------------------------------------------------------------------------------------------------+

ここで、上流のすべてのシャードテーブルに対して次の DDL 操作を実行して、UNIQUE 制約を持つ新しい列を追加します。

ALTER TABLE `shard_db_*`.`shard_table_*` ADD COLUMN new_col INT UNIQUE;

この DDL ステートメントは TiDB でサポートされていないため、移行タスクは中断されます。 query-statusコマンドを実行すると、 shard_db_1によって報告される次のエラーが表示されます。 shard_table_1 MySQL インスタンスのテーブル 1 とshard_db_2shard_table_1 MySQL インスタンス 2 のテーブル:

{ "Message": "cannot track DDL: ALTER TABLE `shard_db_1`.`shard_table_1` ADD COLUMN `new_col` INT UNIQUE KEY", "RawCause": "[ddl:8200]unsupported add column 'new_col' constraint UNIQUE KEY when altering 'shard_db_1.shard_table_1'", }
{ "Message": "cannot track DDL: ALTER TABLE `shard_db_2`.`shard_table_1` ADD COLUMN `new_col` INT UNIQUE KEY", "RawCause": "[ddl:8200]unsupported add column 'new_col' constraint UNIQUE KEY when altering 'shard_db_2.shard_table_1'", }

この DDL ステートメントは、2 つの同等の DDL ステートメントに置き換えることができます。手順は次のとおりです。

  1. 次のコマンドを使用して、MySQL インスタンス 1 と MySQL インスタンス 2 の間違った DDL ステートメントをそれぞれ置き換えます。

    » binlog replace test -s mysql-replica-01 "ALTER TABLE `shard_db_1`.`shard_table_1` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_1`.`shard_table_1` ADD UNIQUE(`new_col`)";
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "worker1" } ] }
    » binlog replace test -s mysql-replica-02 "ALTER TABLE `shard_db_2`.`shard_table_1` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_2`.`shard_table_1` ADD UNIQUE(`new_col`)";
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-02", "worker": "worker2" } ] }
  2. query-status <task-name>を使用してタスクのステータスを表示すると、 shard_db_1によって報告される次のエラーが表示されます。 shard_table_2 MySQL インスタンスのテーブル 1 とshard_db_2shard_table_2 MySQL インスタンス 2 のテーブル:

    { "Message": "detect inconsistent DDL sequence from source ... ddls: [ALTER TABLE `shard_db`.`tb` ADD COLUMN `new_col` INT UNIQUE KEY] source: `shard_db_1`.`shard_table_2`], right DDL sequence should be ..." }
    { "Message": "detect inconsistent DDL sequence from source ... ddls: [ALTER TABLE `shard_db`.`tb` ADD COLUMN `new_col` INT UNIQUE KEY] source: `shard_db_2`.`shard_table_2`], right DDL sequence should be ..." }
  3. handle-error <task-name> replaceを再度実行して、MySQL インスタンス 1 および 2 の間違った DDL ステートメントを置き換えます。

    » binlog replace test -s mysql-replica-01 "ALTER TABLE `shard_db_1`.`shard_table_2` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_1`.`shard_table_2` ADD UNIQUE(`new_col`)";
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-01", "worker": "worker1" } ] }
    » binlog replace test -s mysql-replica-02 "ALTER TABLE `shard_db_2`.`shard_table_2` ADD COLUMN `new_col` INT;ALTER TABLE `shard_db_2`.`shard_table_2` ADD UNIQUE(`new_col`)";
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "source": "mysql-replica-02", "worker": "worker2" } ] }
  4. タスクのステータスを表示するにはquery-status <task-name>を使用します。

    » query-status test
    実行結果を参照してください。
    { "result": true, "msg": "", "sources": [ { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-01", "worker": "worker1", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "test", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10", "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4", "blockingDDLs": [ ], "unresolvedGroups": [ ], "unresolvedGroups": [ ], "synced": true, "binlogType": "remote", "totalRows": "4", "totalRps": "0", "recentRps": "0" } } ] }, { "result": true, "msg": "", "sourceStatus": { "source": "mysql-replica-02", "worker": "worker2", "result": null, "relayStatus": null }, "subTaskStatus": [ { "name": "test", "stage": "Running", "unit": "Sync", "result": null, "unresolvedDDLLockID": "", "sync": { "masterBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "masterBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-10", "syncerBinlog": "(DESKTOP-T561TSO-bin.000001, 2388)", "syncerBinlogGtid": "143bdef3-dd4a-11ea-8b00-00155de45f57:1-4", "blockingDDLs": [ ], "unresolvedGroups": [ ], "unresolvedGroups": [ ], "synced": try, "binlogType": "remote", "totalRows": "4", "totalRps": "0", "recentRps": "0" } } ] } ] }

    タスクがエラーなしで正常に実行され、4 つの間違った DDL ステートメントがすべて置き換えられていることがわかります。

その他のコマンド

binlogの他のコマンドの使用方法については、上記のbinlog skipbinlog replace例を参照してください。

このページは役に立ちましたか?

Playground
新規
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.