TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

TiDB Lightningよくある質問

このドキュメントには、 TiDB Lightningに関するよくある質問 (FAQ) と回答が記載されています。

TiDB Lightningでサポートされる最小の TiDB/TiKV/PD クラスター バージョンは何ですか?

TiDB Lightningのバージョンは、クラスターと同じである必要があります。Local-backend モードを使用する場合、使用可能な最も古いバージョンは 4.0.0 です。Importer-backend モードまたは TiDB-backend モードを使用する場合、使用可能な最も古いバージョンは 2.0.9 ですが、3.0 安定バージョンを使用することをお勧めします。

TiDB Lightning は複数のスキーマ (データベース) のインポートをサポートしていますか?

はい。

ターゲット データベースの権限要件は何ですか?

権限の詳細についてはTiDB Lightningを使用するための前提条件参照してください。

TiDB Lightning で1 つのテーブルをインポートするときにエラーが発生しました。他のテーブルに影響しますか? プロセスは終了しますか?

1 つのテーブルのみにエラーが発生した場合でも、残りのテーブルは正常に処理されます。

TiDB Lightning を適切に再起動するにはどうすればよいですか?

  1. tidb-lightningプロセスを停止する 。
  2. 新しいtidb-lightningタスクを開始します。3 などの以前の開始コマンドを実行しますnohup tiup tidb-lightning -config tidb-lightning.toml

インポートされたデータの整合性を確保するにはどうすればよいですか?

TiDB Lightning はデフォルトで、ローカル データ ソースとインポートされたテーブルに対してチェックサムを実行します。チェックサムが一致しない場合は、プロセスが中止されます。これらのチェックサム情報は、ログから読み取ることができます。

ターゲット テーブルでADMIN CHECKSUM TABLE SQL コマンドを実行して、インポートされたデータのチェックサムを再計算することもできます。

ADMIN CHECKSUM TABLE `schema`.`table`;

+---------+------------+---------------------+-----------+-------------+
| Db_name | Table_name | Checksum_crc64_xor  | Total_kvs | Total_bytes |
+---------+------------+---------------------+-----------+-------------+
| schema  | table      | 5505282386844578743 |         3 |          96 |
+---------+------------+---------------------+-----------+-------------+
1 row in set (0.01 sec)

TiDB Lightningではどのようなデータ ソース形式がサポートされていますか?

TiDB Lightning は以下をサポートします:

TiDB Lightning はスキーマとテーブルの作成をスキップできますか?

v5.1 以降、 TiDB Lightning はダウンストリームのスキーマとテーブルを自動的に認識できます。v5.1 より前のバージョンのTiDB Lightning を使用する場合は、 tidb-lightning.tomlの[mydumper]セクションでno-schema = true設定する必要があります。これにより、 TiDB Lightning はCREATE TABLE呼び出しをスキップし、ターゲット データベースから直接メタデータを取得します。テーブルが実際に欠落している場合、 TiDB Lightning はエラーで終了します。

無効なデータのインポートを禁止するにはどうすればよいですか?

厳密な SQL モードを有効にすると、無効なデータのインポートを禁止できます。

デフォルトでは、 TiDB Lightningで使用されるsql_mode "ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER"であり、日付1970-00-00などの無効なデータが許可されます。

無効なデータのインポートを禁止するには、 tidb-lightning.tomlの[tidb]セクションでsql-mode設定を"STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"に変更する必要があります。

...
[tidb]
sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
...

tidb-lightningプロセスを停止するにはどうすればいいですか?

tidb-lightningプロセスを停止するには、展開方法に応じて対応する操作を選択できます。

  • 手動展開の場合: tidb-lightningフォアグラウンドで実行されている場合は、 Ctrl + C を押して終了します。それ以外の場合は、 ps aux | grep tidb-lightningコマンドを使用してプロセス ID を取得し、 kill -2 ${PID}コマンドを使用してプロセスを終了します。

TiDB Lightning は1 ギガビット ネットワーク カードで使用できますか?

TiDB Lightning は、10 ギガビット ネットワーク カードで使用するのが最適です。

1 ギガビット ネットワーク カードは合計 120 MB/秒の帯域幅しか提供できず、これをすべてのターゲット TiKV ストア間で共有する必要があります。TiDB TiDB Lightning は、物理インポート モードで 1 ギガビット ネットワークのすべての帯域幅を簡単に飽和させ、PD に接続できなくなるためクラスターを停止させる可能性があります。

TiDB Lightning がターゲット TiKV クラスターにこれほど多くの空き領域を必要とするのはなぜですか?

レプリカが 3 つのデフォルト設定の場合、ターゲット TiKV クラスターのスペース要件は、データ ソースのサイズの 6 倍になります。次の要因がデータ ソースに反映されていないため、追加の倍数「2」は控えめな見積もりです。

  • インデックスが占めるスペース
  • RocksDB における空間増幅

