TiDB トラブルシューティング マップ

このドキュメントでは、TiDB およびその他のコンポーネントの一般的な問題をまとめています。このマップを使用して、関連する問題が発生したときに問題を診断して解決できます。

1. サービス利用不可

1.1 クライアントがRegion is Unavailableエラーを報告する

• 1.1.1 通常、 Region is Unavailableのエラーは、リージョンが一定期間利用できないために発生します。 TiKV server is busyが発生するか、 not leaderまたはepoch not matchが原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする可能性があります。このような場合、TiDB はbackoffの再試行メカニズムを実行します。 backoffがしきい値 (デフォルトでは 20 秒) を超えると、クライアントにエラーが送信されます。 backoffのしきい値内では、このエラーはクライアントには表示されません。

• 1.1.2 複数の TiKV インスタンスが同時に OOM であるため、OOM 期間中にリーダーが発生しません。中国語でケース-991を参照してください。

• 1.1.3 TiKV はTiKV server is busyを報告し、 backoff時間を超えます。詳細については、 4.3を参照してください。 TiKV server is busyは内部フロー制御メカニズムの結果であり、 backoff時間にカウントされるべきではありません。この問題は修正される予定です。

• 1.1.4 複数の TiKV インスタンスの開始に失敗したため、リージョンにリーダーがありません。複数の TiKV インスタンスが物理マシンにデプロイされている場合、ラベルが適切に構成されていないと、物理マシンの障害によってリージョンにリーダーが存在しなくなる可能性があります。中国語でケース-228を参照してください。

• 1.1.5 フォロワーの適用が前のエポックで遅れている場合、フォロワーがリーダーになった後、 epoch not matchでリクエストを拒否します。中国語のケース-958を参照してください (TiKV はそのメカニズムを最適化する必要があります)。

1.2 PD エラーによりサービスが利用できなくなる

5 PDの問題を参照してください。

2. レイテンシが大幅に増加

2.1 一時的な増加

• 2.1.1 間違った TiDB 実行計画により、レイテンシーが増加します。 3.3を参照してください。
• 2.1.2 PD リーダー選挙の問題または OOM。 5.2と5.3を参照してください。
• 2.1.3 一部の TiKV インスタンスで多数のリーダー ドロップが発生する。 4.4を参照してください。

2.2 持続的かつ大幅な増加

• 2.2.1 TiKV シングルスレッドのボトルネック

  • TiKV インスタンス内のリージョンが多すぎると、単一の gRPC スレッドがボトルネックになります ( Grafana -> TiKV-details -> Thread CPU/gRPC CPU Per Threadメトリックを確認してください)。 v3.x 以降のバージョンでは、 Hibernate Regionを有効にして問題を解決できます。中国語でケース-612を参照してください。

  • v3.0 より前のバージョンでは、raftstore スレッドまたは適用スレッドがボトルネックになる場合 ( Grafana -> TiKV-details -> Thread CPU/raft store CPUおよびAsync apply CPUメトリクスが80%を超える)、TiKV (v2 .x) インスタンスまたはマルチスレッドで v3.x にアップグレードします。

• 2.2.2 CPU 負荷が増加します。

• 2.2.3 TiKV 書き込みが遅い。 4.5を参照してください。

• 2.2.4 TiDB の間違った実行計画。 3.3を参照してください。

3. TiDB の問題

3.1 DDL

• 3.1.1 decimalフィールドの長さを変更すると、エラーERROR 1105 (HY000): unsupported modify decimal column precisionが報告されます。 TiDB はdecimalフィールドの長さの変更をサポートしていません。

• 3.1.2 TiDB DDL ジョブがハングするか実行が遅い ( admin show ddl jobsを使用して DDL の進行状況を確認する)

  • 原因 1: 他のコンポーネント (PD/TiKV) とのネットワークの問題。

  • 原因 2: TiDB の初期バージョン (v3.0.8 より前) は、同時実行性が高いゴルーチンが多いため、内部負荷が高くなっています。

  • 原因 3: 初期のバージョン (v2.1.15 & バージョン < v3.0.0-rc1) では、PD インスタンスが TiDB キーの削除に失敗し、DDL のすべての変更が 2 つのリースを待機する原因になります。

  • その他の不明な原因については、 バグを報告 .

  • 解決：

    • 原因 1 については、TiDB と TiKV/PD 間のネットワーク接続を確認してください。
    • 原因 2 と 3 については、問題は新しいバージョンで既に修正されています。 TiDB を新しいバージョンにアップグレードできます。
    • その他の原因については、DDL 所有者を移行する次の解決策を使用できます。

  • DDL 所有者の移行:

    • TiDBサーバーに接続できる場合は、所有者選出コマンドを再度実行しcurl -X POST http://{TiDBIP}:10080/ddl/owner/resign 。
    • TiDBサーバーに接続できない場合は、 tidb-ctlを使用して PD クラスターの etcd から DDL 所有者を削除し、再選択をトリガーします: tidb-ctl etcd delowner [LeaseID] [flags] + ownerKey

• 3.1.3 TiDB がログにinformation schema is changedのエラーを報告する

  • 詳細な原因と解決策については、 Information schema is changedた理由エラーが報告されるを参照してください。

  • 背景: 増加したschema versionの数は、各 DDL 変更操作のschema stateの数と一致しています。たとえば、 create table操作には 1 つのバージョン変更があり、 add column操作には 4 つのバージョン変更があります。したがって、列の変更操作が多すぎると、 schema versionが急速に増加する可能性があります。詳細はオンラインスキーマ変更を参照してください。

