Warehouseを使用する
Warehouseの詳細を確認する
warehouseセレクターでは、確認する権限を持つすべてのwarehouseを表示できます。

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ページでパスワードを初期化またはリセットできます。

警告 パスワードは大文字、小文字、数字、特殊文字~!@#$%^&*()_+|<>,.?/:;'[]"のみをサポートし、そのうち少なくとも3種類を含む必要があり、長さは8-20文字です。
Transparent Date Encryption
セキュリティを向上させるため、warehouse作成時にTransparent Data Encryption (TDE)を有効にして、サービスデータに追加の保護レイヤーを提供できます。

拡張暗号化は現在AWSのwarehouseで利用できます。
TDEが有効になると、warehouseが提供するデフォルトキーに代わって、独自のカスタマー管理KMSキーを使用するように暗号化をアップグレードできます。

-
KMS Keyを作成する:AWS KMSコンソールで新しい対称暗号化キーを作成します。
-
Encryption Role IDをコピーする:管理コンソールで、SettingsページのRotate KMSをクリックし、Encryption Role IDをコピーします。

- Key Policyを更新する:作成した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": "*"
}
- VeloDB Cloudに戻り、warehouseの設定のTransparent Data EncryptionセクションにKey ARNを貼り付け、Rotateをクリックします。
注意: warehouseの操作は完全にKMSキーの可用性に依存するため、KMSキーを削除から保護してください。
運用・保守時間ウィンドウ
運用・保守時間ウィンドウとは、システムメンテナンスやユーザーがスケジュールしたタスク(操作リクエスト)を実行できる時間ウィンドウを指します。 例えば、coreが自動的にパッチバージョンをアップグレードするよう設定した場合、システムはメンテナンス時間ウィンドウ中に自動的にcoreバージョンを最新の安定版パッチバージョンにアップグレードします。
デフォルトのメンテナンス時間ウィンドウは毎日02:00 ~ 03:00で、デフォルトのタイムゾーンはUTC+0です。ビジネス条件に応じてSettingsページで変更できます。通常はビジネストラフの時間帯に設定します。

各warehouseは個別のメンテナンス時間ウィンドウを設定できます。開始時刻と終了時刻は時間単位の精度のみで、終了時刻は開始時刻より後である必要があります。
Tagsを設定する
Tagsはキーと値のペアで構成され、リソースにマークを付けて検索フィルタリング、コスト追跡、アクセス制御などを容易にするために使用されます。
カスタムtagsは自動的にクラウドプラットフォームのリソースtagsに同期されます。特に、clusterが時間ベーススケーリングや手動スケーリング用に設定されている場合、クラウドプラットフォームリソースはtagsを保持できます。
Custom Tagsをクリックして、カスタムtag設定に入ります。

tagの範囲としてWarehouse and ClustersまたはClusterを選択し、tagキーとtag値を入力し、OKをクリックしてtag設定を完了します。
-
Warehouse and Clusters: 現在のwarehouseとclusterの仮想マシンリソースにカスタムtagsを追加します。warehouseで共有されるリソースは追加されません。必要に応じて、クラウドプラットフォームで追加してください。
-
Cluster: 指定されたclusterの仮想マシンリソースにカスタムtagsを追加します。

注意:
- 異なるクラウドプラットフォームでサポートされるtagsの数の上限は異なります。ページの指示に従ってください
- 同じキー名のtagがクラウドプラットフォームに既に存在する場合、tagを追加した後、クラウドプラットフォーム上の対応するtagの値は上書きされます
- 一部のtagsはシステムによって生成されるため、クラウドプラットフォーム上で変更や削除を行わないでください
Coreバージョンをアップグレードする
手動でCoreバージョンをアップグレードする
現在のwarehouseのcoreバージョンが古すぎてビジネス要件を満たさない場合や、新機能を体験したい場合は、Settingsページでcoreバージョンをアップグレードできます。
Manually Upgrade Core Versionに切り替え、対象バージョンを選択し、Execute NowまたはExecute Laterを選択して確認します。
Execute Nowを選択した場合、システムは即座にcoreバージョンアップグレードタスクを実行します

Execute Laterを選択した場合、「O&M Time Window」または「Other Time Window」を選択でき、システムは指定された時間にcoreバージョンアップグレードタスクを実行します。
Message Centerページでスケジュールされたイベントを確認できます。スケジュールされた実行時間ウィンドウが適さない場合は、実行前に変更できます。