TiDB Lightningに関連付けられているすべての中間データを完全に破棄するにはどうすればよいですか?

  1. チェックポイント ファイルを削除します。

    tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-remove=all

    何らかの理由でこのコマンドを実行できない場合は、ファイル/tmp/tidb_lightning_checkpoint.pbを手動で削除してみてください。

  2. Local-backend を使用している場合は、構成内のsorted-kv-dirディレクトリを削除します。

  3. 必要に応じて、TiDB クラスター上に作成されたすべてのテーブルとデータベースを削除します。

  4. 残留メタデータをクリーンアップします。次のいずれかの条件が存在する場合は、メタデータ スキーマを手動でクリーンアップする必要があります。

    • TiDB Lightning v5.1.x および v5.2.x バージョンの場合、 tidb-lightning-ctlコマンドではターゲット クラスター内のメタデータ スキーマはクリーンアップされません。手動でクリーンアップする必要があります。
    • チェックポイント ファイルを手動で削除した場合は、ダウンストリーム メタデータ スキーマを手動でクリーンアップする必要があります。そうしないと、後続のインポートの正確性が影響を受ける可能性があります。

    メタデータをクリーンアップするには、次のコマンドを使用します。

    DROP DATABASE IF EXISTS `lightning_metadata`;

TiDB Lightningのランタイム goroutine 情報を取得する方法

  1. TiDB Lightningの設定ファイルでstatus-port指定されている場合は、この手順をスキップしてください。それ以外の場合は、 status-port有効にするためにTiDB Lightningに USR1 信号を送信する必要があります。

    psなどのコマンドを使用してTiDB Lightningのプロセス ID (PID) を取得し、次のコマンドを実行します。

    kill -USR1 <lightning-pid>

    TiDB Lightningのログを確認します。 starting HTTP server started HTTP serverログにstart HTTP server新しく有効になったstatus-port表示されます。

  2. http://<lightning-ip>:<status-port>/debug/pprof/goroutine?debug=2アクセスして、goroutine 情報を取得します。

TiDB Lightning がSQL の配置ルールと互換性がないのはなぜですか?

TiDB Lightning はSQL の配置ルールと互換性がありません。配置ポリシーを含むデータをTiDB Lightning がインポートすると、 TiDB Lightning はエラーを報告します。

その理由は次のように説明されます。

SQL の配置ルールの目的は、テーブルまたはパーティション レベルで特定の TiKV ノードのデータの場所を制御することです。TiDB TiDB Lightning は、テキスト ファイル内のデータをターゲット TiDB クラスターにインポートします。データ ファイルが配置ルールの定義とともにエクスポートされた場合、インポート プロセス中に、 TiDB Lightning は定義に基づいてターゲット クラスター内に対応する配置ルール ポリシーを作成する必要があります。ソース クラスターとターゲット クラスターのトポロジが異なる場合、問題が発生する可能性があります。

ソース クラスターのトポロジが次のようになっているとします。

TiDB Lightning FAQ - source cluster topology

ソース クラスターには次の配置ポリシーがあります。

CREATE PLACEMENT POLICY p1 PRIMARY_REGION="us-east" REGIONS="us-east,us-west";

状況 1:ターゲット クラスターには 3 つのレプリカがあり、トポロジはソース クラスターと異なります。このような場合、 TiDB Lightning がターゲット クラスターに配置ポリシーを作成するときに、エラーは報告されません。ただし、ターゲット クラスターのセマンティクスは間違っています。

TiDB Lightning FAQ - situation 1

状況 2:ターゲット クラスターは、リージョン「us-mid」内の別の TiKV ノードにフォロワー レプリカを配置し、トポロジにリージョン「us-west」がありません。このような場合、ターゲット クラスターで配置ポリシーを作成すると、 TiDB Lightning はエラーを報告します。

TiDB Lightning FAQ - situation 2

回避策:

TiDB Lightningで SQL の配置ルールを使用するには、データをターゲット テーブルにインポートする前に、関連するラベルとオブジェクトがターゲット TiDB クラスターに作成されていることを確認する必要があります。SQL の配置ルールは PD および TiKVレイヤーで機能するため、 TiDB Lightning はインポートされたデータを格納するためにどの TiKV を使用する必要があるかを判断するために必要な情報を取得できます。このように、SQL のこの配置ルールはTiDB Lightningに対して透過的です。

手順は次のとおりです。

  1. データ分散トポロジを計画します。
  2. TiKV および PD に必要なラベルを設定します。
  3. 配置ルール ポリシーを作成し、作成したポリシーをターゲット テーブルに適用します。
  4. TiDB Lightning を使用して、データをターゲット テーブルにインポートします。

TiDB LightningとDumpling を使用してスキーマをコピーするにはどうすればよいですか?

スキーマ定義とテーブル データの両方を 1 つのスキーマから新しいスキーマにコピーする場合は、このセクションの手順に従ってください。 この例では、 testスキーマのコピーをtest2という新しいスキーマに作成する方法を学習します。

  1. 必要なスキーマのみを選択するには、 -B test使用して元のスキーマのバックアップを作成します。

    tiup dumpling -B test -o /tmp/bck1

  2. 次の内容のファイルを/tmp/tidb-lightning.toml作成します。

    [tidb]
host = "127.0.0.1"
port = 4000
user = "root"

[tikv-importer]
backend = "tidb"

[mydumper]
data-source-dir = "/tmp/bck1"

[[mydumper.files]]
pattern = '^[a-z]*\.(.*)\.[0-9]*\.sql$'
schema = 'test2'
table = '$1'
type = 'sql'

[[mydumper.files]]
pattern = '^[a-z]*\.(.*)\-schema\.sql$'
schema = 'test2'
table = '$1'
type = 'table-schema'

    この構成ファイルでは、元のダンプで使用されたスキーマ名とは異なるスキーマ名を使用するため、 schema = 'test2'設定します。ファイル名はテーブルの名前を決定するために使用されます。

  3. この構成ファイルを使用してインポートを実行します。

    tiup tidb-lightning -config /tmp/tidb-lightning.toml

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