階層型ストレージの可観測性

このドキュメントでは、Infrequent Access (IA) ストレージを監視する方法について説明します。これには、ストレージクラス移行の進行状況、SQL レベルでの IA 読み取りメトリクス、クラスターレベルでの IA キャッシュ性能が含まれます。

ストレージクラス移行を監視する

このセクションでは、ストレージクラス変換の進行状況を追跡する方法と、過去の変換を確認する方法について説明します。

変換の進行状況は、ストレージクラスを変更する方法にかかわらず、同じ方法で追跡されます。

• STORAGE_CLASS の糖衣構文。例: ALTER TABLE t1 STORAGE_CLASS='IA'
• ENGINE_ATTRIBUTE 形式。例: ALTER TABLE t1 ENGINE_ATTRIBUTE='{"storage_class":"IA"}'
• ENGINE_ATTRIBUTE を使用したパーティションレベルの変更

パーティションテーブルは ENGINE_ATTRIBUTE のみをサポートするため、パーティション変換はテーブルレベルの変換と同じビューに表示されます。テーブルまたはパーティションが最初から IA ストレージクラスで作成された場合、移行するデータがないため、これらのビューには表示されません。

ALTER TABLE 文自体は、数秒以内にスキーマメタデータを更新します。その後のリージョンレベルのデータ移行は TiKV 内で非同期に実行され、DDL ライフサイクルとは分離されているため、ADMIN SHOW DDL JOBS では進行状況は報告されません。進行中の変換を追跡するには SHOW STORAGE_CLASS TRANSITIONS を使用し、過去および進行中の変換を確認するには mysql.tidb_storage_class_transition_history をクエリします。履歴テーブルには、変換開始時に state = 'RUNNING' のレコードが挿入され、変換が最終状態に達するとその場で更新されます。

進行中の移行を表示する

SHOW STORAGE_CLASS TRANSITIONS;
SHOW STORAGE_CLASS TRANSITIONS LIKE 'table_name';
SHOW STORAGE_CLASS TRANSITIONS WHERE DIRECTION = 'TO_STANDARD';

SHOW STORAGE_CLASS TRANSITIONS は SELECT * FROM INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS と等価です。

INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS テーブルには、現在進行中の変換が一覧表示されます。このテーブルには state カラムはありません。含まれるすべての行が進行中の変換だからです。このテーブルには次のカラムがあります。

特定の変換の進行状況と経過時間を確認するには、次を実行します。

SELECT TABLE_NAME, DIRECTION, COMPLETED_REPLICAS, TOTAL_REPLICAS,
       ROUND(PROGRESS * 100, 1) AS PROGRESS_PCT,
       DURATION, LAST_UPDATE_TIME
FROM INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS
WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name';

変換は 1 つの進行中状態を経て、2 つの最終状態のいずれかで終了します。各状態は mysql.tidb_storage_class_transition_history にも記録されます。

変換が停止しているかどうかを判断する

LAST_UPDATE_TIME、COMPLETED_REPLICAS、DURATION をあわせて確認してください。

• COMPLETED_REPLICAS が増加し、LAST_UPDATE_TIME も更新され続けている場合: 変換は正常に進行しており、単にデータ量が大きいだけです。
• DURATION は増え続けているのに、COMPLETED_REPLICAS が長時間増加しない場合: TiKV のローリング再起動、一時的なリソース不足、短時間のオブジェクトストレージ利用不可などのシステム例外により、変換が停止している可能性があります。
• TOTAL_REPLICAS、COMPLETED_REPLICAS、PROGRESS、LAST_UPDATE_TIME がすべて NULL のままの場合: まだ成功した観測が行われていません。これらのカラムはまとめて設定・クリアされるため、LAST_UPDATE_TIME だけでは観測の試行が継続しているかどうかは判断できません。代わりに DURATION を確認してください。これは変換が追跡されている間は常に増加します。これらのカラムが NULL のままで DURATION だけが増え続けている場合、ポーリングは継続中ですが、有効な観測結果がまだ返ってきていません。

停止した変換を自分で解消できません。TiDB Cloudサポート に連絡してください。問題が解消されると、COMPLETED_REPLICAS は COMPLETED に達するまで再び増加し続け、追加の操作は不要です。

まだ進行中の変換を逆方向に戻す

テーブルまたはパーティションに対して、前回の変換がまだ進行中の間に逆方向の変換を発行すると、前回の変換は無効化されます。

• INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS では、そのテーブルまたはパーティションの行が新しい変換に置き換えられます。DIRECTION には新しい方向が表示され、START_TIME は新しい変換の開始時刻になり、進捗は再び最初からカウントされます。そのテーブルまたはパーティションには 1 行だけが残ります。
• 無効化された変換の mysql.tidb_storage_class_transition_history 内の履歴レコードは、state = 'SUPERSEDED' に更新されます。その finish_time は新しい変換の開始時刻になり、total_replicas と completed_replicas は無効化される直前に最後に観測された値になります。まだ何も観測されていなかった場合、両方のカラムは NULL です。

