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

TiDB LightningFAQ

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

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

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

はい。

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

TiDB Lightningには、次の権限が必要です。

  • 選択する
  • アップデート
  • ALTER
  • 作成
  • 落とす

TiDB-バックエンドを選択した場合、またはターゲットデータベースを使用してチェックポイントを格納する場合は、さらに次の権限が必要です。

  • 入れる
  • 消去

ローカルバックエンドとインポーターバックエンドは、データがTiKVに直接取り込まれ、TiDB特権システム全体をバイパスするため、これら2つの特権を必要としません。これは、TiKV、TiKV Importer、およびTiDBLightningのポートがクラスタの外部に到達できない限り安全です。

TiDB Lightningのchecksum構成がtrueに設定されている場合、ダウンストリームTiDBの管理ユーザー権限をTiDBLightningに付与する必要があります。

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

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

TiDB Lightningを正しく再起動する方法は？

Importer-backendを使用している場合、ステータスtikv-importerに応じて、TiDBLightningを再起動する基本的なシーケンスは次のようになります。

tikv-importerがまだ実行されている場合：

  1. tidb-lightning停止します 。
  2. ソースデータの修正、設定の変更、ハードウェアの交換など、目的の変更を実行します。
  3. 以前に変更によってテーブルが変更された場合は、 対応するチェックポイントを削除しますも変更されます。
  4. tidb-lightningを開始します。

tikv-importerを再起動する必要がある場合：

  1. tidb-lightning停止します 。
  2. tikv-importer停止します 。
  3. ソースデータの修正、設定の変更、ハードウェアの交換など、目的の変更を実行します。
  4. tikv-importerを開始します。
  5. tidb-lightningを開始し、プログラムがCHECKSUMエラー（存在する場合）で失敗するまで待ちます。
    • tikv-importerを再起動すると、まだ書き込まれているすべてのエンジンファイルが破棄されますが、 tidb-lightningはそれを認識していませんでした。 v3.0以降、最も簡単な方法はtidb-lightningを続行して再試行することです。
  6. 失敗したテーブルとチェックポイントを破棄します
  7. もう一度tidb-lightningを開始します。

Local-backendまたはTiDB-backendを使用している場合、操作は、 tikv-importerがまだ実行されているときにImporter-backendを使用する場合と同じです。

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

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

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

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ではどのような種類のデータソース形式がサポートされていますか？

TiDBLightningは以下をサポートします。

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

はい。ターゲットデータベースにすでにテーブルを作成している場合は、 tidb-lightning.tomlの[mydumper]セクションにno-schema = trueを設定できます。これにより、TiDB LightningはCREATE TABLEの呼び出しをスキップし、ターゲットデータベースからメタデータを直接フェッチします。テーブルが実際に欠落している場合、TiDBLightningはエラーで終了します。

厳密なSQLモードを無効にして、無効なデータをインポートできるようにすることはできますか？

はい。デフォルトでは、TiDB Lightningで使用されるsql_modeは"STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"であり、日付1970-00-00などの無効なデータを許可しません。モードは、 tidb-lightning.tomlの[tidb]セクションのsql-mode設定を変更することで変更できます。

...
[tidb]
sql-mode = ""
...

1つのtikv-importer importerで複数のtidb-lightningインスタンスを処理できますか？

はい、すべてのtidb-lightningつのインスタンスが異なるテーブルで動作する限り。

tikv-importerプロセスを停止する方法は？

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

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

tidb-lightningプロセスを停止する方法は？

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

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

バックグラウンドで実行しているときにtidb-lightningプロセスが突然終了するのはなぜですか？

これは、 tidb-lightningを誤って開始したことが原因である可能性があります。これにより、システムはSIGHUP信号を送信してtidb-lightningプロセスを停止します。この状況では、 tidb-lightning.logは通常次のログを出力します。

[2018/08/10 07:29:08.310 +08:00] [INFO] [main.go:41] ["got signal to exit"] [signal=hangup]

コマンドラインでnohupを直接使用してtidb-lightningを開始することはお勧めしません。スクリプトを実行することでtidb-lightning開始しますできます。

