メインコンテンツまでスキップ
バージョン: 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文字です。

透過的データ暗号化​

セキュリティを強化するため、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キーの可用性に完全に依存するため、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