Hologres:仮想ウェアハウスの管理

注意事項

• Alibaba Cloud アカウントまたは Resource Access Management (RAM) ユーザーのみが仮想ウェアハウスを作成できます。インスタンスのスーパーユーザー権限が必要です。

• 仮想ウェアハウスの作成は非同期プロセスであるため、仮想ウェアハウスを作成する SQL コマンドを実行しても、作成が完了したわけではありません。hg_get_warehouse_status 関数を使用して、仮想ウェアハウスのステータスをクエリする必要があります。

方法

注意事項

• Alibaba Cloud アカウントまたは RAM ユーザーのみが仮想ウェアハウスを削除できます。インスタンスのスーパーユーザー権限が必要です。

• インスタンスのデフォルトの仮想ウェアハウスは削除できません。

• SQL コマンドを使用してテーブルグループのプライマリ仮想ウェアハウスを削除することはできません。

• 仮想ウェアハウスの削除は非同期プロセスであるため、SQL コマンドを実行しても削除が完了したわけではありません。hg_get_warehouse_status 関数を使用して、仮想ウェアハウスのステータスをクエリする必要があります。

方法

権限

• V3.0.28 より前は、Alibaba Cloud アカウントまたは RAM ユーザーのみが仮想ウェアハウスをスケーリングできました。V3.0.28 以降、RAM ロール (STS アカウント) もこの操作を実行できます。

• 仮想ウェアハウスをスケーリングするには、次の権限が必要です：

  • RAM ロール権限：AliyunHologresWarehouseFullAccess または AliyunHologresFullAccess。

  • インスタンス内のスーパーユーザー権限。

仮想ウェアハウスの弾力的なスケーリングの仕組みについては、「リソースの弾力性の概要」をご参照ください。

仮想ウェアハウスのスケールアップ (垂直スケーリング)

-- 仮想ウェアハウスのリソースを増やす
CALL hg_alter_warehouse ('read_warehouse_1',64);

-- 仮想ウェアハウスがスケールアップされるのを待つ
SELECT wait_until_warehouse_running ('read_warehouse_1');

-- リバランス
SELECT hg_rebalance_warehouse ('read_warehouse_1');

-- リバランスが完了するのを待つ
SELECT hg_wait_until_rebalance_warehouse_done ('read_warehouse_1');

仮想ウェアハウスのスケールダウン (垂直スケーリング)

仮想ウェアハウスのスケールアウト (水平スケーリング)

計算グループクラスターのスケールイン

計算グループの表示

• 構文

  • hologres.hg_warehouses システムテーブルには、現在のインスタンス内のすべての仮想ウェアハウスに関する情報が格納されています。次の SQL ステートメントを実行して、現在のインスタンス内のすべての仮想ウェアハウスに関する情報を表示できます。

    SELECT * FROM hologres.hg_warehouses;

  • 次の SQL ステートメントを実行して、現在使用されている仮想ウェアハウスを表示します。システムは現在の仮想ウェアハウスの名前を返します。

    SELECT current_warehouse();

• パラメーター

  hologres.hg_warehouses システムテーブルには、次の列が含まれています：

  フィールド	データ型	説明	例
  warehouse_id	INTEGER	計算グループ ID は、計算グループを一意に識別します。	1
  warehouse_name	TEXT	計算グループの名前です。	init_warehouse
  cpu	INTEGER	計算グループの CPU コア数。	32
  mem	INTEGER	計算グループのメモリ (GB)	128
  cluster_min_count	INTEGER	計算グループの最小シャード数。	1
  cluster_max_count	INTEGER	計算グループの最大シャード数。	1
  target_status	INTEGER	仮想ウェアハウスのターゲットステータス。仮想ウェアハウスのステータス変更は非同期プロセスであるため、仮想ウェアハウスを作成する SQL ステートメントを実行すると、システムはすぐに実行結果を返しますが、仮想ウェアハウスはまだ作成されていません。システムはバックグラウンドで非同期に仮想ウェアハウスを作成します。このステータスは、仮想ウェアハウスが到達すべき最終状態を記録します。有効値： 1：実行中。 2：インスタンスを手動でシャットダウン。	1
  status	INTEGER	計算グループには、次のいずれかのステータスがあります： 0：初期化中。 1：実行中。 2：手動で停止。 3：処理失敗。ステータスが処理失敗の場合、status_detail 列に具体的な理由が表示されます。 4：処理中。	1
  status_detail	TEXT	計算グループのステータスの詳細。	なし
  is_default	BOOLEAN	デフォルトの仮想ウェアハウスであるかどうかを示します。有効値： デフォルトの計算グループです。 f はデフォルトの計算グループではありません。	t
  config	TEXT	計算グループの構成	なし
  comment	TEXT	計算グループに関する注記。	なし

計算グループの停止

計算グループの再開

計算グループの再起動

計算グループのステータス取得

