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

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

1. サービスは利用できません

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

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

• 1.1.2 複数のTiKVインスタンスが同時にOOM状態になり、OOM期間中にLeaderが存在しない状態になります。中国語版のケース991ご覧ください。

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

• 1.1.4 複数の TiKV インスタンスの起動に失敗し、リージョンにLeaderが存在しない状態になります。物理マシンに複数の TiKV インスタンスがデプロイされている場合、ラベルが適切に設定されていないと、物理マシンの障害によってリージョンにLeaderが存在しない状態になる可能性があります。中国語版のケース228参照してください。

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

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

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

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

2.1 一時的な増加

• 2.1.1 TiDB実行プランが間違っているとレイテンシーが増加します。1を参照してください3.3
• 2.1.2 PDLeader選挙問題またはOOM。1と5.2 5.3参照してください。
• 2.1.3 一部のTiKVインスタンスでLeaderの離脱が多数発生しています4.4を参照してください。
• 2.1.4 その他の原因については、 読み取りおよび書き込みレイテンシの増加のトラブルシューティング参照してください。

2.2 持続的かつ顕著な増加

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

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

  • v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( 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の実行プランが間違っています。1を参照してください3.3

• 2.2.5 その他の原因については、 読み取りおよび書き込みレイテンシの増加のトラブルシューティング参照してください。

3. TiDBの問題

3.1 DDL

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

• 3.1.2 TiDB DDLジョブがハングしたり実行速度が遅くなる（DDLの進行状況を確認するにはadmin show ddl jobs使用）

  • 原因1: TiDBはバージョン6.3.0でメタデータロックを導入し、バージョン6.5.0以降ではデフォルトで有効になっています。DDL操作に関係するテーブルが、コミットされていないトランザクションに関係するテーブルと交差している場合、トランザクションがコミットまたはロールバックされるまでDDL操作はブロックされます。

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

  • 原因 3: TiDB の初期バージョン (v3.0.8 より前) では、高同時実行での goroutine が多数あるため、内部負荷が高くなります。

  • 原因 4: 以前のバージョン (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文を含むトランザクションの実行時間が1DDLリースを超えています。トランザクションがコミットされるとエラーが報告されます。

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

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

  • 解決：

    • 原因 1 の場合、TiDB の起動時に DML 操作を再試行します。
    • 原因 2 の場合、TiDBサーバーと PD/TiKV 間のネットワークを確認してください。
    • 原因3については、TiKVがビジー状態になっている理由を調べてください。1を参照してください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 が再起動した時点）の「Welcome to TiDB」ログtidb.logを grep します。

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

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

  • モニター: tidb-server インスタンスのメモリ使用量が短期間で急増します。

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

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

  • バージョン < v3.0.0 の場合、 tidb.logで grep "メモリ exceeds quota" を実行して、メモリクォータを超える SQL クエリを見つけます。

  注記：

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

• 3.2.3 OOMの問題を軽減する

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

• 3.2.4 OOMの典型的な理由

  • SQLクエリにはjoinあります。3 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除算し、結果が最大小数点精度（ 30 ）を超える場合、 30桁のみが予約され、エラーは報告されません。

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

    (0.1^30) / 10例に挙げましょう。TiDB と MySQL ではどちらも0なります。これは、精度が最大30であるためです。しかし、TiDB では小数点精度のフィールドは依然として31です。

    Decimal除算を複数回実行すると、結果が正しいにもかかわらず、この精度フィールドがどんどん大きくなり、最終的にTiDB（ 72 ）のしきい値を超え、 Data Truncatedエラーが報告されます。

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

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

3.5 クエリの遅延の問題

遅いクエリを特定するには遅いクエリを特定する参照してください。遅いクエリを分析して処理するには遅いクエリを分析する参照してください。

3.6 ホットスポットの問題

分散データベースであるTiDBは、アプリケーションの負荷を異なるコンピューティングノードまたはstorageノードに可能な限り均等に分散し、サーバーリソースをより有効に活用する負荷分散メカニズムを備えています。しかし、特定のシナリオでは、一部のアプリケーションの負荷が適切に分散されず、パフォーマンスに影響を与え、ホットスポットと呼ばれる高負荷の単一ポイントが形成される可能性があります。

TiDBは、ホットスポットのトラブルシューティング、解決、または回避のための包括的なソリューションを提供します。負荷ホットスポットを分散することで、QPSの向上やレイテンシーの削減など、全体的なパフォーマンスを向上させることができます。詳細なソリューションについては、 ホットスポットの問題のトラブルシューティングご覧ください。

3.7 ディスクI/O使用率が高い

CPUボトルネックとトランザクション競合によるボトルネックのトラブルシューティング後もTiDBの応答速度が低下した場合は、I/Oメトリックをチェックして、現在のシステムボトルネックを特定する必要があります。TiDBにおけるI/O使用率の上昇の問題を特定し、対処する方法については、 ディスクI/O使用率が高い場合のトラブルシューティング参照してください。

3.8 ロックの競合

TiDBは完全な分散トランザクションをサポートします。v3.0以降、TiDBは楽観的トランザクションモードと悲観的トランザクションモードを提供します。ロック関連の問題のトラブルシューティング方法、および楽観的と悲観的ロックの競合の処理方法については、 ロックの競合のトラブルシューティング参照してください。

3.9 データとインデックスの不整合

TiDBは、トランザクションまたはADMIN CHECK [TABLE|INDEX]ステートメントを実行する際に、データとインデックス間の整合性をチェックします。チェックの結果、レコードのキー値と対応するインデックスのキー値に不整合がある場合、つまり、行データを格納するキー値ペアとそのインデックスを格納するキー値ペアに不整合がある場合（たとえば、インデックスが多すぎる、またはインデックスが欠落している）、TiDBはデータ不整合エラーを報告し、関連するエラーをエラーログに出力。

不整合エラーの詳細とチェックをバイパスする方法については、 データとインデックス間の不整合のトラブルシューティング参照してください。

4. TiKVの問題

4.1 TiKVがパニックを起こし起動に失敗する

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

  この問題は想定内です。1 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 他のコンポーネントが大量のメモリを占有します。

  この問題は予期せぬものです。1 バグを報告する実行できます。

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

モニターGrafana -> TiKV -> errorsを表示して、ビジー状態の具体的な原因を確認します。7 server is busy 、TiKV のフロー制御メカニズムによって発生し、TiKV の負荷が現在高すぎるため後で再試行することをtidb/ti-client通知します。

• 4.3.1 TiKV RocksDB の遭遇write stall 。

  TiKV インスタンスには 2 つの RocksDB インスタンスがあり、1 つはRaftログを保存するためにdata/raftに、もう 1 つは実際のデータを保存するためにdata/dbにあります。ログでgrep "Stalling" RocksDB実行すると、ストールの具体的な原因を確認できます。RocksDB ログはLOGで始まるファイルで、 LOG現在のログです。 write stall RocksDB にネイティブに組み込まれているパフォーマンス低下メカニズムです。RocksDB でwrite stall発生すると、システム パフォーマンスが大幅に低下します。v5.2.0 より前のバージョンでは、TiDB はwrite stallに遭遇するとServerIsBusyエラーを直接クライアントに返すことで、すべての書き込み要求をブロックしようとしていましたが、これにより QPS パフォーマンスが急激に低下する可能性がありました。v5.2.0 以降、TiKV は、 write stallが発生したときにserver is busyクライアントに返す以前のメカニズムに代わる、スケジューリングレイヤーで書き込み要求を動的に遅らせることで書き込みを抑制する新しいフロー制御メカニズムを導入しています。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKVはKvDBとRaftDB （memtableを除く）に対してwrite stallメカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、クライアントにserver is busyエラーを返します。詳細な説明としきい値については、 フロー制御設定参照してください。

  • 保留中の圧縮バイトが多すぎるためにserver is busyエラーが発生した場合は、 soft-pending-compaction-bytes-limitおよびhard-pending-compaction-bytes-limitパラメータの値を増やすことでこの問題を軽減できます。

    • 保留中の圧縮バイト数がパラメータsoft-pending-compaction-bytes-limit （デフォルトでは192GiB ）に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます（クライアントにServerIsBusy返します）。この場合、このパラメータの値を[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"など、増やすことができます。

    • 保留中の圧縮バイト数がパラメータhard-pending-compaction-bytes-limit （デフォルトは1024GiB ）に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます（クライアントにServerIsBusy返します）。このシナリオは、しきい値soft-pending-compaction-bytes-limitに達するとフロー制御メカニズムが介入して書き込み速度を低下させるため、発生する可能性は低くなります。このようなシナリオが発生した場合は、このパラメータの値を[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"に増やすことができます。

    • ディスク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"]に変更します。

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

    • 例えば、 [rocksdb.defaultcf] max-write-buffer-numberを8 （デフォルトは5 ）に設定します。この場合、メモリ内のメモリテーブルが増えるため、ピーク時のメモリ使用量が増加する可能性があることに注意してください。

• 4.3.2 scheduler too busy

  • 深刻な書き込み競合が発生しています。1 latch wait duration高い値です。モニター「Grafana」 → 「TiKV詳細」 → 「scheduler prewrite / Scheduler commit」でlatch wait duration確認できます。スケジューラに書き込みタスクが蓄積されると、保留中の書き込みタスクが[storage] scheduler-pending-write-thresholdで設定した閾値（100MB）を超えますMVCC_CONFLICT_COUNTERに対応するメトリックを確認することで、原因を確認できます。

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

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

  • エンカウンター数append log 4.3.1参照。
  • append log durationが高いため、メッセージの処理が遅くなります。4 append log duration高い理由を分析するには、 4.5を参照してください。
  • raftstore は大量のメッセージを瞬時に受信し（TiKV Raftメッセージダッシュボードで確認できます）、処理に失敗します。通常、短期的なステータスchannel fullサービスに影響を与えません。

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

4.4 一部のTiKVノードが頻繁にLeaderをドロップする

• 4.4.1 TiKVの再開による再選挙

  • TiKVがパニック状態になった後、systemdによって引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合はバグを報告する 。

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

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

  • TiKVは、動的調整THP （Transparent Hugepage）が原因でハングアップしています。中国語のケースケース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 の場合のみ)。

  プレライト/コミットの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が小さすぎないか確認してください。3～ 1 5間で、大きすぎない値を設定することを推奨します。
  • マシン上の CPU リソースが不足していないかどうかを確認します。

• 4.5.5 適用が遅い。

  TiKV Grafana のRaft IO / apply log duration値が高くなっています。これは通常、 Raft Propose / apply wait duration値も高いことを意味します。考えられる原因は以下のとおりです。

  • [raftstore] apply-pool-sizeは小さすぎます ( 1から5間で大きすぎない値を設定することを推奨します)、また、 Thread CPU / apply CPUは大きすぎます。

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

  • リージョン書き込みのホットスポット。単一の適用スレッドのCPU使用率が高くなります。現在、単一のリージョンにおけるホットスポット問題を適切に解決できていませんが、改善に向けて取り組んでいます。各スレッドのCPU使用率を確認するには、Grafana式にby (instance, name)追加してください。

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

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

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

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

• 4.5.7 その他の状況については、 パフォーマンスマップの書き込みパスを参照して原因を分析します。

5. PDの問題

5.1 PDスケジュール

• 5.1.1 マージ

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

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

• 5.1.2 レプリカを追加する、またはレプリカをオンライン/オフラインにする

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

  • TiKVノードがオフラインになると、一部のリージョンを他のノードに移行できなくなります。この問題はv3.0.4（ ＃5526 ）で修正されました。中国語版はケース870ご覧ください。

• 5.1.3 バランス

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

5.2 PD選挙

• 5.2.1 PD はLeaderを切り替えます。

  • 原因1：ディスク。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされているかどうか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（ディスクパフォ​​ーマンス、レイテンシー/負荷）を確認することで原因を確認できます。必要に応じて、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 がLeaderを選出できない、または選出が遅い。

  • PDがLeaderを選出できません：PDログにはlease is not expired表示されています。3 この号 v3.0.xおよびv2.1.19で修正されました。中国語版はケース875ご覧ください。

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

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

  • PDにLeaderがいない、またはLeaderが切り替わりました。1と5.2.1 5.2.2参照してください。

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

  • PDはパニックになるバグを報告する 。

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

  • 問題に他の原因がある場合は、 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 InSegsが比較的大きいことが示されています。この問題はv3.0.6（ ＃1952 ）で修正されました。

5.4 Grafanaディスプレイ

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

6. エコシステムツール

6.1 TiDBBinlog

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

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

  • TiDB設定でBinlogが有効になっていません。TiDBの[binlog]設定を変更してください。

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

  • Drainerの Kafka クライアントのバージョンが Kafka のバージョンと一致していません。1 [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ではtimestampのデフォルト値はnullですが、 MySQL 5.7 （MySQL 8を除く）では同じデフォルト値が現在時刻です。そのため、上流のTiDBのtimestampがnullで、下流がMySQL 5.7の場合、timestamp列のデータが不整合になります。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.9Drainerはgen update sqls failed: table xxx: row data is corruption []エラーを報告します。

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

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

  • この問題はv3.0.4で修正されました。中国語版はケース741ご覧ください。

• 6.1.11 いずれかのコンポーネントがパニックになります。

  • バグを報告する 。

6.2 データ移行

• 6.2.1 TiDB Data Migration (DM) は、MySQL/MariaDB から TiDB へのデータ移行をサポートする移行ツールです。詳細については、 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などのbinlogの取得または解析に失敗するエラーで中断されます。

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

  • 原因：リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式MySQLはbinlogの位置をuint32で保存するため、4GBを超えるbinlogファイルの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には書き込めます。1パラメータtidb_skip_utf8_check有効にすると、データ形式のチェックをスキップできます。

6.3 TiDB Lightning

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

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

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

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

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

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

• 6.3.3 checksum failed: checksum mismatched remote vs local .

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

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

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

    • AUTO_INCREMENT列は正の値である必要があり、値「0」は含まれません。
    • UNIQUE KEY と 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 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.6 [sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'

  • 原因: タイムスタンプ型のエントリに存在しない時刻値が含まれています。これは、夏時間の変更、または時刻値がサポート範囲（1970年1月1日から2038年1月19日）を超えていることが原因です。

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

7. 共通ログ分析

7.1 TiDB

• 7.1.1 GC life time is shorter than transaction duration .

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

  GCの有効期間を延ばすには、システム変数tidb_gc_life_time変更します。ただし、このパラメータを変更すると、トランザクションに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.25MB以下のトランザクションの場合、デフォルトのTTLは3秒です。詳細については、 LockNotFoundエラーご覧ください。

• 7.2.4 PessimisticLockNotFound .

  TxnLockNotFoundと同様です。悲観的トランザクションのコミットが遅すぎるため、他のトランザクションによってロールバックされます。

• 7.2.5 stale_epoch .

  リクエストのエポックが古いため、TiDBはルーティングを更新した後、リクエストを再送信します。業務への影響はありません。エポックは、リージョンで分割/結合操作が行われた場合、またはレプリカが移行された場合に変更されます。

• 7.2.6 peer is not leader .

  リクエストはLeaderではないレプリカに送信されました。エラー応答でどのレプリカが最新のLeaderであるかが示されている場合、TiDB はエラーに応じてローカルルーティングを更新し、最新のLeaderに新しいリクエストを送信します。通常、業務に影響はありません。

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

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