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-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を参照してください。
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 ジョブがハングするか実行が遅い (
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
- TiDBサーバーに接続できる場合は、所有者選出コマンドを
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.loggrep します。fatal error: runtime: out of memoryまたはcannot allocate memoryintidb_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 "メモリ exceeded quota" を実行して、メモリクォータを超えている SQL クエリを見つけます。
ノート：
単一の SQLメモリ使用量のデフォルトのしきい値は
1GBです。このパラメータは、システム変数tidb_mem_quota_queryを構成することで設定できます。3.2.3 OOM の問題を軽減する
SWAPを有効にすることで、大規模なクエリによるメモリの過剰使用によって引き起こされる OOM の問題を軽減できます。メモリが不足している場合、この方法は I/O オーバーヘッドのために大規模なクエリのパフォーマンスに影響を与える可能性があります。パフォーマンスへの影響の程度は、残りのメモリ容量とディスク I/O 速度によって異なります。
3.2.4 OOM の典型的な理由
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はターゲット精度です。
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-details -> coprocessor overviewを表示して、
response sizenetwork 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) を設定します。これにより、メモリ内のメモリが増える可能性があるため、ピーク時のメモリ使用量が増える可能性があることに注意してください。
- たとえば、
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状態はサービスに影響はありませんが、エラーが長時間続く場合は、Leaderの切り替えが発生する可能性があります。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を参照してください。
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 durationscheduler 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 レプリカの追加またはレプリカのオンライン/オフライン化
5.1.3 バランス
5.2 PD の選出
5.2.1 PD スイッチLeader。
原因 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 が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などの秒単位の場合、リージョンの読み込みが遅いことを意味します。use-region-storageをtrueに設定することで v3.0 のregion storage機能を有効にできます。これにより、リージョンの読み込み時間が大幅に短縮されます。中国語でケース-429参照してください。
5.2.3 TiDB が SQL ステートメントを実行すると PD がタイムアウトする。
5.2.4 その他の問題
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 TiDBBinlog
6.1.1 TiDB Binlog は、 TiDB から変更を収集し、ダウンストリームの TiDB または MySQL プラットフォームにバックアップとレプリケーションを提供するツールです。詳細については、 GitHub の TiDB Binlogを参照してください。
6.1.2 Pump/ Drainer Status の
Update Time正常に更新され、ログに異常は表示されませんが、下流にデータが書き込まれません。- Binlog はTiDB 構成で有効になっていません。 TiDB の
[binlog]構成を変更します。
- Binlog はTiDB 構成で有効になっていません。 TiDB の
6.1.3 Drainerの
saramaEOFエラーを報告します。- Drainerの Kafka クライアントのバージョンは、Kafka のバージョンと矛盾しています。
[syncer.to] kafka-version構成を変更する必要があります。
- Drainerの Kafka クライアントのバージョンは、Kafka のバージョンと矛盾しています。
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 遅い複製
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 COLUMNDDL を実行しながら、このテーブルで 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のケーススタディを参照してください。
- すべての DM 構成ファイル内のデータベース関連のパスワードは
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を参照してください。
- DM 1.0.0 GA より前のバージョンの場合、
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 returnedDM がリレー ログまたは増分レプリケーションをプルするプロセス中に、上流の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パラメータを有効にすると、データ形式のチェックをスキップできます。
- この値は、MySQL 8.0 または TiDB に正常に書き込むことはできませんが、 MySQL 5.7には書き込むことができます。
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 秒です。詳細については、
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を参照してください。