TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ
🚀
新しい TiDB Labs を探索し、ブラウザから直接分散型 SQL データベースを学び、RAG アプリを構築しましょう。

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

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

TiFlash が起動に失敗する

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

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

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

    dnf install libnsl

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

    ulimit -n 1000000

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

上記の方法で問題を解決できない場合は、 TiFlashログ ファイルと PingCAP またはコミュニティからのサポートを受ける保存します。

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. pd-ctlを通じてTiFlashプロキシの状態が正常かどうかを確認します。

    tiup ctl:nightly pd -u http://${pd-ip}:${pd-port} store

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

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

    tiup ctl:nightly pd -u http://${pd-ip}:${pd-port} config placement-rules show | grep -C 10 default

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

    注記：

    • 配置ルールが有効になっていて、複数のルールが存在する場合、以前に構成されたmax-replicas 、 location-labels 、およびisolation-level有効になりません。レプリカ ポリシーを調整するには、配置ルールに関連するインターフェイスを使用します。
    • 配置ルールが有効になっていて、デフォルト ルールが 1 つだけ存在する場合、 max-replicas 、またはisolation-level location-labelsが変更されると、TiDB はこのデフォルト ルールを自動的に更新します。

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

一部のクエリでは、 Region Unavailableエラーが返されます。

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

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

データファイルの破損

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

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

TiFlashノードの削除は遅い

この問題に対処するには、次の手順を実行します。

  1. クラスターのスケールイン後に使用可能なTiFlashノードの数よりも多くのTiFlashレプリカがテーブルに存在するかどうかを確認します。

    SELECT * FROM information_schema.tiflash_replica WHERE REPLICA_COUNT > 'tobe_left_nodes';

    tobe_left_nodesスケールイン後のTiFlashノードの数です。

    クエリ結果が空でない場合は、対応するテーブルのTiFlashレプリカの数を変更する必要があります。これは、スケールイン後にTiFlashレプリカの数がTiFlashノードの数を超えると、PD が削除するTiFlashノードからリージョンピアを移動しないため、これらのTiFlashノードの削除が失敗するためです。

  2. すべてのTiFlashノードをクラスターから削除する必要があるシナリオで、 INFORMATION_SCHEMA.TIFLASH_REPLICAテーブルにクラスター内にTiFlashレプリカが存在しないことが示されていても、 TiFlashノードの削除が依然として失敗する場合は、最近DROP TABLE <db-name>.<table-name>またはDROP DATABASE <db-name>操作を実行したかどうかを確認します。

    TiFlashレプリカを持つテーブルまたはデータベースの場合、 DROP TABLE <db-name>.<table-name>またはDROP DATABASE <db-name>実行した後、TiDB は PD 内の対応するテーブルのTiFlashレプリケーション ルールをすぐに削除しません。代わりに、対応するテーブルがガベージコレクション(GC) 条件を満たすまで待機してから、これらのレプリケーション ルールを削除します。GC が完了すると、対応するTiFlashノードを正常に削除できます。

    GC 条件が満たされる前にTiFlashのデータ複製ルールを手動で削除するには、次の操作を実行します。

    注記：

    テーブルのTiFlashレプリケーション ルールを手動で削除した後、このテーブルに対してRECOVER TABLE 、またはFLASHBACK DATABASE FLASHBACK TABLEを実行すると、このテーブルのTiFlashレプリカは復元されません。

    1. 現在の PD インスタンス内のTiFlashに関連するすべてのデータ複製ルールをビュー。

      curl http://<pd_ip>:<pd_port>/pd/api/v1/config/rules/group/tiflash

      [
  {
    "group_id": "tiflash",
    "id": "table-45-r",
    "override": true,
    "start_key": "7480000000000000FF2D5F720000000000FA",
    "end_key": "7480000000000000FF2E00000000000000F8",
    "role": "learner",
    "count": 1,
    "label_constraints": [
      {
        "key": "engine",
        "op": "in",
        "values": [
          "tiflash"
        ]
      }
    ]
  }
]

    2. TiFlashに関連するすべてのデータ複製ルールを削除します。1 がid table-45-rあるルールを例にとります。次のコマンドで削除します。

      curl -v -X DELETE http://<pd_ip>:<pd_port>/pd/api/v1/config/rule/tiflash/table-45-r

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レプリケーションは正常に実行されます。
    • いいえの場合、 TiFlashレプリケーションは異常です。 tidb.logで、 Tiflash replica is not availableのログを検索します。対応するテーブルのprogressが更新されているかどうかを確認します。更新されていない場合は、 tiflash logで詳細情報を確認します。たとえば、 tiflash logのlag_region_info検索して、どのリージョンが遅れているかを確認します。

  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 がテーブルの配置ルールを作成したかどうかを確認します。

    TiDB DDL 所有者のログを検索し、TiDB が PD に配置ルールを追加するように通知したかどうかを確認します。パーティション化されていないテーブルの場合はConfigureTiFlashPDForTable検索します。パーティション化されたテーブルの場合はConfigureTiFlashPDForPartitions検索します。

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

  6. PD がテーブルの配置ルールを設定しているかどうかを確認します。

    現在の PD 上のすべてのTiFlash配置ルールを表示するには、 curl http://<pd-ip>:<pd-port>/pd/api/v1/config/rules/group/tiflashコマンドを実行します。ID がtable-<table_id>-rルールが見つかった場合、PD は配置ルールを正常に構成しています。

  7. PD のスケジュールが適切に設定されているかどうかを確認します。

    pd.logファイルでtable-<table_id>-rキーワードとadd operatorのようなスケジュール動作を検索します。

    • キーワードが見つかった場合、PD は適切にスケジュールします。
    • そうでない場合、PD は適切にスケジュールされません。

データの複製が停止する

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

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

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

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

  2. down peerがあるかどうかを確認します ( down peerがあるとレプリケーションが停止する可能性があります)。

    pd-ctl region check-down-peerコマンドを実行して、 down peerがあるかどうかを確認します。 3 がある場合は、 pd-ctl operator add remove-peer <region-id> <tiflash-store-id>コマンドを実行して削除します。

データの複製が遅い

原因はさまざまです。次の手順を実行することで問題を解決できます。

  1. レプリケーションを高速化するにはstore limit増やします。

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

    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

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

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