• 3.1.4 TiDB がログにinformation schema is out of dateを報告する

  • 原因 1: DML ステートメントを実行している TiDBサーバーがgraceful killで停止され、終了の準備をしています。 DML ステートメントを含むトランザクションの実行時間が 1 DDL リースを超えています。トランザクションがコミットされると、エラーが報告されます。

  • 原因 2: DML ステートメントの実行中に、TiDBサーバーが PD または TiKV に接続できません。その結果、TiDBサーバーは 1 つの DDL リース (デフォルトでは45s ) 内で新しいスキーマをロードしなかったか、TiDBサーバーはkeep aliveの設定で PD から切断されました。

  • 原因 3: TiKV の負荷が高いか、ネットワークがタイムアウトになっています。 Grafana -> TiDBおよびTiKVでノードの負荷を確認します。

  • 解決：

    • 原因 1 の場合は、TiDB の開始時に DML 操作を再試行してください。
    • 原因 2 については、TiDBサーバーと PD/TiKV 間のネットワークを確認してください。
    • 原因 3 については、TiKV がビジーである理由を調査します。 4 TiKVの問題を参照してください。

3.2 OOM の問題

• 3.2.1 症状

  • クライアント: クライアントはエラーERROR 2013 (HY000): Lost connection to MySQL server during queryを報告します。

  • ログを確認する

    • dmesg -T | grep tidb-serverを実行します。結果には、エラーが発生した時点の OOM-killer ログが表示されます。

    • エラーが発生した前後の時点 (つまり、tidb-server が再起動した時点) で、「TiDB へようこそ」ログtidb.logを grep します。

    • fatal error: runtime: out of memoryまたはcannot allocate memory in tidb_stderr.logを grep します。

    • v2.1.8 以前のバージョンでは、 tidb_stderr.logのfatal error: stack overflowを grep できます。

  • 監視: tidb-server インスタンスのメモリ使用量が短期間で急激に増加します。

• 3.2.2 OOM の原因となっている SQL ステートメントを見つけます。 (現在、TiDB のすべてのバージョンで SQL を正確に特定することはできません。OOM が SQL ステートメントを特定した後に原因であるかどうかを分析する必要があります。)

  • バージョン >= v3.0.0 の場合、 grep "expensive_query" in tidb.log .このログ メッセージには、タイムアウトしたかメモリ クォータを超えた SQL クエリが記録されます。

  • v3.0.0 より前のバージョンでは、 tidb.logで grep "memory exceeded quota" を実行して、メモリ クォータを超えている SQL クエリを見つけます。

  ノート：

  単一の SQL メモリ使用量のデフォルトのしきい値は1GBです。このパラメータは、システム変数tidb_mem_quota_queryを構成することで設定できます。

• 3.2.3 OOM の問題を軽減する

  • SWAPを有効にすることで、大規模なクエリによるメモリの過剰使用によって引き起こされる OOM の問題を軽減できます。メモリが不足している場合、この方法は I/O オーバーヘッドのために大規模なクエリのパフォーマンスに影響を与える可能性があります。パフォーマンスへの影響の程度は、残りのメモリ容量とディスク I/O 速度によって異なります。

• 3.2.4 OOM の典型的な理由

  • SQL クエリにはjoinがあります。 explainを使用して SQL ステートメントを表示すると、 join操作でHashJoinアルゴリズムが選択され、 innerテーブルが大きいことがわかります。

  • 単一のUPDATE/DELETEクエリのデータ量が大きすぎます。中国語でケース-882を参照してください。

  • SQL には、 Unionで接続された複数のサブクエリが含まれています。中国語でケース-1828を参照してください。

OOM のトラブルシューティングの詳細については、 TiDB OOM の問題のトラブルシューティングを参照してください。

3.3 間違った実行計画

• 3.3.1 症状

  • SQL クエリの実行時間が以前の実行に比べて大幅に長くなった、または実行計画が突然変更された。実行計画がスロー ログに記録されている場合は、実行計画を直接比較できます。

  • SQL クエリの実行時間は、MySQL などの他のデータベースに比べてはるかに長くなります。実行計画を他のデータベースと比較して、 Join Orderなどの違いを確認します。

  • スローログでは、SQL実行回数Scan Keysが多い。

• 3.3.2 実行計画の調査

  • explain analyze {SQL} .実行時間が許容できる場合は、 explain analyzeの結果のcountとexecution infoのrowの数を比較します。 TableScan/IndexScan行目に大きな差が見られる場合は、統計が正しくない可能性があります。他の行で大きな違いが見つかった場合、問題は統計にない可能性があります。

  • select count(*) .実行計画にjoinの操作が含まれている場合、 explain analyzeには時間がかかる場合があります。統計に問題があるかどうかは、 TableScan/IndexScanの条件に対してselect count(*)を実行し、 explainの結果のrow countの情報を比較することで確認できます。

• 3.3.3 緩和

  • v3.0 以降のバージョンでは、 SQL Bind機能を使用して実行プランをバインドします。

  • 統計を更新します。問題の原因が統計にあるとほぼ確信している場合は、 統計をダンプする .原因が、 show stats_metaのmodify count/row countが特定の値 (0.3 など) より大きいなどの古い統計である場合、またはテーブルに時間列のインデックスがある場合は、 analyze tableを使用して回復を試みることができます。 auto analyzeが設定されている場合は、システム変数tidb_auto_analyze_ratioが大きすぎるかどうか (たとえば、0.3 より大きいかどうか)、および現在の時刻がtidb_auto_analyze_start_timeからtidb_auto_analyze_end_timeの間にあるかどうかを確認します。

  • その他の状況については、 バグを報告 .

3.4 SQL実行エラー

