メインコンテンツまでスキップ
バージョン: 26.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 Data Encryption​

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

enable-tde

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

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

tde-settings

  1. ​KMSキーの作成：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キーを削除から保護してください。

運用保守時間枠​

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

デフォルトのメンテナンス時間枠は毎日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で、マイナーバージョンに対してAuto UpgradeまたはManually Upgradeの2つの戦略を設定できます。

  • 「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