無効化された変換がどこまで進んでいたかを確認するには、履歴テーブルで state = 'SUPERSEDED' のレコードをクエリしてください。

移行履歴をクエリする

すべての変換は、開始時に mysql.tidb_storage_class_transition_history テーブルに記録され、進行に応じてそのレコードが更新されます。このテーブルには次のカラムがあります。

このテーブルを使用すると、テスト環境の参考値よりも信頼性高く、自分のクラスターで類似の変換にどれくらい時間がかかるかを見積もれます。

-- Average duration of completed conversions, grouped by direction.
-- Filter on state = 'COMPLETED': the duration of a SUPERSEDED record
-- does not represent a full conversion.
SELECT direction,
       COUNT(*) AS total_conversions,
       ROUND(AVG(duration), 0) AS avg_duration_sec,
       MIN(duration) AS min_duration_sec,
       MAX(duration) AS max_duration_sec
FROM mysql.tidb_storage_class_transition_history
WHERE state = 'COMPLETED'
GROUP BY direction;

-- The most recent finished conversion of a specific table
SELECT table_name, direction, state, duration AS total_duration_sec,
       total_replicas, completed_replicas, start_time, finish_time
FROM mysql.tidb_storage_class_transition_history
WHERE table_schema = 'db_name' AND table_name = 'table_name'
    AND state <> 'RUNNING'
ORDER BY finish_time DESC
LIMIT 1;

-- Conversions that were voided by a reverse conversion
SELECT table_schema, table_name, partition_name, direction,
       completed_replicas, total_replicas, start_time, finish_time, duration
FROM mysql.tidb_storage_class_transition_history
WHERE state = 'SUPERSEDED'
ORDER BY finish_time DESC;

履歴レコードの保持

mysql.tidb_storage_class_transition_history に保持されるレコードの最大数は、システム変数 tidb_storage_class_transition_history_size によって制御されます。レコード数がこの上限を超えると、finish_time の古い順に最も古いレコードから削除されます。保持制御は最大でも 1 分に 1 回しか実行されないため、行数が一時的に上限を超えることがあります。

-- View the current retention limit
SELECT @@tidb_storage_class_transition_history_size;

-- Retain up to 500 records
SET GLOBAL tidb_storage_class_transition_history_size = 500;

tidb_storage_class_transition_history_size

• Scope: GLOBAL
• Persists to cluster: Yes
• Applies to hint SET_VAR: No
• Type: Integer
• Default value: 1000
• Range: [100, 100000]
• この変数は、mysql.tidb_storage_class_transition_history テーブルに保持するストレージクラス移行レコードの最大数を設定するために使用されます。値を大きくすると、より長期間履歴を保持できますが、mysql データベースで使用する領域も増えます。

SQL レベルで IA 読み取りを監視する

このセクションでは、EXPLAIN ANALYZE、ステートメントサマリーテーブル、スロークエリログ、および TiDB Cloud コンソールで利用できる IA メトリクスについて説明します。

EXPLAIN ANALYZE

クエリにリモートデータロードが含まれる場合、scan_detail には次のフィールドが含まれます。

EXPLAIN ANALYZE SELECT * FROM t_ia WHERE id BETWEEN 1 AND 50000;
-- The output includes:
-- ia_remote_read_segment_size: 2320453     -- Total bytes loaded remotely
-- ia_remote_read_segment_count: 3           -- Number of remote loading events
-- ia_remote_read_segment_wait_time: 0.008   -- Remote wait time (seconds)

ステートメントサマリー

STATEMENTS_SUMMARY、STATEMENTS_SUMMARY_HISTORY、およびそれらの CLUSTER_ 対応ビューには、次の IA カラムが含まれます。

AVG_ および MAX_ の各カラムは、各実行でどれだけのデータをリモートから読み取ったかを示し、IA_EXEC_COUNT は、そもそも何回の実行がリモート読み取りを行ったかを示します。これら 2 つの観点を組み合わせて使用してください。たとえば、AVG_IA_REMOTE_READ_SEGMENT_SIZE は小さい一方で IA_EXEC_COUNT / EXEC_COUNT の比率が高いステートメントは、少量のコールドデータに頻繁にアクセスしていることを意味します。

IA テーブルを含まないクエリでは、これらのカラムは 0 または NULL になります。

コールドリード実行の割合が最も高いステートメントを見つけるには、次の SQL を使用します。

SELECT DIGEST_TEXT, EXEC_COUNT, IA_EXEC_COUNT,
       ROUND(IA_EXEC_COUNT / EXEC_COUNT * 100, 2) AS ia_exec_pct,
       AVG_IA_REMOTE_READ_SEGMENT_SIZE
