ディスク容量管理

このドキュメントでは、主にディスクストレージ容量に関連するシステムパラメータと処理戦略について説明します。

Dorisのデータディスク容量が制御されていない場合、ディスクが満杯になることでプロセスがハングします。そのため、ディスク使用量と残り容量を監視し、異なる警告レベルを設定することでDorisシステム内の各種操作を制御し、ディスクが満杯になる状況を回避するよう努めています。

用語集

• Data Dir: データディレクトリ。BEの設定ファイルbe.confのstorage_root_pathで指定された各データディレクトリです。通常、データディレクトリは1つのディスクに対応するため、以下のディスクもデータディレクトリを指します。

基本原理

BEは定期的に（1分毎に）ディスク使用量をFEに報告します。FEはこれらの統計値を記録し、これらの統計値に基づいて各種操作リクエストを制限します。

FEではHigh WatermarkとFlood Stageという2つの閾値が設定されています。Flood StageはHigh Watermarkより高く設定されています。ディスク使用量がHigh Watermarkを上回ると、Dorisは特定の操作（レプリカバランシングなど）の実行を制限します。Flood Stageを上回った場合は、特定の操作（データロードなど）が禁止されます。

同時に、BE上にもFlood Stageが設定されています。FEがBE上のディスク使用量をタイムリーに完全に検出できず、特定のBE操作（Compactionなど）を制御できないことを考慮しています。そのため、BE上のFlood StageはBEが能動的に特定の操作を拒否・停止し、自己防衛の目的を達成するために使用されます。

FEパラメータ

High Watermark:

storage_high_watermark_usage_percent: default value is 85 (85%).
storage_min_left_capacity_bytes: default value is 2GB.

ディスク容量がstorage_high_watermark_usage_percentより多い場合、またはディスク空き容量がstorage_min_left_capacity_bytesより少ない場合、そのディスクは以下の操作の宛先パスとして使用されなくなります：

• Tablet Balance
• Colocation Relocation
• Decommission

Flood Stage:

storage_flood_stage_usage_percent: default value is 95 (95%).
storage_flood_stage_left_capacity_bytes: default value is 1GB.

ディスク容量がstorage_flood_stage_usage_percentを超える場合、またはディスクの空き容量がstorage_flood_stage_left_capacity_bytesを下回る場合、そのディスクは以下の操作の宛先パスとして使用されなくなります：

• Tablet Balance
• Colocation Relocation
• Replica make up
• Restore
• Load/Insert

BEパラメータ

Flood Stage:

storage_flood_stage_usage_percent: default value is 90 (90%).
storage_flood_stage_left_capacity_bytes: default value is 1GB.

ディスク使用量がstorage_flood_stage_usage_percentより多く、かつディスク空き容量がstorage_flood_stage_left_capacity_bytesより少ない場合、このディスクでは以下の操作が禁止されます：

• Base/Cumulative Compaction
• データロード
• Clone Task（通常、レプリカの修復やバランシング時に発生します。）
• Push Task（Hadoopインポートのロードフェーズ中に発生し、ファイルがダウンロードされます。）
• Alter Task（Schema ChangeまたはRollup Task。）
• Download Task（回復操作のダウンロードフェーズ。）

ディスク容量の解放

ディスク容量がHigh WatermarkやFlood Stageを上回った場合、多くの操作が禁止されます。この時、以下の方法でディスク使用量を減らし、システムを復旧することを試すことができます。

• テーブルまたはパーティションの削除

  テーブルやパーティションを削除することで、ディスク容量使用量を素早く削減し、クラスターを復旧できます。 注意：DROP操作のみがディスク容量使用量の迅速な削減という目的を達成できます。DELETE操作では達成できません。

  DROP TABLE tbl;
  ALTER TABLE tbl DROP PARTITION p1;

• BE拡張

  バックエンド拡張後、データタブレットはディスク使用量が少ないBEノードに自動的にバランシングされます。拡張操作により、データ量とノード数に応じて数時間から数日でクラスターがバランスの取れた状態に到達します。

• テーブルまたはパーティションのレプリカ数の変更

  テーブルまたはパーティションのレプリカ数を減らすことができます。例えば、デフォルトの3レプリカを2レプリカに減らすことができます。この方法はデータの信頼性を低下させますが、ディスク使用率を素早く削減し、クラスターを正常状態に復旧できます。 この方法は通常、緊急復旧システムで使用されます。復旧後は拡張またはデータ削除によりディスク使用率を下げた後、レプリカ数を3に復元してください。 レプリカ変更操作は即座に有効になり、バックエンドは冗長なレプリカを自動的かつ非同期的に削除します。

  ALTER TABLE tbl MODIFY PARTITION p1 SET("replication_num" = "2");

• 不要なファイルを削除する

  ディスクが満杯になってBEがクラッシュし、起動できない場合（この現象はFEやBEの検出が遅れることで発生する可能性があります）、BEプロセスが開始できるようにデータディレクトリ内の一部の一時ファイルを削除する必要があります。 以下のディレクトリ内のファイルは直接削除できます：

  • log/: logディレクトリ内のログファイル
  • snapshot/: snapshotディレクトリ内のスナップショットファイル
  • trash/ trashディレクトリ内のゴミ箱ファイル

  この操作はBEゴミ箱からのデータ復元に影響します。

  BEが依然として起動できる場合は、ADMIN CLEAN TRASH ON(BackendHost:BackendHeartBeatPort);を使用して一時ファイルを能動的にクリーンアップできます。すべてのtrashファイルと期限切れのsnapshotファイルがクリーンアップされ、これはゴミ箱からのデータ復元操作に影響します。

  ADMIN CLEAN TRASHを手動で実行しない場合、システムは数分から数十分以内に自動的にクリーンアップを実行します。以下の2つの状況があります：

  • ディスク使用量がFlood Stageの90%に達していない場合、期限切れのtrashファイルと期限切れのsnapshotファイルがクリーンアップされます。この時、最近のファイルの一部は保持され、データの復旧に影響しません。
  • ディスク使用量がFlood Stageの90%に達している場合、すべてのtrashファイルと期限切れのsnapshotファイルがクリーンアップされ、これはゴミ箱からのデータ復元操作に影響します。

  自動実行の時間間隔は、設定項目のmax_garbage_sweep_intervalとmin_garbage_sweep_intervalによって変更できます。

  trashファイルの不足により復旧が失敗した場合、以下の結果が返される可能性があります：

  {"status": "Fail","msg": "can find tablet path in trash"}

• データファイルの削除（危険！！！）

  上記の操作のいずれでも容量を解放できない場合、データファイルを削除してスペースを空ける必要があります。データファイルは指定されたデータディレクトリのdata/ディレクトリ内にあります。tabletを削除するには、まずtabletの少なくとも1つのレプリカが正常であることを確認する必要があります。そうでなければ、唯一のレプリカを削除するとデータ損失が発生します。

  id 12345のtabletを削除したいとします：

  • Tabletに対応するディレクトリを見つけます。通常はdata/shard_id/tablet_id/の下にあります。例：

    data/0/12345/

  • Record the tablet id and schema hash. The schema hash is the name of the next-level directory of the previous step. The following is 352781111:

    data/0/12345/352781111

• データディレクトリを削除する:

    ```rm -rf data/0/12345/```

  • Delete tablet metadata refer to Tablet metadata management tool

    ./lib/meta_tool --operation=delete_header --root_path=/path/to/root_path --tablet_id=12345 --schema_hash= 352781111