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.2と5.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 / raft storeCPUおよび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
- TiDBサーバーに接続できる場合は、所有者選択コマンドを再度実行します
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を超えます。解決策：最初の2つの原因は、関連するDML操作が失敗後に再試行されるため、アプリケーションに影響を与えません。原因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がビジーである理由を調査してください。 4TiKVの問題を参照してください。
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 memorytidb_stderr.logcannot allocate memory。v2.1.8以前のバージョンでは、
tidb_stderr.logのfatal error: stack overflowをgrepできます。
モニター：tidb-serverインスタンスのメモリー使用量が短時間で急激に増加します。
3.2.2OOMの原因となるSQLステートメントを見つけます。 （現在、TiDBのすべてのバージョンがSQLを正確に見つけることができません。それでも、OOMがSQLステートメントによって引き起こされているかどうかを分析する必要があります。）
バージョン>=v3.0.0の場合、
tidb.logのgrep「expensive_query」。そのログメッセージは、タイムアウトした、またはメモリクォータを超えたSQLクエリを記録します。バージョン<v3.0.0の場合、grepは
tidb.logで「メモリがクォータを超えています」と入力して、メモリクォータを超えるSQLクエリを検索します。
ノート：
単一のSQLメモリ使用量のデフォルトのしきい値は
1GBです（バイト単位、スコープ：SESSION）。このパラメーターは、tidb_mem_quota_queryを構成することで設定できます。構成アイテムをホットロードすることにより、構成ファイル内のmem-quota-queryのアイテム（バイト単位）を変更することもできます。3.2.3OOMの問題を軽減する
SWAPを有効にすることで、大規模なクエリによるメモリの過剰使用によって引き起こされるOOMの問題を軽減できます。メモリが不足している場合、この方法はI / Oオーバーヘッドのために、大規模なクエリのパフォーマンスに影響を与える可能性があります。パフォーマンスへの影響の程度は、残りのメモリスペースとディスクI/O速度によって異なります。
3.2.4OOMの一般的な理由
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.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では、小数精度のフィールドは31のままです。複数の
Decimal除算の後、結果が正しい場合でも、この精度フィールドはますます大きくなり、最終的にTiDBのしきい値（72）を超え、Data Truncatedエラーが報告されます。Decimalの乗算では、範囲外がバイパスされ、精度が最大精度制限に設定されるため、この問題は発生しません。解決策：
Cast(xx as decimal(a, b))を手動で追加することで、この問題を回避できます。ここで、aとbがターゲットの精度です。
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- >コプロセッサーの概要を表示して、
response sizeがnetwork 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-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容量が長時間書き込みに追いつかない場合は、ディスクをスケールアップすることをお勧めします。ディスクスループットが上限に達し、書き込みストールが発生する場合（たとえば、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-numberを8に設定します（デフォルトでは5）。これにより、メモリ内のメモリテーブルが増える可能性があるため、ピーク時のメモリ使用量が増える可能性があることに注意してください。
- たとえば、
scheduler too busy深刻な書き込みの競合。
latch wait durationは高いです。モニターでlatch wait durationを表示できますGrafana- > TiKV-詳細->スケジューラープリライト/スケジューラーコミット。書き込みタスクがスケジューラーに積み重なると、保留中の書き込みタスクが[storage] scheduler-pending-write-thresholdで設定されたしきい値（100MB）を超えます。MVCC_CONFLICT_COUNTERに対応するメトリックを表示することにより、原因を確認できます。書き込みが遅いと、書き込みタスクが山積みになります。 TiKVに書き込まれるデータが、
[storage] scheduler-pending-write-thresholdで設定されたしきい値（100MB）を超えています。 4.5を参照してください。
raftstore is busy。メッセージの処理は、メッセージの受信よりも遅くなります。短期channel fullステータスはサービスに影響しませんが、エラーが長期間続く場合は、リーダーの切り替えが発生する可能性があります。4.3.4TiKVコプロセッサーがキューに入っています。積み上げられたタスクの数が
coprocessor threads * readpool.coprocessor.max-tasks-per-worker-[normal|low|high]を超えています。大きなクエリが多すぎると、コプロセッサにタスクが積み重なってしまいます。実行プランの変更により、多数のテーブルスキャン操作が発生するかどうかを確認する必要があります。 3.3を参照してください。
4.4一部のTiKVノードはリーダーを頻繁にドロップします
4.4.1TiKVが再起動されたための再選
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書き込みが少ないかどうかを確認します（生のKVクラスターの場合のみ）。一般的に、 パフォーマンスマップに従って遅いフェーズを見つけることができます。いくつかの一般的な状況を以下に示します。4.5.2スケジューラCPUがビジーです（トランザクションkvの場合のみ）。
prewrite / commitの
scheduler command durationは、scheduler latch wait durationとstorage async write durationの合計よりも長くなります。スケジューラワーカーは、scheduler-worker-pool-size* 100％の80％を超えるなど、CPUの需要が高いか、マシン全体のCPUリソースが比較的制限されています。書き込みワークロードが大きい場合は、[storage] scheduler-worker-pool-sizeの設定が小さすぎるかどうかを確認してください。その他の状況では、 バグを報告 。
4.5.3追加ログが遅い。
TiKVGrafanaのRaftIO /
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のRaftIO /
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のRaftIO /
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レプリカを追加するか、レプリカをオンライン/オフラインで取得します
5.1.3バランス
5.2PD選挙
5.2.1PDスイッチリーダー。
原因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がリーダーを選出できないか、選出が遅い。
PDはリーダーを選出できません：PDログには
lease is not expiredが表示されます。 この問題はv3.0.xおよびv2.1.19で修正されています。中国語のケース-875を参照してください。選挙は遅い：地域の読み込み期間は長い。この問題は、PDログで
grep "regions cost"を実行することで確認できます。結果がload 460927 regions cost 11.77099s秒などの秒単位の場合は、リージョンの読み込みが遅いことを意味します。use-region-storageをtrueに設定すると、v3.0でregion storage機能を有効にできます。これにより、リージョンの読み込み時間が大幅に短縮されます。中国語のケース-429を参照してください。
5.2.3TiDBがSQLステートメントを実行するとPDがタイムアウトしました。
5.2.4その他の問題
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.1TiDBビンログ
6.1.1 TiDB Binlogは、TiDBから変更を収集し、ダウンストリームのTiDBまたはMySQLプラットフォームへのバックアップとレプリケーションを提供するツールです。詳細については、 GitHubのTiDBBinlogを参照してください。
6.1.2ポンプ/ドレイナーステータスの
Update Timeは正常に更新され、ログに異常は表示されませんが、ダウンストリームにデータは書き込まれません。- BinlogはTiDB構成で有効になっていません。 TiDBで
[binlog]の構成を変更します。
- BinlogはTiDB構成で有効になっていません。 TiDBで
6.1.3Drainerの
saramaはEOFエラーを報告します。- DrainerのKafkaクライアントバージョンは、Kafkaのバージョンと矛盾しています。
[syncer.to] kafka-versionの構成を変更する必要があります。
- DrainerのKafkaクライアントバージョンは、Kafkaのバージョンと矛盾しています。
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遅いレプリケーション
6.1.7 Pumpはbinlogを書き込めず、
no space left on deviceエラーを報告します。- ローカルディスク容量は、Pumpがbinlogデータを正常に書き込むには不十分です。ディスクスペースをクリーンアップしてから、Pumpを再起動する必要があります。
6.1.8ポンプは、起動時に
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.10ドレイナーレプリケーションがハングしています。プロセスはアクティブなままですが、チェックポイントは更新されません。
- この問題は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のケーススタディを参照してください。
- すべての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 *を報告するか、レプリケーションタスクが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の位置がオーバーフローすると、上記のエラーが発生します。
解決：
- リレー処理装置の場合、 レプリケーションを手動で回復する 。
- 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情報を取得しない場合、DM-workerは空の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に正常に書き込むことはできませんが、MySQL5.7に書き込むことはできます。
tidb_skip_utf8_checkパラメータを有効にすると、データ形式のチェックをスキップできます。
- この値はMySQL8.0またはTiDBに正常に書き込むことはできませんが、MySQL5.7に書き込むことはできます。
6.3TiDBライトニング
6.3.1 TiDB Lightningは、大量のデータをTiDBクラスタに高速に完全にインポートするためのツールです。 GitHub上のTiDBLightningを参照してください。
6.3.2インポート速度が遅すぎます。
region-concurrencyの設定が高すぎると、スレッドの競合が発生し、パフォーマンスが低下します。トラブルシューティングの3つの方法：- 設定は、ログの先頭から
region-concurrencyを検索して見つけることができます。 - TiDB Lightningがサーバーを他のサービス（Importerなど）と共有する場合は、そのサーバー上のCPUコアの総数の
region-concurrency％を手動で設定する必要があります。 - CPUにクォータがある場合（たとえば、Kubernetes設定によって制限されている場合）、TiDBLightningはこれを読み取れない可能性があります。この場合、
region-concurrencyも手動で減らす必要があります。
- 設定は、ログの先頭から
インデックスを追加するたびに、行ごとに新しいKVペアが導入されます。 N個のインデックスがある場合、インポートされる実際のサイズは、 Mydumperの出力のサイズの約（N + 1）倍になります。インデックスが無視できる場合は、最初にスキーマからインデックスを削除し、インポートの完了後に
CREATE INDEXを介してインデックスを追加し直すことができます。TiDBLightningのバージョンは古いです。最新バージョンを試してください。インポート速度が向上する可能性があります。
checksum failed: checksum mismatched remote vs local。原因1：テーブルにすでにデータが含まれている可能性があります。これらの古いデータは、最終的なチェックサムに影響を与える可能性があります。
原因2：ターゲット・データベースのチェックサムが0の場合、つまり何もインポートされていない場合は、クラスタが過熱しており、データの取り込みに失敗している可能性があります。
原因3：データソースがマシンによって生成され、 Mydumperによってバックアップされていない場合は、テーブルの制約を尊重していることを確認してください。例えば：
AUTO_INCREMENT列は正である必要があり、値「0」は含まれません。- UNIQUEキーとPRIMARYキーには、重複するエントリがあってはなりません。
解決策： トラブルシューティングソリューションを参照してください。
6.3.4
Checkpoint for … has invalid status:(error code)原因：チェックポイントが有効になっていて、Lightning/Importerが以前に異常終了しました。偶発的なデータ破損を防ぐために、エラーが解決されるまでTiDBLightningは起動しません。エラーコードは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を参照してください。