Mastering GaussDB T: Planning Single‑Node, HA, and Distributed Architectures

Software Architecture Overview

GaussDB T provides three deployment models: single‑node , primary‑standby , and distributed . All models share the core components ETCD, DN (DataNode) and CM (Cluster Manager). The distributed model adds GTS (global transaction service) and CN (Coordinator Node). Any architecture can be managed with the Database Manager (DM) tool and accessed via Data Studio.

Component Summary

The essential components and their roles are:

ETCD : key‑value store that provides the foundation for CM coordination.

CM : handles failover and high‑availability orchestration.

DN : stores data shards; each DN belongs to a replica group.

CN : query entry point; one CN per host (max 10).

GTS : provides ACID guarantees for distributed transactions (single‑master‑single‑standby only).

Understanding CN and DN in a Distributed Cluster

An example 5‑node cluster consists of three CNs and three DNs distributed as follows:

Three DN replica groups, each with two replicas. Primary DNs run on hosts 1‑3, secondary replicas on hosts 3‑5, yielding three data shards.

Three CNs are reachable on hosts 1, 2 and 4, allowing client connections to any CN.

To store data, a table is created with a HASH distribution on the ID column. After inserting eight rows, the data distribution across the three DNs was observed as 5, 2, 1 rows respectively. Attempting to create a unique index on a non‑sharding column fails with error GS‑00101, confirming that unique constraints must include all shard columns.

Planning Single‑Node and Primary‑Standby Architectures

Single‑node : All components (ETCD, CM, DN) are installed on a single host.

Primary‑standby :

Deploy a floating IP that can be moved between primary and standby to minimise service interruption.

Set QUORUM_ANY = 1 in the configuration to enable high‑availability with the “maximum available” policy.

ETCD instances are unevenly distributed (two on one host, one on the other) due to the two‑node topology.

Planning Distributed Architecture

Determine whether GTS is required. GTS provides ACID for distributed transactions but supports only a one‑master‑one‑standby deployment.

Consider GBP (global buffer pool). GBP requires RDMA support; without RDMA it cannot be used.

Decide the number of CN nodes. Each CN occupies a separate host; the cluster becomes unavailable if all CNs fail. Huawei recommends no more than ten CNs.

Select the DN synchronization protocol in clusterconfig.xml via the datanodeType parameter: DN_ZENITH_ZPAXOS – GS‑Paxos protocol, high reliability, requires at least two standby nodes (max 8). DN_ZENITH_HA – Quorum protocol, higher flexibility, supports 1‑9 standby nodes.

Configuration diagrams for each architecture are illustrated in the original article (images retained below).

Download and Documentation

GaussDB T binaries are distributed exclusively through Huawei’s official channels. Documentation can be downloaded from the Huawei support site:

https://support.huawei.com/carrier/productNewOffering?col=product&path=PBI1-21430725/PBI1-21430757/PBI1-21431665/PBI1-250430182/PBI1-250399837

Images: