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

TiDB Lightningよくある質問

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

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

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

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

はい。

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

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

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

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

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

  1. tidb-lightningプロセスを停止する 。
  2. 新しいtidb-lightningタスクを開始します。前の開始コマンド ( 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 はダウンストリームのスキーマとテーブルを自動的に認識できるようになりました。 TiDB Lightning v5.1 より前のバージョンを使用している場合は、 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 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のランタイムゴルーチン情報を取得する方法

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

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

    kill -USR1 <lightning-pid>

    TiDB Lightningのログを確認してください。 starting HTTP server / start HTTP server / started 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 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

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