さらに、TiDB Lightningの最後のログに、エラーが「コンテキストがキャンセルされました」と示されている場合は、最初の「エラー」レベルのログを検索する必要があります。この「エラー」レベルのログの後には通常、「終了する信号を取得」が続きます。これは、TiDBLightningが割り込み信号を受信して終了したことを示します。

TiDBクラスタが大量のCPUリソースを使用していて、TiDB Lightningを使用した後、実行速度が非常に遅いのはなぜですか？

tidb-lightningが異常終了した場合、クラスタは「インポート・モード」でスタックしている可能性があり、これは実動には適していません。現在のモードは、次のコマンドを使用して取得できます。

tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode

次のコマンドを使用して、クラスタを強制的に「通常モード」に戻すことができます。

tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode

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

TiDB Lightningツールセットは、10ギガビットネットワークカードで使用するのが最適です。 1ギガビットネットワークカードは、特にtikv-importerの場合はお勧めしません。

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

[import]
# Restricts the total upload speed to TiKV to 100 MB/s or less
upload-speed-limit = "100MB"

TiDB LightningがターゲットTiKVクラスタに非常に多くの空き領域を必要とするのはなぜですか？

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

  • インデックスが占めるスペース
  • RocksDBでのスペース増幅

TiDB Lightningの実行中にTiKVImporterを再起動できますか？

いいえ。TiKVインポーターはエンジンの情報をメモリに保存します。 tikv-importerを再起動すると、接続が失われたためtidb-lightningが停止します。この時点で、これらのTiKVインポーター固有の情報が失われるため、 失敗したチェックポイントを破棄するにする必要があります。その後、TiDBLightningを再起動できます。

正しいシーケンスについては、 TiDB Lightningを正しく再起動する方法は？も参照してください。

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

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

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

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

  2. ローカルバックエンドを使用している場合は、構成内のsorted-kv-dirのディレクトリを削除します。 Importer-backendを使用している場合は、 tikv-importerをホストしているマシンのimportのディレクトリ全体を削除します。

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

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

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

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

    DROP DATABASE IF EXISTS `lightning_metadata`;

TiDB Lightning could not find first pair, this shouldn't happenか？

このエラーは、TiDB Lightningがソートされたローカルファイルを読み取るときに、TiDBLightningによって開かれたファイルの数がシステム制限を超えたために発生する可能性があります。 Linuxシステムでは、 ulimit -nコマンドを使用して、このシステム制限の値が小さすぎるかどうかを確認できます。インポート中にこの値を1000000 （ ulimit -n 1000000 ）に調整することをお勧めします。

インポート速度が遅すぎる

通常、256MBのデータファイルをインポートするのにTiDBLightningはスレッドごとに2分かかります。速度がこれよりはるかに遅い場合は、エラーが発生します。各データファイルにかかった時間は、 restore chunk … takesに記載されているログから確認できます。これは、Grafanaのメトリックからも確認できます。

TiDBLightningが遅くなる理由はいくつかあります。

原因1 ： region-concurrencyの設定が高すぎるため、スレッドの競合が発生し、パフォーマンスが低下します。

  1. 設定は、ログの先頭からregion-concurrencyを検索して見つけることができます。
  2. TiDB Lightningが他のサービス（TiKV Importerなど）と同じマシンを共有している場合、 region-concurrencyをCPUコアの総数の75％に手動で設定する必要があります。
  3. CPUにクォータがある場合（たとえば、Kubernetes設定によって制限されている場合）、TiDBLightningはこれを読み取れない可能性があります。この場合、 region-concurrencyも手動で減らす必要があります。

原因2 ：テーブルスキーマが複雑すぎます。

インデックスを追加するたびに、行ごとに新しいKVペアが導入されます。 N個のインデックスがある場合、インポートされる実際のサイズは、 Dumpling出力のサイズの約（N + 1）倍になります。インデックスが無視できる場合は、最初にスキーマからインデックスを削除し、インポートの完了後にCREATE INDEXを使用してインデックスを追加し直すことができます。

原因3 ：各ファイルが大きすぎます。

TiDB Lightningは、データソースを約256 MBのサイズの複数のファイルに分割して、データを並列処理できる場合に最適に機能します。各ファイルが大きすぎると、TiDBLightningが応答しない場合があります。