アップグレードが開始されると、「Running」warehouseステータスが「Upgrading」に変わり、バックグラウンドで自動的にバージョンアップグレードプロセスが完了します。これは約1分で完了します。バージョンアップグレードが完了すると、warehouseステータスは「Upgrading」から「Running」に戻ります。
注意:
- warehouseに「Running」と「Stopped」以外のclusterがある場合、今すぐ実行を選択すると手動アップグレードが失敗します。操作前にclusterステータスが要件を満たしていることを確認してください。
- warehouseに未完了のcoreバージョンアップグレードタスクがある場合、システムは手動アップグレード操作を実行できません。バージョンアップグレードイベントが完了またはキャンセルされていることを確認してから再試行してください。
- coreバージョンのアップグレードはサービスを約1分間中断します。オフピーク時間にアップグレードを実行し、アプリケーションに再接続メカニズムがあることを確認してください。
- coreバージョンをアップグレードする際、システムは停止状態のclusterを自動的に開始し、アップグレード完了後、システムは自動的に停止状態に復元します。
パッチバージョンアップグレードポリシーを設定する
warehouseを作成する際、またはwarehouse作成後に、Settings > Upgrade Core Version > Patch Version Upgrade Policyで、マイナーバージョンに対してAuto UpgradeまたはManually Upgradeの2つの戦略を設定できます。
- 「Auto Upgrade」を選択した場合、システムはO&M Time Window中にcoreバージョンを最新の安定版パッチバージョンに自動アップグレードします(メジャーバージョンとマイナーバージョンは手動アップグレードが必要です)。Message Centerページでスケジュールされたイベントを確認できます。スケジュールされた実行時間ウィンドウが適さない場合は、実行前に変更できます。
- 「Manually Upgrade」を選択した場合、即座に実行するか、指定した時間ウィンドウで実行するかも選択できます(選択した対象バージョンにアップグレード)。指定した時間ウィンドウで実行することを選択した場合、Message Centerページでスケジュールされたイベントを確認できます。スケジュールされた実行時間ウィンドウが適さない場合は、実行前に変更できます。

現在のWarehouseを削除する
warehouseの削除は高リスク操作であるため、削除の影響を理解し、メール認証コードで確認していただく必要があります。
Settingsページで現在のwarehouseを削除できます。

警告 warehouseの削除は、そのすべてのリソースとデータの削除を伴い、復旧できません。
現在のBYOC warehouseを削除し、BYOCインフラストラクチャを破棄する
現在のBYOC warehouseがVPC内の最後のwarehouseである場合、現在のwarehouseを削除するとBYOCインフラストラクチャも破棄されます。

各クラウドプラットフォームでの削除操作については、以下の手順を参照してください:
AWS
Deleteをクリックした後、5分程度かかる予定ですので、しばらくお待ちください。
warehouseが削除された後、Cloud Platformをクリックし、AWS CloudFormationに入り、リソーススタックを削除してBYOC基本環境を破棄します。
1. bucketをクリアする
削除するリソーススタックに入り、Resourcesタブに切り替え、バケットを検索し、クリックしてbucketに入り、名前を記憶します。

bucketリストに戻り、bucketを選択します。Emptyをクリックします。permanently deleteを入力します。Emptyをクリックします。
注意: bucket空操作は復元できません。操作前に保持すべきファイルがないことを確認してください。


2. リソーススタックを削除する
リソーススタックに戻り、Deleteをクリックし、削除の完了を待ちます。
GCP
Deleteをクリックした後、5分程度かかる予定ですので、しばらくお待ちください。
warehouseが削除された後、コマンドをコピーし、Cloud platformをクリックし、GCP CloudShellに入り、リソーススタックを削除してBYOC基本環境を破棄します。



実行結果でResources: xx destoryedが表示され、xxが0でない場合、リソースが正常に破棄されたことを意味します。そうでない場合は、Get Helpしてください。
Azure
Deleteをクリックした後、5分程度かかる予定ですので、しばらくお待ちください。
warehouseが削除された後、Cloud Platformをクリックし、Azure Deployment Stacksに入り、リソーススタックを削除してBYOC基本環境を破棄します。
Delete stackをクリックします。アップデート behaviourでDelete all resources, detach resource groups and management groupsを選択します。Nextをクリックします。

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