階層型ストレージに関する FAQ

このドキュメントでは、Infrequent Access (IA) ストレージに関する一般的な質問に回答します。内容には、DML の動作、レプリカの扱い、変換の進行状況、キャッシュ設定、オブジェクトストレージ障害などの運用上の影響が含まれます。

IA テーブルで UPDATE/DELETE を実行できますか？

はい。UPDATE 操作では、まず対応するデータをオブジェクトストレージから IA キャッシュにロードし、変更を実行してから、新しい SST ファイルを書き込みます。これは通常の UPDATE と同じフローです。パフォーマンスはコールドリードの影響を受けます。

IA テーブルの TiFlash レプリカも IA に設定できますか？

いいえ。TiFlash は、元テーブルの IA 属性には従いません。

オブジェクトストレージで障害が発生した場合、IA テーブルはどうなりますか？

IA テーブルは影響を受け、利用できなくなります。これは、すべてのデータがリモートに存在し、読み取りリクエストがオブジェクトストレージからの取得を必要とするためです。さらに、オブジェクトストレージの帯域幅が飽和すると、IA の読み書き性能にも影響します。

IA を設定する前に、どのデータがコールドかをシステムで判別できますか？

TiDB には、コールドデータ / ホットデータを検出する組み込みツールはありません。データアクセスパターンは、自身の業務知識に基づいて評価する必要があります。一般的な目安として、時間でパーティション分割されたテーブルでは、古いパーティションほどアクセス頻度が低くなる傾向があります。

データがコールドストレージ (IA 階層) に保存される場合、3 つのレプリカすべてが保存されますか？ それとも 1 コピーだけですか？

Amazon S3 に保存されるのは 1 コピーだけで、3 つのレプリカは同じオブジェクトを共有します。

クラウドストレージエンジンのアーキテクチャでは、SST/blob データファイルは、もともとオブジェクトストレージ (S3/DFS) 上に 1 コピーしかありません。ファイルはフラッシュまたはコンパクションによって 1 回だけアップロードされ、S3 キーにはノードやレプリカの情報は含まれず、3 つの Raft レプリカは Raft によって複製される ChangeSet を通じて同じファイル ID を参照します。3 レプリカの仕組みが適用されるのは、Raft ログ、メタデータ、および各ノードのローカルキャッシュのみであり、オブジェクトストレージ上のデータには適用されません。

コストへの影響: S3 上のストレージ使用量は常にデータサイズの約 1 倍であり、レプリカ数に応じて増えることはありません。IA 階層によって削減されるのは各ノードのローカルディスク使用量であり、データの耐久性はレプリカ数とは独立して、オブジェクトストレージ自体によって保証されます。

ストレージクラスの変換にはどれくらい時間がかかりますか？ 進行状況はどう追跡できますか？

変換の進行中に SHOW STORAGE_CLASS TRANSITIONS を実行してください。完了率は PROGRESS で確認でき、値は 0 から 1 の範囲です。あるいは、COMPLETED_REPLICAS と TOTAL_REPLICAS を比較することでも確認できます。経過時間 (秒) は DURATION で確認できます。進行状況は 10 秒ごとに収集されるため、これらの値はリアルタイムではありません。

変換時間は主にデータ量と変換方向に依存します。テーブルを IA に設定する場合はメタデータの更新のみで済むため高速ですが、Standard に戻す場合はすべてのデータをオブジェクトストレージからダウンロードする必要があるため、はるかに時間がかかります。自身のクラスターで所要時間を見積もるには、mysql.tidb_storage_class_transition_history 内の、state = 'COMPLETED' で絞り込んだ過去の類似変換の duration を問い合わせてください。

完全なカラムリファレンスとクエリ例については、階層型ストレージの可観測性 を参照してください。

変換が RUNNING のままで、進行状況が進まない場合はどうすればよいですか？

変換が停止している原因として、TiKV のローリング再起動、一時的なリソース不足、短時間のオブジェクトストレージ利用不可などのシステム例外が考えられます。停止しているケースと正常進行中のケースは、DURATION と COMPLETED_REPLICAS をあわせて確認することで見分けられます。両方が増え続けている場合、変換は正常に進行しており、単にデータ量が大きいだけです。

停止した変換を自分で解消できません。TiDB Cloudサポート に連絡してください。問題が解決すると、追加の操作を行わなくても変換は継続されます。

