DB Instance Types
Table 1 lists the instance types of GaussDB.
|
Instance Type |
Deployment Model |
Scale-out Supported |
Scenario |
Component |
Service Processing |
|---|---|---|---|---|---|
|
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: 3-node deployment where there are three shards and each shard contains one primary DN and two standby DNs. |
Yes |
The data volume is large, and large data capacity and high concurrency are required. |
|
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. |
|
|
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. |
|
An application sends a task directly to the DN, and the DN returns the result to the application after processing the task. |
- 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.
Distributed
- 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.
- 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 DNs) 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.
Centralized
- 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.
- 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
- 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.
- 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.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot
