重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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.2PDリーダー選出問題またはOOM。 5.25.3を参照してください。
  • 2.1.3一部のTiKVインスタンスでは、かなりの数のリーダーがドロップします。 4.4を参照してください。

2.2持続的かつ大幅な増加

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

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

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

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

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

  • 2.2.4TiDBの間違った実行プラン。 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.3TiDBはログにinformation schema is changedのエラーを報告します

    • 原因1:DML操作がDDLの下にある表に触れています。 admin show ddl jobを使用して、現在進行中のDDLを確認できます。

    • 原因2:現在のDML操作の実行時間が長すぎます。この間、多くのDDL操作が実行されるため、 schema versionの変更が1024を超えます。新しいバージョンlock tableでも、スキーマのバージョンが変更される可能性があります。

    • 原因3:現在DMLステートメントを実行しているTiDBインスタンスが新しいschema informationをロードできません(PDまたはTiKVのネットワークの問題が原因である可能性があります)。この間、多くのDDLステートメントが実行され( lock tableを含む)、 schema versionの変更が1024を超えます。

    • 解決策:関連するDML操作は失敗後に再試行するため、最初の2つの原因はアプリケーションに影響を与えません。原因3については、TiDBとTiKV/PD間のネットワークを確認する必要があります。

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

  • 3.1.4TiDBはログにinformation schema is out of dateを報告します

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

    • 原因2:TiDBサーバーは、DMLステートメントの実行中に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.2OOMの問題

  • 3.2.1症状

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

    • ログを確認する

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

      • エラーが発生した後の時点(つまり、tidb-serverが再起動したとき)の前後に「WelcometoTiDB」ログインtidb.logをgrepします。

      • fatal error: runtime: out of memory tidb_stderr.log cannot allocate memory

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

    • モニター:tidb-serverインスタンスのメモリ使用量は、短期間に急激に増加します。

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

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

    • バージョン<v3.0.0の場合、メモリクォータを超えるSQLクエリを見つけるために、grep「メモリがクォータを超えています」をtidb.logで指定します。

    ノート:

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

  • 3.2.3OOMの問題を軽減する

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

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

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

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

3.3間違った実行計画

  • 3.3.1症状

    • SQLクエリの実行時間は、以前の実行に比べてはるかに長いか、実行プランが突然変更されます。実行プランが低速ログに記録されている場合は、実行プランを直接比較できます。

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

    • 遅いログでは、SQL実行時間Scan Keysの数が多くなります。

  • 3.3.2実行計画を調査する

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

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

  • 3.3.3緩和

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

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

    • その他の状況では、 バグを報告

3.4SQL実行エラー

  • 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を取り上げます。精度が最大で30であるため、TiDBとMySQLの結果は両方とも0です。ただし、TiDBでは、10進精度のフィールドは31のままです。

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

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

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

4.TiKVの問題

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

  • 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 sizenetwork outboundトラフィックを超えているかどうかを確認できます

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

    この問題は予期しないものです。あなたはバグを報告することができます。

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

モニターのGrafana- > TiKV- >エラーを表示して、ビジーの特定の原因を確認します。 server is busyは、TiKVのフロー制御メカニズムによって引き起こされます。これは、 tidb/ti-clientに現在圧力がかかりすぎていることを通知し、後で再試行します。

  • 4.3.1TiKVRocksDBが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-limithard-pending-compaction-bytes-limitを増やすことで、この問題を軽減できます。

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

      • デフォルト値のhard-pending-compaction-bytes-limit256GBです。保留中の圧縮バイトがしきい値に達すると(保留中の圧縮バイトがsoft-pending-compaction-bytes-limitに達した後、RocksDBは書き込みを遅くするため、これは発生しない可能性があります)、RocksDBは書き込み操作を停止します。 hard-pending-compaction-bytes-limitから512GBまで設定できます。

      • ディスクI/O容量が長時間書き込みに追いつかない場合は、ディスクをスケールアップすることをお勧めします。ディスクスループットが上限に達し、書き込みストールが発生する場合(たとえば、SATASSDがNVMESSDよりもはるかに低い場合)、CPUリソースは十分ですが、より高い圧縮率の圧縮アルゴリズムを適用できます。このようにして、CPUリソースがディスクリソースと交換され、ディスクへの負荷が軽減されます。

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

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

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

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

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

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

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

  • 4.4.1TiKVが再起動されたための再選

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

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

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

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

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

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

