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

TiDB Lightning のトラブルシューティング

このドキュメントでは、 TiDB Lightning の使用時に発生する可能性のある一般的な問題とその解決策をまとめています。

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

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

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

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

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

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

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

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

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

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

[mydumper]
strict-format = true

原因 4 : TiDB Lightningが古すぎます。

最新バージョンをお試しください。速度がさらに向上するかもしれません。

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]

tidb-lightning起動するためにコマンドラインでnohup直接使用することは推奨されません。 tidb-lightning起動するスクリプトを実行することで起動できます。

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

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がエラーを報告

could not find first pair, this shouldn't happen

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

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 KEY や 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の「 TiDB Lightningを適切に再起動する方法 」セクションも参照してください。

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

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

エラー コードは 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

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

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 。

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

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

原因: テーブルにtimestamp型の列が含まれていますが、時間値自体が存在しません。これは、DST の変更によるか、時間値がサポートされている範囲 (1970 年 1 月 1 日から 2038 年 1 月 19 日) を超えたことが原因です。

ソリューション:

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

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

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

  2. クラスター全体で同じ最新バージョンtzdata (バージョン 2018i 以上) が使用されていることを確認します。

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

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

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

解決：

  • 制限を動的に増やすには、 tidb_txn_entry_size_limitシステム変数を使用します。
  • TiKV にも同様の制限があることに注意してください。単一の書き込み要求のデータ サイズがraft-entry-max-size (デフォルトでは8MiB ) を超えると、TiKV はこの要求の処理を拒否します。テーブルに大きなサイズの行がある場合は、両方の設定を変更する必要があります。

TiDB Lightningがモードを切り替えると、 rpc error: code = Unimplemented ...

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

ソリューション:

  • クラスター内に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ローカル バックエンドは、v4.0.0 以降のバージョンの TiDB クラスターへのデータのインポートのみをサポートします。ローカル バックエンドを使用して v2.x または v3.x クラスターにデータをインポートしようとすると、上記のエラーが報告されます。この時点で、データのインポートに Importer バックエンドまたは TiDB バックエンドを使用するように設定を変更できます。

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

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

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

[mydumper.csv]
header = false

Unknown character set

TiDB はすべての MySQL 文字セットをサポートしていません。そのため、インポート中にテーブル スキーマを作成するときにサポートされていない文字セットが使用されると、 TiDB Lightning はこのエラーを報告します。このエラーを回避するには、特定のデータに応じてTiDB でサポートされている文字セット使用してダウンストリームで事前にテーブル スキーマを作成します。

invalid compression type ...

  • TiDB Lightning v6.4.0 以降のバージョンでは、次の圧縮データ ファイルのみがサポートされています: gzip 、 snappy 、およびzstd 。その他の種類の圧縮ファイルではエラーが発生します。ソース データ ファイルが格納されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクによってエラーが報告されます。このようなエラーを回避するには、サポートされていないファイルをインポート データ ディレクトリから移動します。詳細については、 圧縮ファイル参照してください。

注記：

Snappy 圧縮ファイルは公式Snappyフォーマットである必要があります。Snappy 圧縮の他のバリエーションはサポートされていません。

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