Hologres:Convert general purpose instances to virtual warehouse instances

General-purpose instances

A general-purpose instance has only one endpoint. After converting it to a virtual warehouse instance, the endpoint will remain unchanged, and metadata information such as user permissions within the instance will also remain the same.

To convert a general-purpose instance to a virtual warehouse instance, you only need to submit a ticket or join the Hologres DingTalk group to apply for a conversion and provide the instance ID and operation time. Hologres O&M engineers will convert the instance to a virtual warehouse instance in the background. For more information about the subsequent business isolation operations, see (Recommended) Load isolation.

Primary/Secondary instances (with the primary instance as a general-purpose instance)

Hologres primary/secondary instances adopt a multi-endpoint load isolation architecture, while virtual warehouse instances use a single-endpoint load isolation architecture.

To convert a primary instance to a virtual warehouse instance, you must first migrate the query traffic of the associated read-only secondary instances to the primary instance and then disassociate or release the read-only secondary instances. For more information, see Instances. This way, the primary instance becomes a regular general-purpose instance. Then, you can submit a ticket or join the Hologres DingTalk group to apply for a conversion and provide the instance ID and operation time. Hologres O&M engineers will convert the instance to a virtual warehouse instance in the background.

Instance parameter changes

The following table describes the impacts on core parameters after the instance type is changed.

(Important) Alert rule configuration

If you change the instance type from general-purpose to virtual warehouse for an instance, the instance in the CloudMonitor console is moved from the Hologres standard instance tab to the Hologres warehouse instance tab. The directory update latency in the CloudMonitor console is approximately 10 minutes.

• If no alert rules are configured for the instance, we recommend that you configure alert rules for key business metrics of the instance. For more information about how to configure alert rules, see the Configure alert rules section of the "CloudMonitor" topic.

• If alert rules have been configured for the instance, reconfigure alert rules for the instance after the instance type change on the Hologres warehouse instance tab in the CloudMonitor console. You can also configure new alert rules based on the metrics of the virtual warehouse instance, such as gateway-related metrics.

(Recommended) Load isolation

• Identify business scenarios and isolate loads. For more information, see Manage virtual warehouses.

• Grant permissions to users and allocate resources. For more information, see Manage permissions on virtual warehouses.

• Grant permissions on table groups that are loaded to virtual warehouses. For more information, see Manage data permissions.

To prevent impacts on your business during the change, we recommend that you scale up and then scale down your Hologres instance to isolate your loads. In this example, a general-purpose instance with 128 CUs is used. To change the instance type and isolate loads for the instance, perform the following operations:

1. Contact O&M engineers of Hologres to change the instance type.

   After the instance type is changed, the amount of reserved computing resources of the virtual warehouse instance is 128 CUs. All 128 CUs are allocated to the default init_warehouse virtual warehouse.

2. Scale up the instance based on your business requirements. For more information, see the Scale up a virtual warehouse section of the "Manage virtual warehouses" topic.

   For example, you increase the reserved computing resources of the instance to 192 CUs, and the amount of unallocated computing resources is 64 CUs. During the scale-up, you can use the default virtual warehouse init_warehouse as expected.

3. Create multiple virtual warehouses based on your business requirements. For more information, see the Create a virtual warehouse section of the "Manage virtual warehouses" topic.

   For example, you can create a virtual warehouse named warehouse_olap that has 32 CUs for online analytical processing (OLAP) and a virtual warehouse named warehouse_serving that has 32 CUs for online services.

4. Perform operations such as granting permissions to users and granting permissions on table groups that are loaded to virtual warehouses, and switch the related business traffic to the created virtual warehouses.

5. Scale down the instance based on your business requirements. For more information, see the Scale down a virtual warehouse section of the "Manage virtual warehouses" topic.

   For example, you can decrease the computing resources of the virtual warehouse init_warehouse to 64 CUs. During the scale-down, you can use other two virtual warehouses as expected. Then, you can decrease the reserved computing resources of the instance from 192 CUs to 128 CUs. During the scale-down, you can use all virtual warehouses as expected.

6. Complete the load isolation.

(Optional) Enable features

You can separately enable the following features for a single virtual warehouse based on your business requirements:

• Time-specific scaling of virtual warehouses. For more information, see Scheduled scaling (beta).

• Serverless Computing. For more information, see Serverless Computing.