データソースがCSVであり、すべてのCSVファイルに改行制御文字（U+000AおよびU+000D）を含むフィールドがない場合は、「厳密な形式」をオンにして、TiDBLightningが大きなファイルを自動的に分割できるようにすることができます。

[mydumper]
strict-format = true

原因4 ：TiDBLightningが古すぎます。

最新バージョンをお試しください！たぶん、新しい速度の改善があります。

checksum failed: checksum mismatched remote vs local

原因：ローカル・データ・ソースとリモートでインポートされたデータベースの表のチェックサムが異なります。このエラーには、いくつかのより深い理由があります。 checksum mismatchedを含むログを確認することで、理由をさらに特定できます。

checksum mismatchedを含む行は、情報total_kvs: x vs yを提供します。ここで、 xは、インポートの完了後にターゲットクラスタによって計算されたキーと値のペア（KVペア）の数を示し、 yは、ローカルデータによって生成されたキーと値のペアの数を示します。ソース。

  • xが大きい場合は、ターゲットクラスタにKVペアが多いことを意味します。
    • このテーブルはインポート前に空ではないため、データチェックサムに影響を与える可能性があります。 TiDB Lightningが以前に失敗してシャットダウンしたが、正しく再起動しなかった可能性もあります。
  • yが大きい場合は、ローカルデータソースにKVペアが多いことを意味します。
    • ターゲットデータベースのチェックサムがすべて0の場合、インポートが発生していないことを意味します。クラスタがビジー状態でデータを受信できない可能性があります。
    • エクスポートされたデータに、値が重複するUNIQUEキーやPRIMARY KEYなどの重複データが含まれている可能性があります。または、データが大文字と小文字を区別する一方で、ダウンストリームテーブル構造は大文字と小文字を区別しない可能性があります。
  • その他の考えられる理由
    • データソースがマシンで生成され、 Dumplingによってバックアップされていない場合は、データがテーブルの制限に準拠していることを確認してください。たとえば、AUTO_INCREMENT列は0ではなく正である必要があります。

ソリューション：

  1. tidb-lightning-ctlを使用して破損したデータを削除し、テーブルの構造とデータを確認してから、TiDB Lightningを再起動して、影響を受けるテーブルを再度インポートします。

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

  2. ターゲットデータベースの負荷を軽減するために、外部データベースを使用してチェックポイントを格納することを検討してください（変更[checkpoint] dsn ）。

  3. TiDB Lightningが不適切に再起動された場合は、 FAQの「 TiDBLightningを正しく再起動する方法 」セクションも参照してください。

Checkpoint for … has invalid status:エラーコード）

原因： チェックポイントが有効であり、TiDBLightningまたはTiKVImporterが以前に異常終了しました。偶発的なデータ破損を防ぐために、エラーが解決されるまでTiDBLightningは起動しません。

エラーコードは25より小さい整数であり、可能な値は0、3、6、9、12、14、15、17、18、20、および21です。整数は、インポートで予期しない終了が発生するステップを示します。処理する。整数が大きいほど、出口が発生する後のステップです。

ソリューション：

無効なデータソースが原因でエラーが発生した場合は、 tidb-lightning-ctlを使用してインポートしたデータを削除し、Lightningを再起動してください。

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

他のオプションについては、 チェックポイント管理セクションを参照してください。

ResourceTemporarilyUnavailable("Too many open engines …: …")

原因：同時エンジンファイルの数がtikv-importerで指定された制限を超えています。これは、設定の誤りが原因である可能性があります。さらに、 tidb-lightningが異常終了した場合、エンジンファイルがぶら下がっているオープン状態のままになる可能性があり、これもこのエラーの原因となる可能性があります。

ソリューション：

  1. tikv-importer.tomlのmax-open-engines設定の値を増やします。この値は通常、使用可能なメモリによって決まります。これは、次を使用して計算できます。

    最大メモリ使用量max-open-engines × write-buffer-size × max-write-buffer-number

  2. table-concurrency + index-concurrencyの値を減らして、 max-open-engines未満にします。

  3. tikv-importerを再起動して、すべてのエンジンファイルを強制的に削除します（デフォルトは./data.import/ ）。これにより、部分的にインポートされたすべてのテーブルも削除されます。これには、TiDBLightningが古いチェックポイントをクリアする必要があります。

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

cannot guess encoding for input file, please convert to UTF-8 manually

