TiFlashクラスタのトラブルシューティング

このセクションでは、TiFlash の使用時によく発生する問題、その理由、および解決策について説明します。

TiFlash が起動しない

この問題は、さまざまな理由で発生する可能性があります。以下の手順に従ってトラブルシューティングを行うことをお勧めします。

1. システムが CentOS8 であるかどうかを確認します。

   CentOS8 にはlibnsl.soのシステム ライブラリがありません。次のコマンドを使用して手動でインストールできます。

   dnf install libnsl
   

2. システムのulimitパラメータ設定を確認してください。

   ulimit -n 1000000
   

3. PD Controlツールを使用して、ノード (同じ IP とポート) でオフラインにできなかった TiFlash インスタンスがあるかどうかを確認し、インスタンスを強制的にオフラインにします。詳細な手順については、 スケールインクラスターのスケーリングを参照してください。

上記の方法で問題を解決できない場合は、TiFlash ログ ファイルを保存し、詳細についてinfo@pingcap.comに電子メールを送信してください。

TiFlash レプリカは常に利用できません

これは、設定エラーまたは環境の問題によって、TiFlash が異常な状態にあるためです。次の手順を実行して、障害のあるコンポーネントを特定します。

1. PD がPlacement Rulesつの機能を有効にするかどうかを確認します。

   echo 'config show replication' | /path/to/pd-ctl -u http://${pd-ip}:${pd-port}
   

   • trueが返された場合は、次のステップに進みます。
   • falseが返された場合は、 配置ルール機能を有効にするを返し、次のステップに進みます。

2. TiFlash-Summary 監視パネルでUpTimeを表示して、TiFlash プロセスが正しく機能しているかどうかを確認します。

3. pd-ctlで TiFlash プロキシの状態が正常かどうかを確認します。

   echo "store" | /path/to/pd-ctl -u http://${pd-ip}:${pd-port}
   

   TiFlash プロキシのstore.labelsには、 {"key": "engine", "value": "tiflash"}などの情報が含まれます。この情報を確認して、TiFlash プロキシを確認できます。

4. pd buddyがログを正しく出力できるかどうかを確認します (ログ パスは、[flash.flash_cluster] 構成アイテムのlogの値です。デフォルトのログ パスは、TiFlash 構成ファイルで構成されたtmpディレクトリの下にあります)。

5. 構成されたレプリカの数が、クラスター内の TiKV ノードの数以下であるかどうかを確認します。そうでない場合、PD はデータを TiFlash に複製できません。

   echo 'config placement-rules show' | /path/to/pd-ctl -u http://${pd-ip}:${pd-port}
   

   default: countの値を再確認します。

   ノート：

   配置ルールの機能が有効になると、以前に構成されたmax-replicasとlocation-labelsは無効になります。レプリカ ポリシーを調整するには、配置ルールに関連するインターフェイスを使用します。

6. マシンの残りのディスク容量 (TiFlash ノードのstoreがある場所) が十分かどうかを確認します。デフォルトでは、残りのディスク容量がstoreの容量の 20% 未満の場合 (これはlow-space-ratioパラメーターによって制御されます)、PD はこの TiFlash ノードにデータをスケジュールできません。

TiFlash のクエリ時間が不安定で、エラー ログに多くのLock Exceptionメッセージが出力される

これは、クラスターに大量のデータが書き込まれ、TiFlash クエリでロックが発生し、クエリの再試行が必要になるためです。

TiDB では、クエリのタイムスタンプを 1 秒前に設定できます。たとえば、現在の時刻が「2020-04-08 20:15:01」の場合、クエリを実行する前にset @@tidb_snapshot='2020-04-08 20:15:00';を実行できます。これにより、TiFlash クエリがロックに遭遇することが少なくなり、不安定なクエリ時間のリスクが軽減されます。

一部のクエリがRegion Unavailableエラーを返す

TiFlash の負荷が重すぎて、TiFlash データのレプリケーションが遅れる原因となる場合、一部のクエリでRegion Unavailableエラーが返されることがあります。

この場合、TiFlash ノードを追加することで負荷のバランスを取ることができます。

データファイルの破損

データ ファイルの破損を処理するには、次の手順を実行します。

1. 対応する TiFlash ノードを停止するには、 TiFlash ノードをダウンさせるを参照してください。
2. TiFlash ノードの関連データを削除します。
3. クラスターに TiFlash ノードを再デプロイします。