• 3.4.1 クライアントはERROR 1265(01000) Data Truncatedのエラーを報告します。これは、TiDB がDecimal型の精度を内部で計算する方法が MySQL の精度と互換性がないためです。この問題は v3.0.10 で修正されています ( #14438 )。

  • 原因：

    MySQL では、2 つの大きな精度のDecimalが除算され、結果が 10 進数の最大精度 ( 30 ) を超える場合、 30桁のみが予約され、エラーは報告されません。

    TiDB では、計算結果は MySQL と同じですが、 Decimalを表すデータ構造内で、10 進精度のフィールドは実際の精度を保持しています。

    例として(0.1^30) / 10を取り上げます。 TiDB と MySQL の結果はどちらも0です。これは、精度が最大で30であるためです。ただし、TiDB では、10 進精度のフィールドは依然として31です。

    複数のDecimal除算の後、結果が正しい場合でも、この精度フィールドがどんどん大きくなり、最終的に TiDB のしきい値を超える可能性があり ( 72 )、 Data Truncatedエラーが報告されます。

    Decimalの乗算では、範囲外がバイパスされ、精度が最大精度制限に設定されるため、この問題は発生しません。

  • 解決策: Cast(xx as decimal(a, b))を手動で追加することにより、この問題を回避できます。ここで、 aとbはターゲット精度です。

4.TiKVの問題

4.1 TiKV がパニックになり、起動に失敗する

• 4.1.1 sync-log = false .マシンの電源をオフにした後、 unexpected raft log index: last_index X < applied_index Yエラーが返されます。

  この問題は予期されたものです。 tikv-ctlを使用してリージョンを復元できます。

• 4.1.2 TiKV が仮想マシンにデプロイされている場合、仮想マシンが強制終了されるか物理マシンの電源がオフになると、 entries[X, Y] is unavailable from storageエラーが報告されます。

  この問題は予期されたものです。仮想マシンのfsyncは信頼できないため、 tikv-ctlを使用してリージョンを復元する必要があります。

• 4.1.3 その他の予期せぬ原因については、 バグを報告 .

4.2 TiKV OOM

• 4.2.1 block-cacheの構成が大きすぎると、OOM が発生する可能性があります。

  問題の原因を確認するには、モニターGrafana -> TiKV-detailsで対応するインスタンスを選択して、RocksDB のblock cache sizeを確認します。

  一方、 [storage.block-cache] capacity = # "1GB"パラメータが正しく設定されているかどうかを確認します。デフォルトでは、TiKV のblock-cacheは、マシンの合計メモリの45%に設定されています。 TiKV はコンテナーのメモリ制限を超える可能性がある物理マシンのメモリを取得するため、コンテナーに TiKV をデプロイするときに、このパラメーターを明示的に指定する必要があります。

• 4.2.2 コプロセッサーが大量のクエリを受け取り、大量のデータを返します。 gRPC は、コプロセッサがデータを返すのと同じ速さでデータを送信できず、OOM が発生します。

  原因を確認するには、モニターGrafana -> TiKV-details -> coprocessor overviewを表示して、 response sizeがnetwork outboundのトラフィックを超えているかどうかを確認できます。

• 4.2.3 他のコンポーネントがメモリを占有しすぎています。

  この問題は予想外です。 バグを報告 .

4.3 クライアントがserver is busyあるというエラーを報告する

モニタGrafana -> TiKV -> errorsを表示して、ビジーの特定の原因を確認します。 server is busyは、TiKV のフロー制御メカニズムが原因であり、TiKV が現在過大な圧力を受けており、後で再試行することをtidb/ti-clientに通知します。

• 4.3.1 TiKV RocksDB はwrite stallに遭遇します。

  TiKV インスタンスには 2 つの RocksDB インスタンスがあり、 data/raftつはRaftログを保存するためのもので、もうdata/dbつは実際のデータを保存するためのものです。ログでgrep "Stalling" RocksDBを実行すると、ストールの具体的な原因を確認できます。 RocksDB ログはLOGで始まるファイルで、 LOGが現在のログです。

  • level0 sstが多すぎると失速します。 [rocksdb] max-sub-compactions = 2 (または 3) パラメータを追加して、 level0 sst圧縮を高速化できます。 level0 から level1 までの圧縮タスクは、複数のサブタスク (サブタスクの最大数はmax-sub-compactionsの値) に分割され、同時に実行されます。中国語でケース-815を参照してください。

  • pending compaction bytesが多すぎると失速します。ディスク I/O は、ビジネス ピーク時の書き込み操作についていけません。この問題は、対応する CF のsoft-pending-compaction-bytes-limitとhard-pending-compaction-bytes-limitを増やすことで軽減できます。

    • [rocksdb.defaultcf] soft-pending-compaction-bytes-limitのデフォルト値は64GBです。保留中の圧縮バイトがしきい値に達すると、RocksDB は書き込み速度を遅くします。 [rocksdb.defaultcf] soft-pending-compaction-bytes-limit ～ 128GBまで設定できます。

    • hard-pending-compaction-bytes-limitのデフォルト値は256GBです。保留中のコンパクション バイト数がしきい値に達すると (保留中のコンパクション バイト数がsoft-pending-compaction-bytes-limitに達すると、RocksDB は書き込みを遅くするため、これが発生する可能性はほとんどありません)、RocksDB は書き込み操作を停止します。 hard-pending-compaction-bytes-limit ～ 512GBまで設定できます。

    • ディスク I/O キャパシティが書き込みに長時間対応できない場合は、ディスクをスケールアップすることをお勧めします。ディスクのスループットが上限に達し、書き込みストールが発生する場合 (たとえば、SATA SSD は NVME SSD よりもはるかに低い)、CPU リソースが十分にある場合は、より高い圧縮率の圧縮アルゴリズムを適用できます。このようにして、CPU リソースがディスク リソースと交換され、ディスクへのプレッシャーが緩和されます。

    • デフォルトの CF 圧縮で圧力が高い場合は、 [rocksdb.defaultcf] compression-per-levelパラメータを["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]から["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]に変更します。

  • memtable が多すぎるとストールが発生します。これは通常、インスタント書き込みの量が多く、memtables がディスクにゆっくりとフラッシュされる場合に発生します。ディスクの書き込み速度を向上させることができず、この問題がビジネスのピーク時にのみ発生する場合は、対応する CF のmax-write-buffer-numberを増やすことで軽減できます。

    • たとえば、 [rocksdb.defaultcf] max-write-buffer-number ～ 8 (デフォルトでは5 ) を設定します。これにより、メモリ内の memtable が増える可能性があるため、ピーク時のメモリ使用量が増える可能性があることに注意してください。

• 4.3.2 scheduler too busy

  • 深刻な書き込み競合。 latch wait durationが高い。モニターGrafana -> TiKV-details -> scheduler prewrite / scheduler commitでlatch wait durationを表示できます。スケジューラーに書き込みタスクが溜まると、保留中の書き込みタスクが[storage] scheduler-pending-write-thresholdで設定されたしきい値 (100MB) を超えます。 MVCC_CONFLICT_COUNTERに対応するメトリクスを表示することで、原因を確認できます。

  • 書き込みが遅いと、書き込みタスクが山積みになります。 TiKV に書き込まれているデータが、 [storage] scheduler-pending-write-thresholdで設定されたしきい値 (100MB) を超えています。 4.5を参照してください。

• 4.3.3 raftstore is busy .メッセージの処理は、メッセージの受信よりも遅くなります。短期的なchannel fullの状態はサービスに影響はありませんが、エラーが長時間続く場合は、リーダーの切り替えが発生する可能性があります。

  • append log遭遇失速。 4.3.1を参照してください。
  • append log durationは高く、メッセージの処理が遅くなります。 4.5を参照して、 append log durationが高い理由を分析できます。
  • raftstore は瞬時に大量のメッセージを受信し (TiKV Raftメッセージ ダッシュボードで確認してください)、それらの処理に失敗します。通常、短期channel fullステータスはサービスに影響しません。

• 4.3.4 TiKV コプロセッサーがキューに入っています。積み上げられたタスクの数がcoprocessor threads * readpool.coprocessor.max-tasks-per-worker-[normal|low|high]を超えています。大規模なクエリが多すぎると、コプロセッサでタスクが積み重なってしまいます。実行計画の変更によって多数のテーブル スキャン操作が発生するかどうかを確認する必要があります。 3.3を参照してください。

4.4 一部の TiKV ノードはリーダーを頻繁にドロップします

• 4.4.1 TiKV再始動による再選

  • TiKV がパニックに陥った後、systemd によってプルアップされ、正常に実行されます。panicが発生したかどうかは、TiKV ログを表示することで確認できます。この問題は想定外であるため、発生した場合はバグを報告 。

  • TiKV はサードパーティによって停止または強制終了され、systemd によってプルアップされます。 dmesgと TiKV ログを参照して原因を確認してください。

  • TiKV は OOM であり、再起動を引き起こします。 4.2を参照してください。

  • THP (Transparent Hugepage) を動的に調整するため、TiKV がハングします。中国語のケースケース-500を参照してください。

• 4.4.2 TiKV RocksDB で書き込みストールが発生し、再選択されます。モニターGrafana -> TiKV-details -> errorsがserver is busyを示しているかどうかを確認できます。 4.3.1を参照してください。

• 4.4.3 ネットワーク分離による再選。

4.5 TiKV 書き込みが遅い

• 4.5.1 TiKV gRPC のprewrite/commit/raw-put期間を表示して、TiKV 書き込みが少ないかどうかを確認します (RawKV クラスターの場合のみ)。一般に、 パフォーマンス マップに従って遅い段階を見つけることができます。一般的な状況を次に示します。

• 4.5.2 スケジューラ CPU がビジーです (トランザクション kv のみ)。

  prewrite/commit のscheduler command durationは、 scheduler latch wait durationとstorage async write durationの合計よりも長くなっています。スケジューラ ワーカーの CPU 需要が高い ( scheduler-worker-pool-size * 100% の 80% を超えるなど) か、マシン全体の CPU リソースが比較的制限されています。書き込みワークロードが大きい場合は、 [storage] scheduler-worker-pool-sizeの設定が小さすぎないかどうかを確認してください。

  その他の状況については、 バグを報告 .

• 4.5.3 ログの追加が遅い。

  TiKV Grafana のRaft IO / append log durationが高いのは、通常、ディスクの書き込み操作が遅いためです。 RocksDB - raft のWAL Sync Duration maxの値を確認することで原因を確認できます。

  その他の状況については、 バグを報告 .

• 4.5.4 raftstore スレッドがビジーです。

  Raft Propose / propose wait durationは、TiKV Grafana の追加ログ期間よりも大幅に長くなります。次の方法を取ります。

  • [raftstore] store-pool-size構成値が小さすぎるかどうかを確認します。値は1 ～ 5の間で、大きすぎない値に設定することをお勧めします。
  • マシンのCPUリソースが不足していないか確認してください。

• 4.5.5 適用が遅い。

  TiKV Grafana のRaft IO / apply log durationは高く、通常はRaft Propose / apply wait durationが高くなります。考えられる原因は次のとおりです。

  • [raftstore] apply-pool-sizeは小さすぎます (値は1から5の間で、大きすぎない値を設定することをお勧めします)、スレッド CPU / apply CPUは大きくなります。

  • マシンの CPU リソースが不足しています。

  • リージョン書き込みホット スポット。 1 つの適用スレッドの CPU 使用率が高くなります。現在、改善中の単一のリージョンでのホット スポットの問題に適切に対処できません。各スレッドの CPU 使用率を表示するには、Grafana 式を変更してby (instance, name)を追加します。

  • RocksDB の書き込みが遅い。 RocksDB kv / max write durationは高いです。 1 つのRaftログに複数の KV が含まれる場合があります。 RocksDB に書き込む場合、128 KV が書き込みバッチで RocksDB に書き込まれます。したがって、適用ログは RocksDB の複数の書き込みに関連付けられる場合があります。

  • その他の状況については、 バグを報告 .

• 4.5.6 Raftコミット ログが遅い。

  TiKV Grafana のRaft IO / commit log durationが高い (このメトリックは、v4.x 以降の Grafana でのみサポートされています)。すべてのリージョンは、独立したRaftグループに対応します。 Raftには、TCP のスライディング ウィンドウ メカニズムに似たフロー制御メカニズムがあります。 [raftstore] raft-max-inflight-msgs = 256パラメータを設定することで、スライディング ウィンドウのサイズを制御できます。書き込みホット スポットがあり、 commit log durationが高い場合は、 1024に増やすなど、パラメーターを調整できます。

• 4.5.7 その他の場合は、 パフォーマンス マップの書き込みパスを参照し、原因を分析してください。

5.PDの問題

5.1 PD スケジューリング

• 5.1.1 マージ

  • テーブル間の空のリージョンはマージできません。 v4.x ではデフォルトでfalseに設定されている TiKV の[coprocessor] split-region-on-tableパラメータを変更する必要があります。中国語でケース-896を参照してください。

  • リージョンのマージが遅い。マージされたオペレーターが生成されているかどうかは、 Grafana -> PD -> operatorでモニター ダッシュボードにアクセスして確認できます。マージを加速するには、 merge-schedule-limitの値を増やします。

• 5.1.2 レプリカの追加またはレプリカのオンライン/オフライン化

  • TiKV ディスクは容量の 80% を使用し、PD はレプリカを追加しません。この状況では、ミスピアの数が増えるため、TiKV をスケールアウトする必要があります。中国語でケース-801を参照してください。

  • TiKV ノードがオフラインになると、一部のリージョンを他のノードに移行できなくなります。この問題は v3.0.4 で修正されています ( #5526 )。中国語でケース-870を参照してください。

• 5.1.3 バランス

  • リーダー/リージョンの数は均等に分散されていません。中国語のケース-394とケース-759を参照してください。主な原因は、バランスがリージョン/リーダーのサイズに基づいてスケジューリングを行うため、カウントの偏りが発生する可能性があることです。 TiDB 4.0 では、 [leader-schedule-policy]パラメーターが導入されました。これにより、リーダーのスケジューリング ポリシーをcountベースまたはsizeベースに設定できます。

5.2 PD の選出

• 5.2.1 PD スイッチ リーダー。

  • 原因 1: ディスク。 PD ノードが配置されているディスクの I/O 負荷が最大になっています。 I/O 要求が高く、ディスクの状態が良好な他のコンポーネントと共に PD が展開されているかどうかを調査します。 Grafana -> disk performance -> レイテンシー / loadでモニター メトリックを表示することで、原因を確認できます。必要に応じて、FIO ツールを使用してディスクのチェックを実行することもできます。中国語でケース-292を参照してください。

  • 原因 2: ネットワーク。 PD ログにはlost the TCP streaming connectionが表示されます。 PD ノード間のネットワークに問題があるかどうかを確認し、モニターGrafana -> PD -> etcdでround tripを表示して原因を確認する必要があります。中国語でケース-177を参照してください。

  • 原因 3: システム負荷が高い。ログにはserver is likely overloadedが表示されます。中国語でケース-214を参照してください。

• 5.2.2 PD がリーダーを選出できない、または選出が遅い。

  • PD がリーダーを選出できない: PD ログはlease is not expiredを示します。 v3.0.x と v2.1.19 でこの問題が修正されました。中国語でケース-875を参照してください。

  • 選挙が遅い:リージョンの読み込み時間が長い。 PD ログでgrep "regions cost"を実行すると、この問題を確認できます。結果がload 460927 regions cost 11.77099sなどの秒単位の場合、リージョンの読み込みが遅いことを意味します。 use-region-storageをtrueに設定することで v3.0 のregion storage機能を有効にできます。これにより、リージョンの読み込み時間が大幅に短縮されます。中国語でケース-429を参照してください。

• 5.2.3 TiDB が SQL ステートメントを実行すると PD がタイムアウトする。

  • PD にはリーダーがないか、リーダーが切り替わります。 5.2.1と5.2.2を参照してください。

  • ネットワークの問題。モニターGrafana -> blackbox_exporter -> ping レイテンシーにアクセスして、TiDB から PD リーダーへのネットワークが正常に動作しているかどうかを確認します。

  • PDパニック。 バグを報告 .

  • PD は OOM です。 5.3を参照してください。

  • 問題に他の原因がある場合は、 curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2とバグを報告を実行して goroutine を取得します。

• 5.2.4 その他の問題

  • PD はFATALエラーを報告し、ログにはrange failed to find revision pairが表示されます。この問題は v3.0.8 ( #2040 ) で修正されています。詳細については、中国語のケース-947を参照してください。

  • その他の状況については、 バグを報告 .

5.3 PD OOM

• 5.3.1 /api/v1/regionsのインターフェースを使用する場合、リージョンが多すぎると PD OOM が発生する可能性があります。この問題は v3.0.8 で修正されています ( #1986 )。

• 5.3.2 ローリング アップグレード中の PD OOM。 gRPC メッセージのサイズは制限されておらず、モニターは TCP InSeg が比較的大きいことを示しています。この問題は v3.0.6 で修正されています ( #1952 )。

5.4 グラファナ表示

• 5.4.1 Grafanaのモニター -> PD ->クラスター->ロールはフォロワーを表示します。 Grafana 式の問題は v3.0.8 で修正されました。

6. 生態系ツール

6.1 Binlog

• 6.1.1 TiDB Binlogは、TiDB から変更を収集し、ダウンストリームの TiDB または MySQL プラットフォームにバックアップとレプリケーションを提供するツールです。詳細については、 GitHub の TiDB Binlogを参照してください。

• 6.1.2 Pump/ Drainer Status のUpdate Timeは正常に更新され、ログに異常は表示されませんが、下流にデータが書き込まれません。

  • Binlogは TiDB 構成で有効になっていません。 TiDB の[binlog]構成を変更します。

• 6.1.3 DrainerのsaramaがEOFエラーを報告します。

  • Drainerの Kafka クライアントのバージョンは、Kafka のバージョンと矛盾しています。 [syncer.to] kafka-version構成を変更する必要があります。

• 6.1.4 Drainerが Kafka への書き込みに失敗してパニックになり、Kafka がMessage was too largeエラーを報告します。

  • binlog データが大きすぎるため、Kafka に書き込まれる 1 つのメッセージが大きすぎます。次の Kafka の構成を変更する必要があります。

    message.max.bytes=1073741824
    replica.fetch.max.bytes=1073741824
    fetch.message.max.bytes=1073741824
    

    詳細については、中国語のケース-789を参照してください。

• 6.1.5 アップストリームとダウンストリームのデータの不一致

  • 一部の TiDB ノードは binlog を有効にしません。 v3.0.6 以降のバージョンでは、 http://127.0.0.1:10080/info/allのインターフェースにアクセスすることで、すべてのノードの binlog ステータスを確認できます。 v3.0.6 より前のバージョンでは、構成ファイルを表示して binlog の状態を確認できます。

  • 一部の TiDB ノードはignore binlogステータスになります。 v3.0.6 以降のバージョンでは、 http://127.0.0.1:10080/info/allインターフェイスにアクセスすることで、すべてのノードの binlog ステータスを確認できます。 v3.0.6 より前のバージョンの場合は、TiDB ログをチェックして、 ignore binlogキーワードが含まれているかどうかを確認してください。

  • アップストリームとダウンストリームでタイムスタンプ列の値が一致しません。

    • これは、異なるタイム ゾーンが原因です。 Drainerが上流および下流のデータベースと同じタイム ゾーンにあることを確認する必要があります。 Drainerは/etc/localtimeからタイム ゾーンを取得し、 TZ環境変数をサポートしません。中国語でケース-826を参照してください。

    • TiDB では、timestamp のデフォルト値はnullですが、 MySQL 5.7 (MySQL 8 を除く) の同じデフォルト値は現在の時刻です。したがって、上流の TiDB のタイムスタンプがnullで下流がMySQL 5.7の場合、タイムスタンプ列のデータは矛盾しています。 binlog を有効にする前に、アップストリームでset @@global.explicit_defaults_for_timestamp=on;を実行する必要があります。

  • その他の状況については、 バグを報告 .

• 6.1.6 遅いレプリケーション

  • ダウンストリームは TiDB/MySQL であり、アップストリームは頻繁な DDL 操作を実行します。中国語でケース-1023を参照してください。

  • ダウンストリームは TiDB/MySQL であり、レプリケートされるテーブルには主キーと一意のインデックスがないため、binlog でのパフォーマンスが低下します。主キーまたは一意のインデックスを追加することをお勧めします。

  • ダウンストリームがファイルに出力する場合は、出力ディスクまたはネットワーク ディスクが遅いかどうかを確認します。

  • その他の状況については、 バグを報告 .

• 6.1.7Pumpが binlog を書き込めず、 no space left on deviceのエラーが報告されます。

  • Pumpが binlog データを正常に書き込むには、ローカル ディスク容量が不足しています。ディスク領域をクリーンアップしてから、 Pumpを再起動する必要があります。

• 6.1.8Pumpは起動時にfail to notify all living drainerのエラーを報告します。

  • 原因: Pumpが開始されると、状態がonlineのすべてのDrainerノードに通知されます。 Drainerへの通知に失敗した場合、このエラー ログが出力されます。

  • 解決策: binlogctl ツールを使用して、各Drainerノードが正常かどうかを確認します。これは、 online状態のすべてのDrainerノードが正常に動作していることを確認するためです。 Drainerノードの状態が実際の動作状態と一致しない場合は、binlogctl ツールを使用して状態を変更し、 Pumpを再起動します。ケース通知に失敗したすべての生きているドレーナーを参照してください。

• 6.1.9 Drainerがgen update sqls failed: table xxx: row data is corruption []のエラーを報告します。

  • トリガー: アップストリームは、 DROP COLUMNの DDL を実行しながら、このテーブルで DML 操作を実行します。この問題は v3.0.6 で修正されています。中国語でケース-820を参照してください。

• 6.1.10 Drainerの複製がハングします。プロセスはアクティブなままですが、チェックポイントは更新されません。

  • この問題は v3.0.4 で修正されています。中国語でケース-741を参照してください。

• 6.1.11 コンポーネントのパニック。

  • バグを報告 .

6.2 データ移行

• 6.2.1 TiDB Data Migration (DM) は、MySQL/MariaDB から TiDB へのデータ移行をサポートする移行ツールです。詳細については、 GitHub の DMを参照してください。

• 6.2.2 Access denied for user 'root'@'172.31.43.27' (using password: YES)は、 query statusを実行するか、ログを確認すると表示されます。

  • すべての DM 構成ファイル内のデータベース関連のパスワードはdmctlで暗号化する必要があります。データベースのパスワードが空の場合、パスワードを暗号化する必要はありません。 v1.0.6以降、クリアテキストのパスワードを使用できます。
  • DM の操作中、アップストリーム データベースとダウンストリーム データベースのユーザーは、対応する読み取りおよび書き込み権限を持っている必要があります。データ複製タスクの開始中に、データ移行も自動的に対応する権限を事前チェックしますになります。
  • DM クラスターに異なるバージョンの DM-worker/DM-master/dmctl をデプロイするには、中国語のAskTUGのケーススタディを参照してください。

• 6.2.3 driver: bad connectionのエラーが返されてレプリケーション タスクが中断されます。

  • driver: bad connectionエラーは、DM と下流の TiDB データベースとの間の接続に異常 (ネットワーク障害や TiDB の再起動など) が発生し、現在の要求のデータがまだ TiDB に送信されていないことを示します。

    • DM 1.0.0 GA より前のバージョンの場合、 stop-taskを実行してタスクを停止し、 start-taskを実行してタスクを再開します。
    • DM 1.0.0 GA 以降のバージョンでは、このタイプのエラーに対する自動再試行メカニズムが追加されています。 #265を参照してください。

• 6.2.4 レプリケーション タスクがinvalid connectionのエラーで中断されます。

  • invalid connectionエラーは、DM と下流の TiDB データベース間の接続に異常 (ネットワーク障害、TiDB 再起動、TiKV ビジーなど) が発生し、現在の要求のデータの一部が TiDB に送信されたことを示します。 DM には、レプリケーション タスクでデータを下流に同時にレプリケートする機能があるため、タスクが中断されると、いくつかのエラーが発生する可能性があります。これらのエラーは、 query-statusまたはquery-errorを実行して確認できます。

    • 増分レプリケーション プロセス中にエラーがinvalid connectionだけ発生した場合、DM はタスクを自動的に再試行します。
    • DM が再試行しないか、バージョンの問題が原因で自動再試行に失敗した場合 (自動再試行は v1.0.0-rc.1 で導入されました)、 stop-taskを使用してタスクを停止し、 start-taskを使用してタスクを再開します。

• 6.2.5 リレー ユニットがエラーevent from * in * diff from passed-in event *を報告するか、バイナリ ログの取得または解析に失敗するエラーでレプリケーション タスクが中断されget binlog error ERROR 1236 (HY000) and binlog checksum mismatch, data may be corrupted returned 。

  • DM がリレー ログまたは増分レプリケーションをプルするプロセス中に、上流の binlog ファイルのサイズが 4 GB を超えると、この 2 つのエラーが発生する可能性があります。

  • 原因: リレー ログを書き込むとき、DM は binlog の位置と binlog ファイルのサイズに基づいてイベント検証を実行し、レプリケートされた binlog の位置をチェックポイントとして保存する必要があります。ただし、公式の MySQL は uint32 を使用して binlog 位置を保存します。つまり、4 GB を超える binlog ファイルの binlog 位置がオーバーフローし、上記のエラーが発生します。

  • 解決：

    • 中継処理ユニットの場合、 レプリケーションを手動で回復する ．
    • バイナリログ レプリケーション処理ユニットの場合、 レプリケーションを手動で回復する .

• 6.2.6 DM レプリケーションが中断され、ログがERROR 1236 (HY000) The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.を返す

  • マスター binlog がパージされているかどうかを確認します。

  • relay.metaで記録した位置情報を確認します。

    • relay.metaには空の GTID 情報が記録されています。 DM-worker は、終了時または 30 秒ごとに GTID 情報をメモリにrelay.metaに保存します。 DM-worker が上流の GTID 情報を取得できない場合、空の GTID 情報をrelay.metaに保存します。中国語でケース-772を参照してください。

    • relay.metaで記録された binlog イベントは、不完全な回復プロセスをトリガーし、間違った GTID 情報を記録します。この問題は v1.0.2 で修正されており、以前のバージョンでは発生する可能性があります。

• 6.2.7 DM 複製プロセスがエラーError 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)を返します。

  • この値は、MySQL 8.0 または TiDB に正常に書き込むことはできませんが、 MySQL 5.7には書き込むことができます。 tidb_skip_utf8_checkパラメータを有効にすると、データ形式のチェックをスキップできます。

6.3 TiDB Lightning

• 6.3.1 TiDB Lightningは、大量のデータを TiDB クラスターに高速に完全にインポートするためのツールです。 GitHubの TiDB Lightningを参照してください。

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

  • region-concurrencyの設定が高すぎると、スレッドの競合が発生し、パフォーマンスが低下します。トラブルシューティングの 3 つの方法:

    • 設定は、ログの先頭からregion-concurrencyを検索して見つけることができます。
    • TiDB Lightningがサーバーを他のサービス (インポーターなど) と共有する場合、そのサーバーの CPU コアの総数のregion-concurrency ～ 75% を手動で設定する必要があります。
    • CPU にクォータがある場合 (たとえば、Kubernetes の設定によって制限されている場合)、 TiDB Lightningはこれを読み取れない可能性があります。この場合、 region-concurrencyも手動で減らす必要があります。

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

  • TiDB Lightningのバージョンが古い。インポート速度が向上する可能性がある最新バージョンを試してください。

• 6.3.3 checksum failed: checksum mismatched remote vs local .

  • 原因 1: テーブルに既にデータがある可能性があります。これらの古いデータは、最終的なチェックサムに影響を与える可能性があります。

  • 原因 2: ターゲット データベースのチェックサムが 0 の場合、つまり何もインポートされていない場合、クラスターが過熱してデータの取り込みに失敗している可能性があります。

  • 原因 3: データ ソースがマシンによって生成され、 マイダンパーによってバックアップされていない場合は、テーブルの制約に従っていることを確認してください。例えば：

    • AUTO_INCREMENT列は正である必要があり、値「0」が含まれていません。
    • UNIQUE および PRIMARY KEY に重複するエントリがあってはなりません。

  • 解決策: トラブルシューティングの解決策を参照してください。

• 6.3.4 Checkpoint for … has invalid status:(error code)

  • 原因: チェックポイントが有効になっていて、Lightning/Importer が以前に異常終了しました。偶発的なデータ破損を防ぐために、 TiDB Lightningはエラーが解決されるまで起動しません。エラー コードは 25 未満の整数で、可能な値は0, 3, 6, 9, 12, 14, 15, 17, 18, 20 and 21です。整数は、インポート プロセスで予期しない終了が発生したステップを示します。整数が大きいほど、終了が遅くなります。

  • 解決策: トラブルシューティングの解決策を参照してください。

• 6.3.5 ResourceTemporarilyUnavailable("Too many open engines …: 8")

  • 原因: 同時エンジン ファイルの数が、tikv-importer で指定された制限を超えています。これは、設定ミスが原因である可能性があります。また、設定が正しい場合でも、以前に tidb-lightning が異常終了したことがあると、エンジン ファイルがダングリング オープン状態のままになる可能性があり、これも同様のエラーを引き起こす可能性があります。
  • 解決策: トラブルシューティングの解決策を参照してください。

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

  • 原因: TiDB Lightningは、UTF-8 および GB-18030 エンコーディングのみをサポートしています。このエラーは、ファイルがこれらのエンコーディングのいずれでもないことを意味します。過去の ALTER TABLE の実行により、UTF-8 の文字列と GB-18030 の別の文字列が含まれているなど、ファイルにエンコーディングが混在している可能性もあります。

  • 解決策: トラブルシューティングの解決策を参照してください。

• 6.3.7 [sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'

  • 原因: タイムスタンプ タイプのエントリに、存在しない時間値があります。これは、DST の変更が原因であるか、時間の値がサポートされている範囲 (1970 年 1 月 1 日から 2038 年 1 月 19 日まで) を超えたためです。

  • 解決策: トラブルシューティングの解決策を参照してください。

7. 共通ログ分析

7.1 TiDB

• 7.1.1 GC life time is shorter than transaction duration .

  トランザクション期間が GC の有効期間 (既定では 10 分) を超えています。

  tidb_gc_life_timeシステム変数を変更することで、GC の寿命を延ばすことができます。通常、このパラメーターを変更することはお勧めしません。これを変更すると、このトランザクションにUPDATEステートメントとDELETEステートメントが多数含まれている場合、多くの古いバージョンが蓄積される可能性があるためです。

• 7.1.2 txn takes too much time .

  このエラーは、長時間 (590 秒以上) コミットされていないトランザクションをコミットすると返されます。

  アプリケーションがこのような長時間のトランザクションを実行する必要がある場合は、 [tikv-client] max-txn-time-use = 590パラメータと GC の有効期間を増やして、この問題を回避できます。アプリケーションがそのような長いトランザクション時間を必要とするかどうかを確認することをお勧めします。

• 7.1.3 coprocessor.goレポートrequest outdated 。

  このエラーは、TiKV に送信されたコプロセッサー要求が TiKV のキューで 60 秒以上待機している場合に返されます。

  TiKV コプロセッサーが長いキューに入っている理由を調査する必要があります。

• 7.1.4 region_cache.goは多数のswitch region peer to next due to send request failを報告し、エラー メッセージはcontext deadline exceededです。

  TiKV のリクエストがタイムアウトになり、リージョン キャッシュがトリガーされて、リクエストが他のノードに切り替えられます。ログのaddrフィールドでgrep "<addr> cancelledコマンドを引き続き実行し、 grepの結果に従って次の手順を実行できます。

  • send request is cancelled : 送信フェーズ中にリクエストがタイムアウトしました。 Grafana -> TiDB -> Batch Client / Pending Request Count by TiKVの監視を調査し、保留中の要求数が 128 より大きいかどうかを確認できます。

    • 128を超えると送信がKVの処理能力を超えてしまうため、送信が重なってしまいます。
    • 値が 128 以下の場合は、ログをチェックして、レポートが対応する KV の運用および保守の変更によって引き起こされているかどうかを確認します。それ以外の場合、このエラーは予期しないものであり、 バグを報告する必要があります。

  • wait response is cancelled : リクエストが TiKV に送信された後にタイムアウトになりました。対応する TiKV アドレスの応答時間を確認する必要があり、その時点でリージョンが PD と KV にログインします。

• 7.1.5 distsql.goレポートinconsistent index 。

  データ インデックスに一貫性がないようです。報告されたインデックスがあるテーブルでadmin check table <TableName>コマンドを実行します。チェックが失敗した場合は、次のコマンドを実行してガベージ コレクションを無効にし、 バグを報告 :

  SET GLOBAL tidb_gc_enable = 0;
  

7.2 TiKV

• 7.2.1 key is locked .

  読み取りと書き込みが競合しています。読み取り要求は、コミットされていないデータに遭遇し、データがコミットされるまで待機する必要があります。

  このエラーの数が少ない場合はビジネスに影響はありませんが、このエラーの数が多い場合は、ビジネスで読み取りと書き込みの競合が深刻であることを示しています。

• 7.2.2 write conflict .

  これは、楽観的なトランザクションにおける書き込みと書き込みの競合です。複数のトランザクションが同じキーを変更した場合、1 つのトランザクションのみが成功し、他のトランザクションは自動的にタイムスタンプを再度取得して操作を再試行します。ビジネスに影響はありません。

  競合が深刻な場合、複数回の再試行後にトランザクションが失敗する可能性があります。この場合、悲観的ロックを使用することをお勧めします。

• 7.2.3 TxnLockNotFound .

  このトランザクション コミットは遅すぎるため、Time To Live (TTL) 後に他のトランザクションによってロールバックされます。このトランザクションは自動的に再試行されるため、通常、ビジネスは影響を受けません。サイズが 0.25 MB 以下のトランザクションの場合、デフォルトの TTL は 3 秒です。

• 7.2.4 PessimisticLockNotFound .

  TxnLockNotFoundに似ています。悲観的なトランザクション コミットは遅すぎるため、他のトランザクションによってロールバックされます。

• 7.2.5 stale_epoch .

  リクエストのエポックが古いため、TiDB はルーティングを更新した後にリクエストを再送信します。ビジネスに影響はありません。リージョンに分割/マージ操作があるか、レプリカが移行されると、エポックが変更されます。

• 7.2.6 peer is not leader .

  要求は、リーダーではないレプリカに送信されます。エラー応答がどのレプリカが最新のリーダーであるかを示している場合、TiDB はエラーに従ってローカル ルーティングを更新し、新しい要求を最新のリーダーに送信します。通常、ビジネスは影響を受けません。

  v3.0 以降のバージョンでは、以前のリーダーへのリクエストが失敗した場合、TiDB は他のピアを試行し、TiKV ログで頻繁にpeer is not leaderになる可能性があります。 TiDB で対応するリージョンのswitch region peer to next due to send request failのログを確認して、送信エラーの根本原因を特定できます。詳細は7.1.4を参照してください。

  このエラーは、他の理由でリージョンにリーダーがない場合にも返されることがあります。詳細については、 4.4を参照してください。