DB Instance Types

Updated on 2025-01-08 GMT+08:00

View PDF

Table 1 lists the instance types of GaussDB.

**Table 1** Instance types
Instance Type	Deployment Model	Scale-out Supported	Scenario	Component	Service Processing
Distributed	Independent: Database components are deployed on different nodes. This model is suitable for where high availability and stability are required and the instance scale is large. Combined: Different database components are deployed on the same node. This model is only available for instances of the basic edition.	Yes	The data volume is large, and large data capacity and high concurrency are required.	OM CM GTM ETCD CN DN	An application sends a SQL query request to a CN. The CN uses the optimizer of the database to generate an execution plan and sends the plan to DNs. Each DN processes data based on the execution plan. After the processing is complete, DNs return the result set to the CN for summary. Finally, the CN returns the summary result to the application.
Centralized	1 primary + 2 standby: 3-node deployment where there is a shard. The shard contains one primary DN and two standby DNs. Single: single-node deployment where there is only one CMS component and one DN. This deployment model is not suitable for production environments. To create a single-replica instance, ensure that the instance version is V2.0-2.2 or later. The availability (SLA) cannot be guaranteed because the instance is deployed on a single server. 1 primary + 1 standby + 1 log: 3-node deployment where there is a shard. The shard contains one primary DN, one standby DN, and one log-dedicated DN. The log node is used only to store logs and does not incur fees, which reduces costs and resource consumption.	No	The data volume is small and stable, and data reliability and service availability are extremely important.	OM CM ETCD DN	An application sends a task directly to the DN, and the DN returns the result to the application after processing the task.

NOTE:

OM: The Operation Manager (OM) provides management APIs and tools for routine maintenance and configuration management of the cluster.
CM: The Cluster Manager (CM) manages and monitors the running status of functional units and physical resources in a distributed system, ensuring stable running of the entire system. CM acts as the overseer of the system's health, regularly assessing the status of DNs to ensure optimal performance. Once an issue arises, the CM takes corrective measures, like restarting a DN or promoting a standby DN to primary.
GTM: The Global Transaction Manager (GTM) generates and maintains the global transaction IDs, transaction snapshots, timestamps, and sequences that must be unique globally.
ETCD: The Editable Text Configuration Daemon (ETCD) is used for shared configuration and service discovery (service registry and search). ETCD stores metadata information, for example, the status of each DN. The CM checks in DN statuses with ETCD to stay informed and make management decisions.
CN: A CN receives access requests from applications and returns execution results to clients. It also splits and distributes tasks to different DNs for parallel processing. Each CN can connect to all DNs, and all CNs share the same metadata.
DN: A DN stores business data, performs data queries, and returns execution results.

Introduction Video

Distributed

The following figure shows the logical architecture of a distributed GaussDB instance.

Figure 1 Logical architecture of a distributed instance
Click to enlarge

Deployment models for distributed instances

Independent deployment
In the independent deployment model, database components are independently deployed on different servers. That is, each CN or DN occupies a VM and resources are isolated from each other. Take the default configuration (3 CNs, 3 replicas, and 3 shards) as an example. In the independent deployment model, such configuration requires 12 nodes (VMs) in total, including three CNs and nine DNs, and the cost of independent deployment is relatively high. Figure 2 shows the architecture. This model is suitable for where high availability and stability are required and the instance scale is large.
Figure 2 Architecture of the independent deployment model
Combined deployment
In the combined deployment model, multiple database components are deployed on the same server. For example, the default configuration (3 CNs and 3 DN shards) in this model requires three nodes (VMs) in total, and one CN and three DNs share one VM. Figure 3 shows the architecture. This model is only available for distributed instances of the basic edition. Compared with the enterprise edition, the basic edition offers a lower price and is suitable for users who do not require high performance but are sensitive to costs.
Figure 3 Architecture of the combined deployment model

Centralized

The following figure shows the logical architecture of a centralized GaussDB instance.

Figure 4 Logical architecture of a centralized instance
Click to enlarge

Deployment models for centralized instances

1 primary + 2 standby
The 1 primary + 2 standby deployment model is a 3-node deployment where there is one shard. The shard contains one primary DN and two standby DNs. Figure 5 shows the architecture. This model is only available for centralized instances. Instances deployed using this model are not scalable. This model is suitable for scenarios with small and stable volumes of data, where data reliability and service availability are important.
NOTE:
- If any of primary and standby DNs is faulty, services will not be affected.
- 1 primary + 2 standby instances can be deployed in either of the following modes:
  - 3 replicas, single AZ
  - 3 replicas, 3 AZs
Figure 5 Architecture of the 1 primary + 2 standby deployment model
1 primary + 1 standby + 1 log
The 1 primary + 1 standby + 1 log deployment model is a 3-node deployment where there is one shard with three replicas. The shard contains one primary DN, one standby DN, and one log-dedicated DN. This model is only available for centralized instances. Figure 6 shows the architecture.
Figure 6 Architecture of the 1 primary + 1 standby + 1 log deployment model
Single (also known as single-replica)
The single-replica deployment model is a single-node deployment where there is only one CMS component and one DN. This model is only available for centralized instances. Figure 7 shows the architecture.
Figure 7 Architecture of the single-replica deployment model

NOTE:

The single-replica deployment model is only available to whitelisted users. You can submit a service ticket to request it at Service Tickets > Create Service Ticket in the upper right corner of the management console.

Parent topic: DB Instance Description

Previous topic: DB Instance Description

Next topic: Instance Storage Types

Feedback

Was this page helpful?

Helpful Not helpful

Provide feedback

Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.

The system is busy. Please try again later.

Which of the following issues have you encountered?

Content is inconsistent with the product UI

Unclear descriptions

Lack of examples or code

Incorrect steps

Can't find what I need

Lack of best practices

Feedback (optional)

0/500

Select at least one type of issue, and enter your comments or suggestions.

Enter a maximum of 500 characters.

Submit Cancel

For any further questions, feel free to contact us through the chatbot.

Chatbot