📣新登場!TiDB Cloud BYOC、TiDB Cloud Filesystem、PostgreSQL-compatible TiDB Cloud Starter がパブリックプレビュー中。このページは自動翻訳されたものです。原文はこちらからご覧ください。

TiDB Lightningに関するよくある質問



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

使用すべき TiDB Lightning のバージョンはどれですか?

ターゲット TiDB クラスターと同じバージョンの TiDB Lightning を使用することをお勧めします。

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

はい。

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

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

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

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

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

  1. tidb-lightningプロセスを停止する 。
  2. 元のタスクの開始に使用したコマンドを再実行して、新しいtidb-lightningタスクを開始します(例: nohup tiup tidb-lightning:<version> -config tidb-lightning.toml)。<version> は元のタスクで使用した TiDB Lightning のバージョンに置き換えてください。

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

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ギガビットネットワークカードは合計120MB/秒の帯域幅しか提供できず、これをすべてのターゲット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のランタイム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 / 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にインポートすると、エラーが報告されます。

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

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

Suppose the source cluster has the following topology:

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を使用してスキーマをコピーするにはどうすればよいですか?

あるスキーマから新しいスキーマにスキーマ定義とテーブルデータの両方をコピーしたい場合は、このセクションの手順に従ってください。この例では、スキーマ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

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