• 構文

  • 次の SQL ステートメントを使用して、計算グループの現在のステータスを取得できます：

    select hg_get_warehouse_status('<warehouse_name>');

  • 仮想ウェアハウスの作成やスケーリングなどの操作は非同期で実行されるため、仮想ウェアハウスのステータスが変更された後に他の操作を実行する必要がある場合があります。この場合、wait_until_warehouse_running 関数を使用できます。この関数は、指定された仮想ウェアハウスが実行中状態になるまで待機してから結果を返します。コマンドは次のとおりです：

    select wait_until_warehouse_running('<warehouse_name>',<timeout_seconds>);

• パラメーター

  パラメーター	タイプ	説明
  warehouse_name	TEXT	ステータスを取得する計算グループの名前です。
  timeout_seconds	INTEGER	タイムアウト期間 (秒)。このパラメーターはオプションです。

• 例

  次の SQL ステートメントを実行して、org_data テーブルから res_data テーブルにデータをインポートする前に仮想ウェアハウスをスケールアップし、インポートが完了した後に仮想ウェアハウスをスケールダウンします：

  -- warehouse_1 を 64 CU にスケールアップする
  CALL hg_alter_warehouse ('warehouse_1',64);
  
  -- warehouse_1 がスケールアップされるのを待つ
  SELECT wait_until_warehouse_running('warehouse_1');
  
  -- データを書き込む
  INSERT INTO res_data SELECT * FROM org_data;
  
  -- warehouse_1 を 32 CU にスケールダウンする
  CALL hg_alter_warehouse ('warehouse_1',32);

計算グループ名の変更

方法

計算グループのリバランス

Hologres インスタンスが実行中のとき、各仮想ウェアハウスのワーカーノードはデータシャードのメタデータを均等にロードします。ただし、高速回復やスケールアウト後などの一部のシナリオでは、データシャードがワーカーノード間で不均等に分散されることがあります。この場合、シャードリバランス操作をトリガーして、データシャードを積極的に再配布し、仮想ウェアハウスのワーカーノードがシャードメタデータを均等にロードするようにする必要があります。

• 権限

  シャードリバランス操作をトリガーするには、インスタンスのスーパーユーザー権限が必要です。

• 注意事項

  • Hologres V2.1 以降、仮想ウェアハウスに空のワーカーノード (つまり、シャードをロードしていないノード) が含まれている場合、仮想ウェアハウスは自動的にリバランスをトリガーします。

  • Hologres V2.2 以降、システムは仮想ウェアハウスのリバランス中に実行される SELECT クエリの自動リトライをサポートします。これにより、クエリはわずかに長い実行時間の後に正常に完了し、ERROR: fail to execute query internal error: Get rundown is not allowed in recovering state. のようなエラーを防ぎます。

• 構文

  SELECT hg_rebalance_warehouse ('<warehouse_name>');

• パラメーター

  パラメーター	タイプ	説明
  warehouse_name	TEXT	シャードバランシングをトリガーする計算グループの名前です。

• 戻り値

  シャードリバランス操作をトリガーすると、次のいずれかの結果が返されます：

  • true：リバランスが正常にトリガーされ、システムはリバランス操作を開始します。

  • false：リバランスは不要です。

  • エラー：リバランスのトリガーに失敗しました。たとえば、Pod に障害がある場合、リバランス操作をトリガーするとエラーが報告されます。

  説明

  • リバランス中、システムはバランスの取れた状態 (各ワーカーノードがロードするシャード数の差が 1 以下である状態) を達成するためにリバランスが必要かどうかを計算します。例：

    • ワーカーが 2 つ、シャードが 2 つの場合、各ワーカーに 1 つのシャードが割り当てられます。

    • ワーカーが 2 つ、シャードが 3 つの場合、一方のワーカーに 1 つのシャード、もう一方に 2 つのシャードが割り当てられます。

  • リバランス操作は通常 2〜3 分かかります。所要時間は仮想ウェアハウス内のテーブルグループの数に依存します。テーブルグループが多いほど、リバランスにかかる時間が長くなります。リバランス中、書き込み操作は約 15 秒間中断されます。

  • リバランスは非同期で実行されるため、次の SQL ステートメントを実行して実行の進行状況を監視できます：

    SELECT hg_get_rebalance_warehouse_status('<warehouse_name>');

    DOING の戻り値はリバランスが進行中であることを示します。DONE の戻り値はリバランスが完了したことを示します。

計算グループのタイムアウト期間の設定

statement_timeout パラメーターを設定して、セッションレベルまたはデータベースレベルでタイムアウト期間を構成できます。詳細については、「GUC パラメーター」をご参照ください。

仮想ウェアハウスの場合、次のコマンドを実行してタイムアウト期間を設定できます。この構成は、セッションレベルおよびデータベースレベルの構成よりも優先度が低くなります。したがって、まずデータベースレベルの構成をキャンセルする必要があります。

-- データベースレベルの設定をキャンセルする
ALTER DATABASE <db_name> RESET statement_timeout;

-- 仮想ウェアハウスのタイムアウト期間を 600 秒に設定する
CALL hg_alter_warehouse ('<warehouse_name>', <cu>, '{"configs":{"gucs":{"statement_timeout":"600000"}}}');