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 期間中にLeaderが存在しなくなります。中国語のケース-991を参照してください。

• 1.1.3 TiKV はTiKV server is busy報告し、 backoff時間を超えています。詳細については、 4.3を参照してください。 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 実行計画によりレイテンシーが増加します。 3.3を参照してください。
• 2.1.2 PDLeader選挙の問題または OOM。 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メトリックを確認してください)。 v3.x 以降のバージョンでは、 Hibernate Region有効にすることで問題を解決できます。中国語のケース-612を参照してください。

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

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

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

• 2.2.4 TiDB の実行計画が間違っています。 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 は v6.3.0 でメタデータロックを導入し、v6.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 ステートメントを含むトランザクションの実行時間が 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.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 します。

    • Grep fatal error: runtime: out of memoryまたはcannot allocate memory in tidb_stderr.log 。

    • 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 "メモリ がクォータを超えています" を実行して、メモリクォータを超えている 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テーブルが大きいことがわかります。

  • 1 つの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を表すデータ構造内では、小数精度のフィールドが実際の精度を保持します。

    (0.1^30) / 10例に挙げます。 TiDB と MySQL の結果は両方とも0です。これは、精度が最大30であるためです。ただし、TiDB では、10 進精度のフィールドは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が返されます。

  この問題は予想されています。 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 詳細->コプロセッサー概要を表示して、 response size network outboundトラフィックを超えているかどうかを確認できます。

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

  この問題は予期せぬものです。 バグを報告を行うことができます。

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

モニターGrafana -> TiKV ->エラーを表示して、ビジーの具体的な原因を確認します。 server is busyは、TiKV のフロー制御メカニズムによって発生し、TiKV が現在過剰な圧力を受けているため、後で再試行することをtidb/ti-clientに通知します。

• 4.3.1 TiKV RocksDB との遭遇write stall 。

  TiKV インスタンスには 2 つの RocksDB インスタンスがあり、 data/raftつはRaftログを保存するため、もう 1 つは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 容量が長時間書き込みに追いつかない場合は、ディスクをスケールアップすることをお勧めします。 CPU リソースが十分であるにもかかわらず、ディスク スループットが上限に達して書き込み停止が発生する場合 (たとえば、SATA SSD が NVME SSD よりも大幅に低い場合)、より高い圧縮率の圧縮アルゴリズムを適用することができます。このようにして、CPU リソースがディスク リソースと交換され、ディスクへの負荷が軽減されます。

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

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

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

• 4.3.2 scheduler too busy

  • 深刻な書き込み競合。 latch wait duration高いですね。 latch wait durationは、モニターGrafana -> TiKV-details ->スケジューラー事前書き込み/スケジューラーコミットで表示できます。スケジューラに書き込みタスクが溜まると、保留中の書き込みタスクが[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ステータスはサービスに影響しませんが、エラーが長期間続く場合は、Leaderスイッチが発生する可能性があります。

  • 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 ノードがLeaderを頻繁にドロップする

• 4.4.1 TiKV 再開による再選

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

  • TiKV はサードパーティによって停止または強制終了され、systemd によって引き上げられます。 dmesgおよびTiKVログを参照して原因を確認してください。

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

  • TiKV は、 THP (透明な巨大ページ) を動的に調整するためにハングします。中国語のケースケース-500を参照してください。

• 4.4.2 TiKV RocksDB で書き込みストールが発生し、再選択が発生します。モニターGrafana -> TiKV-details ->エラーに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の値を設定することをお勧めします)。Thread CPU / apply CPUは大きすぎます。

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

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

  • RocksDB の書き込みが遅い。 RocksDB kv / max write durationは高いです。単一の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 マージ

  • テーブル間の空の領域をマージすることはできません。 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 バランス

  • Leader/リージョンの数は均等に分散されていません。中国語のケース-394とケース-759を参照してください。主な原因は、天びんがリージョン/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表示されます。 この問題 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を切り替えます。 5.2.1と5.2.2を参照してください。

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

  • 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 InSegs が比較的大きいことが示されています。この問題は v3.0.6 ( #1952 ) で修正されました。

5.4 グラファナ表示

• 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 sarama in Drainer はEOFエラーを報告します。

  • 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を再起動します。ケースすべての生きている排水者への通知に失敗するを参照してください。

• 6.1.9 Drainer は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 *を報告するか、レプリケーション タスクがbinlogの取得または解析に失敗するエラー ( 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の位置がオーバーフローし、上記のエラーが発生することを意味します。

  • 解決：

    • 中継処理ユニットの場合、 レプリケーションを手動で回復する ．
    • 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 個のインデックスがある場合、インポートされる実際のサイズは、 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 キーと 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}'

  • 原因: タイムスタンプ タイプのエントリに存在しない時刻値が含まれています。これは、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 秒です。詳細については、 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 以降のバージョンでは、以前のLeaderへのリクエストが失敗した場合、TiDB は他のピアを試行し、TiKV ログにpeer is not leader頻繁に記録される可能性があります。 TiDB の対応するリージョンのswitch region peer to next due to send request failを確認して、送信失敗の根本原因を特定できます。詳細は7.1.4を参照してください。

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