FROM INFORMATION_SCHEMA.CLUSTER_STATEMENTS_SUMMARY_HISTORY
WHERE IA_EXEC_COUNT > 0
ORDER BY ia_exec_pct DESC
LIMIT 10;

スロークエリ

INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY には、次の IA カラムが含まれます。

• IA_remote_read_segment_count
• IA_remote_read_segment_size
• IA_remote_read_segment_wait_time

同じフィールドは ADMIN SHOW SLOW の出力でも利用できます。

ADMIN SHOW SLOW RECENT 10;
ADMIN SHOW SLOW TOP INTERNAL 10;
ADMIN SHOW SLOW TOP ALL 10;

フィールドの意味と単位は、SLOW_QUERY テーブルと同じです。IA テーブルを含まないクエリでは、値は NULL または 0 になります。対応するフィールドは、TiDB Cloud コンソールのスロークエリ詳細にも表示されます。

コンソールの SQL ステートメントリスト

IA_EXEC_COUNT カラムは、SQL ステートメント診断リストにも表示されます。

• Cloud Console: Monitoring > Diagnosis > SQL Statement
• Clinic: Diagnosis > SQL Statements

このカラム名は Exec Count of IA で、Executions Count の直後に配置されるため、2 つの値を直接比較できます。他のカラムと同様に、昇順および降順のソートをサポートします。IA テーブルを含まないステートメントでは、値は 0 です。

クラスターレベルで IA キャッシュ性能を監視する

このセクションでは、TiDB Cloud コンソールで IA キャッシュの挙動を確認するためのクラスターレベルのパネルについて説明します。

IA Cache Performance パネル

パス: Monitoring > Metrics > Instance Overview > IA Cache Performance。

時間選択ツールで時間範囲を変更すると、より長期的な傾向を観察できます。クラスターに IA テーブルがない場合、パネルには 0% やエラーの代わりに No IA data が表示されます。

単一ステートメントのコールドデータ量を監視するには、Monitoring > Diagnosis > Slow Query > Coprocessor にある IA Remote Read Segment Size パネルを使用します。

パネルの見方

キャッシュヒット率は、実際のアクセスパターンに依存します。アクセスが集中していれば 95% を超えることもありますが、アクセスが分散している場合は 95% を下回ることがあります。

• ヒット率の急低下: 同時に IA Cache Miss Rate が上昇しているか確認してください。同時に上昇していれば、収集上の問題ではなく、コールドリードが実際に増加していることを示します。その後、ステートメントサマリーテーブルの IA_EXEC_COUNT を使って、どのステートメントがコールドリードを引き起こしたかを特定します。
• ヒット率が継続的に低い: キャッシュがコールドデータによって圧迫されています。IA キャッシュレベルを引き上げるか、IA に設定するデータ量を減らすことを検討してください。階層型ストレージの設定と管理 を参照してください。
• テーブルが IA に適しているかの評価: パーティションを IA に設定した後、少なくとも 1 営業日分は IA Cache Hit Rate を観察してください。ヒット率が安定していれば、そのアクセスパターンは IA に適しています。大きな変動や低い平均値は、そのデータへのアクセスが IA に対して分散しすぎていることを意味します。

診断ワークフロー

変更前に変換ウィンドウを見積もる

1. SHOW STORAGE_CLASS TRANSITIONS を実行して、他の変換がすでに進行中かどうかを確認します。このテーブルには、進行中の変換のみが表示されます。
2. mysql.tidb_storage_class_transition_history をクエリし、state = 'COMPLETED' で絞り込んだうえで、クラスター内の類似する過去の変換の duration を確認します。
3. 変換中は、DURATION と PROGRESS を組み合わせて残り時間を見積もります。

キャッシュヒット率の急低下を調査する

1. IA Cache Hit Rate の低下を確認し、同時に IA Cache Miss Rate が上昇しているかを確認します。
2. ステートメントサマリーテーブルで、IA_EXEC_COUNT / EXEC_COUNT の比率が高いステートメントを特定します。
3. 多くのステートメントで同時にこの比率が上昇している場合、分析クエリのバッチが IA テーブルをスキャンし、キャッシュからホットデータを追い出している可能性があります。
4. IA キャッシュレベルを引き上げるか、影響を受けたデータを Standard ストレージに戻すかを判断します。

テーブルを IA に保持するかどうかを判断する

1. そのテーブルにアクセスするステートメントについて、IA_EXEC_COUNT / EXEC_COUNT を集計します。
2. ほとんどのステートメントでコールドリード比率が高いままであれば、IA に対してキャッシュヒット率が低すぎます。テーブルを Standard に戻すことを検討してください。
3. コールドリード比率が低くても、一部のステートメントが毎回大量のデータを読み取る場合は、テーブル全体を戻すのではなく、それらのステートメントを最適化してください。

参照

• 階層型ストレージの概要
• 階層型ストレージの設定と管理
• 階層型ストレージの制限事項
• 階層型ストレージに関する FAQ