前回の変換が完了する前に、逆方向の ALTER TABLE を実行するとどうなりますか？

前回の変換は無効になります。SHOW STORAGE_CLASS TRANSITIONS では、そのテーブルまたはパーティションの行が新しい変換に置き換えられます。方向が変更され、進行状況は再び最初からカウントされます。

mysql.tidb_storage_class_transition_history にある無効化された変換の履歴レコードは、state = 'SUPERSEDED' に更新されます。その finish_time は新しい変換の開始時刻となり、completed_replicas と total_replicas は無効化される直前に観測された最後の値になります。変換を逆転させても、必ずしも完了済みの作業がすべて破棄されるわけではありません。すでに新しいターゲットに一致しているリージョンはスキップでき、該当する場合は既存のローカルファイルを再利用できます。

変換時間の統計を計算する場合は、state = 'COMPLETED' で絞り込んでください。SUPERSEDED レコードの duration は、完全な変換時間ではなく、無効化されるまでの時間だけを表します。

IA データのローカルキャッシュを増やせますか？ また、その場合コストは増えますか？

はい。ただし、キャッシュレベルの調整には、階層型ストレージのプライベートプレビュー有効化に加えて別途許可リストへの登録が必要です。まず TiDB Cloudサポート に連絡して有効化してください。その後、Overview > Capacity > Update Capacity > Storage Acceleration で、より高い IA キャッシュレベルを選択できます。利用可能なレベルは Economy、Default、Balanced、Deep です。高いレベルほど、より多くの IA データをローカルディスクにキャッシュするため、コールドリード性能が向上します。

コストは増えます。TiDB Cloud Premium では、各キャッシュレベルに IA ストレージ換算係数があり、Economy の 0.9x から Deep の 1.8x まで設定されています。この係数は、請求額計算時に報告される IA ストレージ使用量に適用されます。TiDB Cloud BYOC では係数は適用されません。追加リソースは自身のクラウドアカウント内でプロビジョニングされ、クラウドプロバイダーから課金されます。この変更はホットアップデートであり、再起動は不要です。各レベルの係数については、TiDB Cloud課金 を参照してください。

なお、キャッシュレベルは個々の論理インスタンスではなく、基盤となる TiKV 物理クラスターに適用されます。アカウントで同じ物理クラスター上に複数の論理インスタンスを実行している場合、1 つのインスタンスでの変更は他のインスタンスにも適用されます。

キャッシュレベルやセグメントサイズを変更すると、オブジェクトストレージ内のデータは書き換えられますか？

いいえ。キャッシュレベルの変更は、ローカルキャッシュに保持するデータ量を調整するだけであり、ホットアップデートとして反映されます。

セグメントサイズ (kvengine.ia.segment-size、TiDB Cloud BYOC でのみ利用可能) は、オブジェクトストレージからデータを読み取り、ローカルキャッシュに書き込む際の粒度を変更するだけです。SST ファイルはオブジェクトストレージ内で 1 つのオブジェクト全体として保存され、セグメント単位で構成されているわけではないため、オブジェクトストレージ内の内容が書き換えられることはありません。このパラメータは起動時にのみ有効になるため、TiKV ノードのローリング再起動が必要です。その後、ローカルキャッシュは新しい粒度で徐々に再構築されます。

テーブルを IA のままにすべきかどうかは、どう判断すればよいですか？

ステートメントサマリーテーブル内の IA_EXEC_COUNT と EXEC_COUNT を比較して、IA データを読み取る実行の割合を確認し、クラスター全体の IA Cache Hit Rate パネルも確認してください。

• テーブルにアクセスする大半のステートメントでコールドリード比率が高いままであれば、キャッシュヒット率が IA に対して低すぎます。テーブルを Standard に戻すか、キャッシュレベルを上げることを検討してください。
• コールドリード比率が低くても、一部のステートメントが毎回大量のデータを読み取る場合は、テーブル全体を Standard に戻すのではなく、それらのステートメントを最適化してください。

IA キャッシュヒット率はどこで確認できますか？

Cloud Console で Monitoring > Metrics > Instance Overview に移動し、IA Cache Performance パネルグループを開いてください。ここには、キャッシュヒット率、キャッシュミス率、リモート読み取りセグメントの数とデータ量、リモート読み取り待機時間が含まれます。

ヒット率が 85% を下回ると、黄色のインジケーターが表示されます。クラスターに IA テーブルがない場合、パネルには No IA data と表示されます。