Help Center/ GaussDB(DWS)/ Service Overview/ Restrictions
Updated on 2024-12-27 GMT+08:00
View PDF
Share

Restrictions

This document describes the constraints and precautions of using the key functions of GaussDB(DWS).

After creating a GaussDB(DWS) cluster, you do not need to perform basic database O&M operations, such as HA and security patch installation. However, you need to pay attention to the following:

Table 1 GaussDB(DWS) constraints

Item

Constraint

Creating a Cluster
  • The number of nodes in a new cluster cannot exceed the quota that can be used by a user or 256. If the node quota is insufficient, click Increase quota to submit a service ticket and apply for higher node quota.
  • After a cluster is created, its type cannot be changed. For details about the differences between product types, see Data Warehouse Types.
  • You are advised to purchase a cluster in yearly/monthly mode. After the monthly package expires, the cluster will automatically be released.

Connecting to a Cluster
  • If you use a client to connect to a cluster, its VPC subnet must be the same as that of the cluster.
  • You can manage clusters only and cannot directly access nodes in a cluster. You can use a cluster's IP address and port to access the database in the cluster.

SQL Syntax Changes
  • A storage-compute coupled data warehouse (standalone) does not support full-text search, OBS and HDFS foreign table import and export, automatic partition creation, sequence, and related functions.
  • A storage-compute coupled data warehouse (standalone) has only one DN. Therefore, the distribution rule is ignored and cannot be modified.
  • If you copy commands from the document to the operating environment, the text wraps automatically, causing command execution failures. To solve the problem, delete the line break.
  • You are advised to create databases as required. Do not use the default gaussdb database of a cluster.

Changing Flavor
  • Only clusters of version 8.1.1.300 or later support flavor change.
  • Currently, only offline flavor chage is supported. The change takes about 10 minutes.
  • If your cluster is created using local disks or compute-storage integration, you cannot change the flavor of the cluster. If you need nodes with a higher flavor, create a new cluster. Elastic specification change is supported only for storage-compute coupled clusters with cloud SSDs. You can choose Change node flavor to enable elastic specification change.
  • The new flavor of a yearly/monthly cluster is billed in yearly/monthly mode by default.
  • If the cluster is billed in yearly/monthly mode, the Change all specifications option is not supported.
  • The new cluster does not incur charges before the change completes. The old cluster enters the retention period and will not incur charges after the change completes.
  • The Change all specifications option is available only for storage-compute coupled clusters, not for standalone systems. Logical clusters do not support classic changes.
  • A cluster can have up to 240 nodes. The old and new clusters can have up to 480 nodes in total.
  • Disk capacity expansion can be performed only for storage-compute coupled data warehouses with cloud SSDs. Only version 8.1.1.203 and later are supported.
  • Disk capacity can be expanded only if the cluster is in Available, To be restarted, Read-only, or Node fault, Unbalanced state.

Scaling Out
  • If a cluster is billed in yearly/monthly mode, new nodes in the cluster will also be billed in this mode.
  • When you scale out a storage-compute coupled data warehouse cluster, use the same storage specifications as the cluster.
  • Nodes cannot be added to a storage-compute coupled data warehouse (standalone).
  • The cluster redistribution function is supported in 8.1.1.200 or later cluster versions.
  • This function can be manually enabled only when the cluster task information displays To be redistributed after scale-out.
  • Scale-in is supported only by clusters of version 8.1.1.300 and later. For clusters in yearly/monthly billing mode, the function is supported only in version 8.2.1 and later.
  • By default, scaled in nodes are charged by quantity.
  • When you scale in a storage-compute coupled data warehouse cluster, you can only modify the same storage specifications as used by the cluster.
  • A storage-compute coupled data warehouse (cluster mode) cannot be scaled in to a standalone cluster.

Backing Up a Cluster
  • The new GaussDB(DWS) cluster created based on the snapshot must have the same configurations as the original cluster. That is, the number and specifications of nodes, memory, and disks in the new cluster must be the same as those in the original cluster.
  • If you create a new cluster based on a snapshot without modifying parameters, the parameters of the new cluster will be the same as those of the snapshot.
  • A storage-compute coupled data warehouse (standalone) does not support snapshots.
  • During snapshot creation, do not perform the VACUUM FULL operation, or the cluster may become read-only.
  • Snapshot creation affects disk I/O performance. You are advised to create snapshots during off-peak hours.
  • During the snapshot creation, some intermediate files are retained, which occupy extra disk space. Therefore, avoid peak hours and ensure that the disk capacity usage is less than 70%.
  • Snapshots can be restored to the current cluster, but logical clusters and resource pools cannot be restored to the current cluster.

Version Upgrade
  • Cluster 8.1.1 and later versions allow users to deliver cluster upgrade operations on the console.
  • If the cluster is interrupted for a long time due to a node fault or system upgrade, contact technical support.

Data Migration
  • Ensure that no Chinese characters are contained in paths used for importing data to or exporting data from OBS.
  • Data cannot be imported to or exported from OBS across regions. Ensure that OBS and the GaussDB(DWS) cluster are in the same region.

Failover
  • When the DR task is created, the snapshot function of the production cluster is normal, but that of the DR cluster is disabled. Besides, snapshot restoration of both clusters is disabled.
  • DR does not synchronize data from external sources.
  • DR management refers to dual-cluster DR under the same tenant.
  • The DR cluster and the production cluster must be logically homogeneous and in the same type and version.
  • The production cluster and DR cluster used for intra-region DR must be in the same VPC.
  • In intra-region DR, after services are switched over from the production cluster to the DR cluster, the bound ELB is automatically switched to the new production cluster. During the switchover, the connection is interrupted for a short period of time. Do not run service statements to write data during the switchover.
  • During intra-region DR, the EIP, intranet domain name, and connection IP address of the original production cluster are not automatically switched with the cluster switchover. The EIP, domain name, or IP address used for connection in the service system need to be switched to the new cluster.

Hot and Cold Data Management
  • A storage-compute coupled data warehouse (standalone) does not support cold and hot partition switchover.
  • Currently, cold and hot tables support only column-store partitioned tables of version 2.0. Foreign tables do not support cold and hot partitions.
  • Only hot data can be switched to cold data. Cold data cannot be switched to hot data.
  • A partition on a DN is either hot or cold. For a partition across DNs, its data on some DNs may be hot, and some may be cold.
  • Only the cold and hot switchover policies can be modified. The tablespace of cold data in cold and hot tables cannot be modified.