4.5TiKVの書き込みが遅い

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

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

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

    その他の状況では、 バグを報告

  • 4.5.3追加ログが遅い。

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

    その他の状況では、 バグを報告

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

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

    • [raftstore] store-pool-size構成値が小さすぎないか確認してください。値は1の範囲で、大きすぎないように設定することをお勧めし5
    • 本機のCPUリソースが不足していないか確認してください。
  • 4.5.5適用が遅い。

    TiKVGrafanaのRaft / apply log durationは高く、通常は高いRaft Propose / apply wait durationが付属しています。考えられる原因は次のとおりです。

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

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

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

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

    • その他の状況では、 バグを報告

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

    TiKVGrafanaのRaft / 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.1PDスケジューリング

  • 5.1.1マージ

    • テーブル全体の空のリージョンはマージできません。 TiKVの[coprocessor] split-region-on-tableパラメーターを変更する必要があります。これは、v4.xではデフォルトでfalseに設定されています。中国語のケース-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]パラメータが導入されました。これにより、Leaderのスケジューリングポリシーをcountベースまたはsizeベースに設定できます。

5.2PD選挙

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

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

    • 原因2:ネットワーク。 PDログにはlost the TCP streaming connectionが表示されます。 PDノード間のネットワークに問題があるかどうかを確認し、モニターGrafana- > PD- > etcdround 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-storagetrueに設定すると、v3.0でregion storage機能を有効にできます。これにより、リージョンの読み込み時間が大幅に短縮されます。中国語のケース-429を参照してください。

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

    • PDにリーダーがないか、リーダーを切り替えます。 5.2.15.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バグを報告を実行してゴルーチンを取得します。

  • 5.2.4その他の問題

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

    • その他の状況では、 バグを報告

5.3PDルーム

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

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

5.4Grafanaディスプレイ

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

6.エコシステムツール

6.1TiDBBinlog

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

  • 6.1.2Pump/DrainerステータスのUpdate Timeは正常に更新され、ログに異常は表示されませんが、ダウンストリームにデータは書き込まれません。

    • BinlogはTiDB構成で有効になっていません。 TiDBの[binlog]の構成を変更します。
  • DrainerのsaramaEOFエラーを報告します。

    • DrainerのKafkaクライアントバージョンがKafkaのバージョンと矛盾しています。 [syncer.to] kafka-versionの構成を変更する必要があります。
  • 6.1.4 DrainerはKafkaへの書き込みに失敗してパニックになり、KafkaはMessage was too largeのエラーを報告します。

    • binlogデータが大きすぎるため、Kafkaに書き込まれる単一のメッセージが大きすぎます。 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では、タイムスタンプのデフォルト値は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を再起動します。ケース通知に失敗するすべての生きている水切りを参照してください。

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

    • トリガー:アップストリームは、 DROP COLUMNのDDLを実行しながら、このテーブルに対してDML操作を実行します。この問題はv3.0.6で修正されています。中国語のケース-820を参照してください。
  • Drainerドレイナーレプリケーションがハングしています。プロセスはアクティブなままですが、チェックポイントは更新されません。

    • この問題はv3.0.4で修正されています。中国語のケース-741を参照してください。
  • 6.1.11コンポーネントがパニックになります。

6.2データ移行

  • 6.2.1 TiDBデータ移行(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-worker/DM-master / dmctlをDMクラスタにデプロイするには、中国語の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などのbinlogの取得または解析に失敗するエラーでレプリケーションタスクが中断されます

    • 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.7DMレプリケーションプロセスはエラーError 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)を返します。

    • この値はMySQL8.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 %を手動で設定する必要があります。
      • CPUにクォータがある場合(たとえば、Kubernetes設定によって制限されている場合)、 TiDB Lightningはこれを読み取れない可能性があります。この場合、 region-concurrencyも手動で減らす必要があります。
    • インデックスを追加するたびに、行ごとに新しいKVペアが導入されます。 N個のインデックスがある場合、インポートされる実際のサイズは、 Mydumperの出力のサイズの約(N + 1)倍になります。インデックスが無視できる場合は、最初にスキーマからインデックスを削除し、インポートの完了後にCREATE INDEXを介してインデックスを追加し直すことができます。

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

  • checksum failed: checksum mismatched remote vs local

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

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

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

      • AUTO_INCREMENT列は正である必要があり、値「0」は含まれません。
      • UNIQUEキーとPRIMARYKEYには、重複するエントリがあってはなりません。
    • 解決策: トラブルシューティングソリューションを参照してください。

  • 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

  • GC life time is shorter than transaction duration

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

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

  • txn takes too much time

    このエラーは、長期間(590秒以上)コミットされていないトランザクションをコミットした場合に返されます。

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

  • 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にログインします。

  • distsql.goレポートinconsistent index

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

    SET GLOBAL tidb_gc_enable = 0;
    

7.2 TiKV

  • key is locked

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

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

  • write conflict

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

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

  • TxnLockNotFound

    このトランザクションのコミットは遅すぎます。これは、TTL後に他のトランザクションによってロールバックされます(デフォルトでは、小さなトランザクションの場合は3秒)。このトランザクションは自動的に再試行されるため、通常、ビジネスに影響はありません。

  • PessimisticLockNotFound

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

  • stale_epoch

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

  • 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を参照してください。