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

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

TiFlashの起動に失敗する

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

  1. システムがCentOS8であるかどうかを確認してください。

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

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

    ulimit -n 1000000
  3. PD制御ツールを使用して、ノード(同じIPとポート)でオフラインにできなかったTiFlashインスタンスがあるかどうかを確認し、インスタンスを強制的にオフラインにします。詳細な手順については、 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}
  2. TiFlash-SummaryモニタリングパネルでUpTimeを表示して、TiFlashプロセスが正しく機能しているかどうかを確認します。

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

    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-replicaslocation-labelsは無効になります。レプリカポリシーを調整するには、配置ルールに関連するインターフェイスを使用します。

  6. マシンの残りのディスク容量(TiFlashノードのstore )が十分かどうかを確認します。デフォルトでは、残りのディスク容量がstoreの容量( low-space-ratioのパラメーターによって制御される)の20%未満の場合、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ファイルのflash_region_countパラメータ、およびtiflash_cluster_manager.log監視項目Uptimeに変更があるかどうかを確認します。

    • はいの場合、TiFlashプロセスは正しく実行されます。
    • いいえの場合、TiFlashプロセスは異常です。詳細については、 tiflashログを確認してください。
  3. pd-ctlを使用して、 配置ルールの機能が有効になっているかどうかを確認します。

    echo 'config show replication' | /path/to/pd-ctl -u http://<pd-ip>:<pd-port>
  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 > Regiontaskworkerの事前処理/スナップショットCPUの生成を選択します。 <instance-ip>:<instance-port>-region-workerのCPU使用率を確認します。

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

データ複製が遅い

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

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

    • store limitを増やすと、レプリケーションが高速化されます。
    • config set patrol-region-interval 10msを減らすと、TiKVでリージョンのチェッカースキャンがより頻繁になります。
    • region mergeを増やすと、リージョンの数が減ります。つまり、スキャンが少なくなり、チェック頻度が高くなります。
  2. TiFlshの負荷を調整します。

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

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

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

このページは役に立ちましたか?