TiFlash 解析が遅い

MPP モードでサポートされていない演算子または関数がステートメントに含まれている場合、TiDB は MPP モードを選択しません。したがって、ステートメントの分析は遅くなります。この場合、 EXPLAINステートメントを実行して、MPP モードでサポートされていない演算子または関数をチェックできます。

create table t(a datetime);
alter table t set tiflash replica 1;
insert into t values('2022-01-13');
set @@session.tidb_enforce_mpp=1;
explain select count(*) from t where subtime(a, '12:00:00') > '2022-01-01' group by a;
show warnings;

この例では、警告メッセージは、TiDB 5.4 以前のバージョンがsubtime関数をサポートしていないため、TiDB が MPP モードを選択しないことを示しています。

+---------+------+-----------------------------------------------------------------------------+
> | Level   | Code | Message                                                                     |
+---------+------+-----------------------------------------------------------------------------+
| Warning | 1105 | Scalar function 'subtime'(signature: SubDatetimeAndString, return type: datetime) is not supported to push down to tiflash now.       |
+---------+------+-----------------------------------------------------------------------------+

データは TiFlash に複製されません

TiFlash ノードをデプロイし、(ALTER 操作を実行して) レプリケーションを開始した後、それにデータがレプリケートされません。この場合、次の手順に従って問題を特定し、対処できます。

1. ALTER table <tbl_name> set tiflash replica <num>コマンドを実行してレプリケーションが成功したかどうかを確認し、出力を確認します。

   • 出力がある場合は、次のステップに進みます。
   • 出力がない場合は、 SELECT * FROM information_schema.tiflash_replicaコマンドを実行して、TiFlash レプリカが作成されているかどうかを確認します。そうでない場合は、 ALTER table ${tbl_name} set tiflash replica ${num}コマンドを再度実行し、他のステートメント ( add indexなど) が実行されたかどうかを確認するか、DDL の実行が成功したかどうかを確認します。

2. TiFlash プロセスが正しく実行されるかどうかを確認します。

   progress 、 tiflash_cluster_manager.logファイルのflash_region_countパラメーター、および Grafana 監視項目Uptimeに変更がないかどうかを確認します。

   • はいの場合、TiFlash プロセスは正しく実行されます。
   • いいえの場合、TiFlash プロセスは異常です。詳細については、 tiflashログを確認してください。

3. pd-ctl を使用して、 配置ルールの機能が有効になっているかどうかを確認します。

   echo 'config show replication' | /path/to/pd-ctl -u http://<pd-ip>:<pd-port>
   

   • trueが返された場合は、次のステップに進みます。
   • falseが返された場合は、 配置ルール機能を有効にするを返し、次のステップに進みます。

4. max-replicasの構成が正しいかどうかを確認します。

   • max-replicasの値がクラスター内の TiKV ノードの数を超えていない場合は、次の手順に進みます。

   • 値max-replicasがクラスター内の TiKV ノードの数より大きい場合、PD はデータを TiFlash ノードに複製しません。この問題に対処するには、 max-replicasをクラスター内の TiKV ノードの数以下の整数に変更します。

   ノート：

   max-replicasはデフォルトで 3 に設定されています。本番環境では、この値は通常、TiKV ノードの数よりも少なくなります。テスト環境では、値は 1 です。

       curl -X POST -d '{
           "group_id": "pd",
           "id": "default",
           "start_key": "",
           "end_key": "",
           "role": "voter",
           "count": 3,
           "location_labels": [
           "host"
           ]
       }' <http://172.16.x.xxx:2379/pd/api/v1/config/rule>
   

5. TiDB または PD と TiFlash の接続が正常かどうかを確認します。

   flash_cluster_manager.logファイルでERRORキーワードを検索します。

   • ERRORが見つからない場合、接続は正常です。次のステップに進みます。

   • ERRORが見つかった場合、接続は異常です。以下のチェックを行ってください。

     • ログに PD キーワードが記録されているかどうかを確認します。

       PD キーワードが見つかった場合は、TiFlash 構成ファイルのraft.pd_addrが有効かどうかを確認します。具体的には、 curl '{pd-addr}/pd/api/v1/config/rules'コマンドを実行し、5 秒で出力があるかどうかを確認します。

     • ログに TiDB 関連のキーワードが記録されているかどうかを確認します。

       TiDB キーワードが見つかった場合は、TiFlash 構成ファイルのflash.tidb_status_addrが有効かどうかを確認します。具体的には、 curl '{tidb-status-addr}/tiflash/replica'コマンドを実行し、5 秒で出力があるかどうかを確認します。

     • ノードが相互に ping できるかどうかを確認します。

   ノート：

   問題が解決しない場合は、対応するコンポーネントのログを収集してトラブルシューティングを行います。

6. テーブルにplacement-ruleが作成されているかどうかを確認します。

   flash_cluster_manager.logファイルでSet placement rule … table-<table_id>-rキーワードを検索します。

   • キーワードが見つかった場合は、次の手順に進みます。
   • そうでない場合は、トラブルシューティングのために、対応するコンポーネントのログを収集します。

7. PD が正しくスケジュールされているかどうかを確認します。

   pd.logファイルでtable-<table_id>-rキーワードとスケジューリング動作 ( add operatorなど) を検索します。

   • キーワードが見つかった場合、PD は適切にスケジュールします。
   • そうでない場合、PD は適切にスケジュールされません。 PingCAP テクニカル サポートに問い合わせてください。

データの複製が停止する

TiFlash でのデータ複製が正常に開始された後、一定時間経過してもすべてまたは一部のデータの複製に失敗する場合は、次の手順を実行して問題を確認または解決できます。

1. ディスク容量を確認してください。

   ディスク容量の比率が値low-space-ratioよりも高いかどうかを確認します (デフォルトは 0.8 です。ノードの容量使用率が 80% を超えると、PD はこのノードへのデータの移行を停止して、ディスク容量の枯渇を回避します)。

   • ディスク使用率がlow-space-ratio以上の場合、ディスク容量が不足しています。ディスク容量を解放するには、 ${data}/flash/フォルダーの下にあるspace_placeholder_file (必要に応じて、ファイルを削除した後にreserve-spaceを 0MB に設定) などの不要なファイルを削除します。
   • ディスク使用率が値low-space-ratio未満の場合、ディスク容量は十分です。次のステップに進みます。

2. TiKV、TiFlash、および PD 間のネットワーク接続を確認します。

   flash_cluster_manager.logで、スタックしたテーブルに対応するflash_region_countへの新しい更新があるかどうかを確認します。

   • いいえの場合は、次のステップに進みます。

   • はいの場合は、 down peerを検索します (停止しているピアがある場合、レプリケーションは停止します)。

     • pd-ctl region check-down-peerを実行してdown peerを検索します。
     • down peerが見つかった場合は、 pd-ctl operator add remove-peer\<region-id> \<tiflash-store-id>を実行して削除します。

3. CPU 使用率を確認します。

   Grafana で、 TiFlash-Proxy-Details > Thread CPU > リージョン task worker pre-handle/generate snapshot CPU を選択します。 <instance-ip>:<instance-port>-region-workerの CPU 使用率を確認します。

   曲線が直線の場合、TiFlash ノードはスタックしています。 TiFlash プロセスを終了して再起動するか、PingCAP テクニカル サポートに連絡してください。

データ複製が遅い

原因はさまざまです。次の手順を実行することで、この問題に対処できます。

1. スケジューリング パラメータの値を調整します。

   • レプリケーションを高速化するには、 store limitを増やします。
   • TiKV でリージョンのチェッカー スキャンをより頻繁に行うには、 config set patrol-region-interval 10msを減らします。
   • region mergeを増やして領域の数を減らします。つまり、スキャンが少なくなり、チェック頻度が高くなります。

2. TiFlsh の負荷を調整します。

   TiFlash の負荷が高すぎると、レプリケーションが遅くなる可能性もあります。 Grafana のTiFlash-Summaryパネルで TiFlash インジケータの負荷を確認できます。

   • Applying snapshots Count : TiFlash-summary > raft > Applying snapshots Count
   • Snapshot Predecode Duration : TiFlash-summary > raft > Snapshot Predecode Duration
   • Snapshot Flush Duration : TiFlash-summary > raft > Snapshot Flush Duration
   • Write Stall Duration : TiFlash-summary > Storage Write Stall > Write Stall Duration
   • generate snapshot CPU : TiFlash-Proxy-Details > Thread CPU > Region task worker pre-handle/generate snapshot CPU

   サービスの優先順位に基づいて、それに応じて負荷を調整し、最適なパフォーマンスを実現します。