原因：TiDB Lightningは、テーブルスキーマのUTF-8およびGB-18030エンコーディングのみを認識します。このエラーは、ファイルがこれらのエンコーディングのいずれにも含まれていない場合に発生します。過去ALTER TABLEの実行により、ファイルにUTF-8の文字列とGB-18030の別の文字列が含まれるなど、エンコードが混在している可能性もあります。

ソリューション：

  1. ファイルが完全にUTF-8またはGB-18030になるようにスキーマを修正します。

  2. ターゲットデータベース内の影響を受けるテーブルを手動でCREATEにし、次に[mydumper] no-schema = trueを設定して自動テーブル作成をスキップします。

  3. チェックをスキップするには、 [mydumper] character-set = "binary"を設定します。これにより、ターゲットデータベースに文字化けが導入される可能性があることに注意してください。

[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 …}'

原因：表にtimestampタイプの列が含まれていますが、時間値自体が存在しません。これは、DSTが変更されたか、時間値がサポートされている範囲（1970年1月1日から2038年1月19日）を超えたことが原因です。

ソリューション：

  1. TiDBLightningとソースデータベースが同じタイムゾーンを使用していることを確認します。

    TiDB Lightningを直接実行する場合、 $TZの環境変数を使用してタイムゾーンを強制できます。

    # Manual deployment, and force Asia/Shanghai.
TZ='Asia/Shanghai' bin/tidb-lightning -config tidb-lightning.toml

  2. Mydumperを使用してデータをエクスポートする場合は、必ず--skip-tz-utcフラグを含めてください。

  3. クラスタ全体が同じ最新バージョンのtzdata （バージョン2018i以降）を使用していることを確認します。

    CentOSで、 yum info tzdataを実行して、インストールされているバージョンと更新があるかどうかを確認します。 yum upgrade tzdataを実行してパッケージをアップグレードします。

[Error 8025: entry too large, the max entry size is 6291456]

原因：TiDB Lightningによって生成されたキーと値のペアの単一行が、TiDBによって設定された制限を超えています。

解決策：

現在、TiDBの制限を回避することはできません。このテーブルを無視して、他のテーブルを正常にインポートできるようにすることしかできません。

Encounter rpc error: code = Unimplemented ... TiDBLightningがモードを切り替えたとき

原因：クラスタの一部のノードがswitch-modeをサポートしていません。たとえば、 switch-modeはサポートされていませんのバージョンがv4.0.0-rc.2より前の場合。

ソリューション：

  • クラスタにTiFlashノードがある場合は、クラスタをv4.0.0-rc.2つ以上のバージョンに更新できます。
  • クラスタをアップグレードしない場合は、TiFlashを一時的に無効にします。

tidb lightning encountered error: TiDB version too old, expected '>=4.0.0', found '3.0.18'

TiDB Lightning Local-バックエンドは、v4.0.0以降のバージョンのTiDBクラスターへのデータのインポートのみをサポートします。ローカルバックエンドを使用してデータをv2.xまたはv3.xクラスタにインポートしようとすると、上記のエラーが報告されます。このとき、データのインポートにImporter-backendまたはTiDB-backendを使用するように構成を変更できます。

一部のnightlyバージョンは、v4.0.0-beta.2に類似している可能性があります。これらのnightlyのバージョンのTiDBLightningは、実際にはローカルバックエンドをサポートしています。 nightlyバージョンを使用しているときにこのエラーが発生した場合は、構成check-requirements = falseを設定することにより、バージョンチェックをスキップできます。このパラメータを設定する前に、TiDBLightningの設定が対応するバージョンをサポートしていることを確認してください。そうしないと、インポートが失敗する可能性があります。

restore table test.district failed: unknown columns in header [...]

このエラーは通常、CSVデータファイルにヘッダーが含まれていないために発生します（最初の行は列名ではなくデータです）。したがって、TiDBLightning構成ファイルに次の構成を追加する必要があります。

[mydumper.csv]
header = false

TiDBLightningのランタイムゴルーチン情報を取得する方法

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

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

    kill -USR1 <lightning-pid>

    TiDBLightningのログを確認してください。 starting HTTP serverのログには、新しく有効になったstarted HTTP serverがstatus-portされstart HTTP server 。

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

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