メインコンテンツまでスキップ
バージョン: 4.x

Warehouse設定

Warehouseの詳細を確認​

warehouseセレクターでは、確認が許可されているすべてのwarehouseを表示できます。

warehouse-details

warehouseセレクターには、各warehouseの名前、クラウドプラットフォーム、リージョン、ステータスが表示されます。チェックマークが付いているものが現在のwarehouseです。

warehouseの上にカーソルを移動すると、ポップアップカードが表示され、warehouseの名前、ID、コアバージョン、クラウドプラットフォーム、リージョン、ゾーン、組織が表示されます。

注意

  • Warehouse IDの命名規則：8文字で構成され、大文字と数字で構成されます。最初の4文字はクラウドプラットフォームとリージョンを表し（例：AWSのUS East (N. Virginia)の場合、AWVA）、最後の4文字は文字と数字のランダムな組み合わせでwarehouseを表します（X7NGなど）。

現在のWarehouseを切り替え​

warehouseセレクターでは、スクロールして対象のwarehouseを見つけ、シンプルなクリックで切り替えることができます。

Warehouse名を変更​

Settingsページでwarehouse名を変更できます。新しいwarehouse名（分かりやすい名前を推奨）を入力し、Enterキーを押して変更を確定してください。

警告 warehouse名は現在の組織内で一意である必要があり、最大32文字です。中国語、英字、数字、_、-のみサポートします

Warehouseパスワードを変更​

warehouseに接続する際には、ユーザー名とパスワードが必要です。Settingsページでパスワードを初期化またはリセットできます。

change-warehouse-password

警告 パスワードは大文字、小文字、数字、特殊文字~!@#$%^&*()_+|&lt&gt,.?/:;'[]"のみサポートし、そのうち少なくとも3つを含む必要があり、長さは8-20文字です。

Transparent Date Encryption​

セキュリティを強化するため、warehouse作成時にTransparent Data Encryption（TDE）を有効にして、サービスデータに追加の保護レイヤーを提供できます。

enable-tde

拡張暗号化は現在AWSのwarehouseで利用可能です。

TDEが有効になると、warehouseが提供するデフォルトキーの代わりに、独自の顧客管理KMSキーを使用するように暗号化をアップグレードできます。

tde-settings

  1. ​KMS Keyを作成：AWS KMSコンソールで、新しい対称暗号化キーを作成します。

  2. ​Encryption Role IDをコピー：管理コンソールで、SettingsページのRotate KMSをクリックし、Encryption Role IDをコピーします。

tde-rotate-key

  1. ​キーポリシーを更新：作成したKMSキーのキーポリシーに以下のポリシーステートメントを追加して、上記のロールがキーを使用することを承認します。YOUR_ENCRYPTION_ROLE_IDを前の手順でコピーしたロールIDに置き換えてください。
{
    "Sid": "Allow VeloDB Access",
    "Effect": "Allow",
    "Principal": {
        "AWS": [ "Encryption role ID " ]
    },
    "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:DescribeKey"
    ],
    "Resource": "*"
}
  1. VeloDB Cloudに戻り、ウェアハウス設定のTransparent Data EncryptionセクションにKey ARNを貼り付け、Rotateをクリックします。

注意：ウェアハウスの運用は完全にKMSキーの可用性に依存するため、KMSキーを削除から保護してください。

運用・保守時間ウィンドウ​

運用・保守時間ウィンドウとは、システムメンテナンスまたはユーザーがスケジュールしたタスク（運用リクエスト）を実行できる時間ウィンドウを指します。 例えば、コアのパッチバージョンを自動アップグレードするよう設定した場合、システムはメンテナンス時間ウィンドウ中にコアバージョンを最新の安定パッチバージョンに自動的にアップグレードします。

デフォルトのメンテナンス時間ウィンドウは毎日02:00 ~ 03:00で、デフォルトのタイムゾーンはUTC+0です。ビジネス条件に応じてSettingsページで変更でき、通常はビジネスの閑散時間に設定します。

time window

各ウェアハウスは個別のメンテナンス時間ウィンドウを設定できます。開始時刻と終了時刻は時間単位でのみ正確で、終了時刻は開始時刻より大きくなければなりません。

コアバージョンのアップグレード​

手動でコアバージョンをアップグレード​

現在のウェアハウスのコアバージョンが古すぎてビジネス要件を満たさない場合や、新機能を体験したい場合は、Settingsページでコアバージョンをアップグレードできます。

Manually Upgrade Core Versionに切り替え、対象バージョンを選択し、Execute NowまたはExecute Laterを選択して確認します。

Execute Nowを選択すると、システムは直ちにコアバージョンアップグレードタスクを実行します

manual upgrading now

Execute Laterを選択すると、「O&M Time Window」または「Other Time Window」を選択でき、システムは指定した時刻にコアバージョンアップグレードタスクを実行します。

スケジュールされたイベントはMessage Centerページで確認できます。スケジュールされた実行時間ウィンドウが適切でない場合は、実行前に変更できます。

manual upgrading later

アップグレードが開始されると、「Running」ウェアハウスステータスが「Upgrading」に変わり、バックグラウンドでバージョンアップグレードプロセスが自動的に完了します。これには約1分かかります。バージョンアップグレードが完了すると、ウェアハウスステータスは「Upgrading」から「Running」に戻ります。

注意:

  1. ウェアハウスに「Running」および「Stopped」以外のクラスターがある場合、今すぐ実行を選択すると手動アップグレードは失敗します。操作前にクラスターステータスが要件を満たしていることを確認してください。
  2. ウェアハウスに未完了のコアバージョンアップグレードタスクがある場合、システムは手動アップグレード操作を実行できません。バージョンアップグレードイベントが完了またはキャンセルされていることを確認してから再試行してください。
  3. コアバージョンのアップグレードは約1分間サービスを中断します。オフピーク時間にアップグレードを実行し、アプリケーションに再接続メカニズムがあることを確認してください。
  4. コアバージョンのアップグレード時、システムは停止状態のクラスターを自動的に開始し、アップグレード完了後に停止状態に自動復元します。

パッチバージョンアップグレードポリシーの設定​

ウェアハウス作成時、またはウェアハウス作成後のSettings > Upgrade Core Version > Patch Version Upgrade Policyで、マイナーバージョンに対して2つの戦略を設定できます：Auto UpgradeまたはManually Upgrade。

  • 「Auto Upgrade」を選択すると、システムはO&M Time Window中にコアバージョンを最新の安定パッチバージョンに自動的にアップグレードします（メジャーおよびマイナーバージョンは依然として手動アップグレードが必要）。スケジュールされたイベントはMessage Centerページで確認できます。スケジュールされた実行時間ウィンドウが適切でない場合は、実行前に変更できます。
  • 「Manually Upgrade」を選択すると、即座に実行するか指定した時間ウィンドウで実行するかも選択できます（選択した対象バージョンにアップグレード）。指定した時間ウィンドウでの実行を選択した場合、スケジュールされたイベントはMessage Centerページで確認できます。スケジュールされた実行時間ウィンドウが適切でない場合は、実行前に変更できます。

patch version upgrading

現在のウェアハウスの削除​

ウェアハウスの削除は高リスク操作であるため、削除の影響を理解し、メール認証コードによる確認が必要です。

Settingsページで現在のウェアハウスを削除できます。

delete-warehouse

警告 ウェアハウスの削除はすべてのリソースとデータの削除を伴い、復旧できません。

現在のBYOCウェアハウスの削除とBYOCインフラストラクチャの破棄​

現在のBYOCウェアハウスがVPC内の最後のウェアハウスの場合、現在のウェアハウスを削除するとBYOCインフラストラクチャも破棄されます。

wh delete last

各クラウドプラットフォームでの削除操作については、以下の手順を参照してください：

AWS​

Deleteをクリック後、5分程度かかる予定ですので、お待ちください。

ウェアハウスが削除された後、Cloud Platformをクリックし、AWS CloudFormationに入り、リソーススタックの削除を続行してBYOC基本環境を破棄します。

1. バケットのクリア

削除対象のリソーススタックに入り、Resourcesタブに切り替え、Bucketを検索し、クリックしてバケットに入り、名前を記憶します。

wh delete 1

バケットリストに戻り、バケットを選択します。Emptyをクリックします。permanently deleteを入力します。Emptyをクリックします。

注意：空のバケット操作は復元できません。操作前に保持すべきファイルがないことを確認してください。

wh delete 2

wh delete 3

2. リソーススタックの削除

リソーススタックに戻り、Deleteをクリックし、削除が完了するまで待ちます。

GCP​

Deleteをクリック後、5分程度かかる予定ですので、お待ちください。

ウェアハウスが削除された後、コマンドをコピーし、Cloud platformをクリックし、GCP CloudShellに入り、リソーススタックの削除を続行してBYOC基本環境を破棄します。

wh delete 1

wh delete 2

wh delete 3

実行結果でResources: xx destoryedが表示され、xxが0でない場合、リソースの破棄が成功したことを意味します。そうでなければ、Get Helpをご利用ください。

Azure​

Deleteをクリック後、5分程度かかる予定ですので、お待ちください。

ウェアハウスが削除された後、Cloud Platformをクリックし、Azure Deployment Stacksに入り、リソーススタックの削除を続行してBYOC基本環境を破棄します。

Delete stackをクリックします。Update behaviourでDelete all resources, detach resource groups and management groupsを選択します。Nextをクリックします。

wh delete 1

スタック名を入力し、Deleteをクリックします。

wh delete 2