Centralized and Distributed: KingbaseES's Four Forms Share One Kernel

KingbaseES's centralized family has four members: single-node, ClusterWare primary-standby cluster, RWC read-write separation cluster, and RAC shared-storage cluster. The distributed architecture stacks four modules on this kernel—sharding management, distributed execution, distributed transactions, and global transaction consistency—to form TDC, Sharding, and ADC clusters. One codebase, two shapes.

The Four Centralized Forms

Single-node is the simplest: one instance, one set of storage. Network or node failure puts RTO above 10 minutes; storage failure above 30 minutes; RPO is 0 in all cases. ClusterWare uses a primary-standby structure: two machines each hold a copy of the data. When the primary stops, the standby takes over, and the switchover takes more than a minute. Storage failure is budgeted at half an hour, and there's only one copy of storage.

RWC is read-write separation with one primary and multiple replicas. Writes go to the primary, reads are distributed to replicas. Write response time is about 120% of single-node, RTO is under 1 minute, RPO is 0. Each node stores a full copy of the data, so capacity grows with node count. RAC is shared-storage multi-active: multiple instances attach to the same storage, each can read and write. Normal operation response is about 120% of single-node; conflicting operations that race for the same data across nodes hit about 200%. Storage is a single copy, adding nodes doesn't add storage, and you keep twice the capacity as redundancy. RTO is under 1 minute, RPO is 0. All four forms list 'none' as the application migration cost.

Figure: KingbaseES RAC runtime architecture. The two nodes exchange global cache and lock information through a cluster communication process; a lock manager process handles cross-node concurrency control; a membership manager maintains a globally consistent member list; a failure-handling process is responsible for detection; underneath is the same shared storage.

RAC's Internal Processes and Regions

The official documentation's architecture chapter splits RAC into three layers: the database layer, the cluster file system layer, and the Clusterware layer. The database layer runs service processes and background processes, plus a cluster communication process that exchanges global cache and lock information between nodes. I/O is issued from this layer down to the cluster file system.

The cluster file system layer has a lock manager process and an I/O process. The lock manager handles cross-node concurrency control; the I/O process performs actual data access. The Clusterware layer has two processes: a failure-handling process that detects failures and handles them automatically after an anomaly, and a membership manager that maintains a globally consistent member list. The two layers communicate via node heartbeats.

Shared storage is divided into two zones: the data zone holds database files, and the voting zone is used for arbitration among nodes. The voting zone design is straightforward: when two nodes can't see each other, it decides which one is entitled to continue serving, preventing both from thinking they should be the primary.

On the client side, KingbaseES provides a connection driver that does connection-level load balancing. The documentation is honest about performance: RAC can scale read-write throughput, but operation response time increases compared to a single node. The scaling effect is directly tied to the amount of cross-node access conflicts during use. So its suggestion is to let different business modules access different nodes; when modules are relatively independent in data, conflicts are fewer. Dividing into HR, sales management, call center, the shared area is only a small block of organization structure and personnel info.

Figure: KingbaseES RWC deployment. Applications send writes to the primary and reads to replicas via the JDBC driver; logs are transferred between primary and standby, and each server runs a daemon for health checks and failover.

Seven Steps of RWC Switchover

Walk through the primary-failure scenario; there are seven steps. First, reconnect confirmation. The standby daemon, upon detecting an anomaly on the primary, does not act immediately. It repeatedly reconnects according to reconnect_attempts and reconnect_interval, to rule out false positives from network flapping. Only after the loop ends without reconnection does it proceed.

Second, isolation. The standby first shuts down its own log receiver process and confirms that other standbys have also shut down theirs, ensuring all standbys compete from the same state and no two nodes are still catching up on logs.

Third, election. First check the sync configuration: the all, sync, and custom modes require the standby to be streaming and sync; quorum mode requires streaming and quorum; async mode compares the primary's log write position with the local replay position, and eligibility requires the difference to be less than lsn_lag_threshold. After passing this gate, sorting begins: compare log positions first, the newer wins; if equal, compare priority, higher wins; if still tied, pick the smaller node_id. All three conditions are rigid, no human judgment.

Fourth, majority check. Without a witness node, if visible nodes are fewer than half the total, the election is abandoned; with a witness node configured, the restriction can be relaxed to allow a switchover even when more than half the nodes are down.

Fifth, network confirmation. Ping each gateway in trusted_servers one by one; if none responds, give up promoting. This step prevents split brain: if only the local node's network is cut off, no one else looks alive, and a hasty promotion would cause dual-primary writes.

Sixth, takeover. The order is to attach the VIP first, then run arping; only when both succeed do you promote, and finally do a checkpoint. The VIP is mounted before promote, and during that window business can connect, writes are rejected, and logs show read-only errors. Seventh, watchdog. The entire process is executed by repmgrd, which is watched by kbha; kbha checks the pid file every 3 seconds and restarts the process if missing, while kbha itself is woken by a system cron job every minute.

The documentation also gives formulas for switchover time. The shortest is (reconnect_attempts - 1) * reconnect_interval + 1, plus ping-gateway time and VIP switch time; the longest formula adds monitoring interval, connection timeout, and standby isolation timeout on top of that. Each step's seconds are listed individually.

How Distributed Clusters Arise

On the distributed side, the official documentation states that the distributed extension architecture extends the centralized architecture by adding modules such as sharding management, distributed execution, distributed transactions, and global transaction consistency, supporting TDC, Sharding, and ADC distributed clusters. Distributed capability sits on the same kernel. When data volume is small, deploy as centralized; when the business grows, add the sharding module. The management platform, monitoring, backup tools, and operations habits all carry over, so no new migration assessment is needed.

This is a different route from sharding-and-table-splitting assembly. That approach places several independent single-node databases underneath, with cross-database transactions and global consistency patched in by external middleware, which becomes a separate logic from the database kernel. Here, distributed transactions and global consistency are kernel modules. SQL still follows the same execution path, and the executor and optimizer remain the same.

Figure: Assembly relationship of the same kernel. On the left, the four centralized forms ascend from single-node; on the right, distributed clusters stack sharding management, distributed execution, distributed transactions, and global consistency as four modules on the same kernel.

Costing with Four Variables

Storage capacity, application migration, maintenance effort, and recovery time—these four variables determine the choice. For storage capacity, RWC keeps a full copy per node, so capacity grows linearly with node count; RAC has all instances share a single copy, adding nodes doesn't add capacity, and you keep double the capacity as redundancy.

Application migration: all four forms are 'none'—the deployment shape changes, not the code. Maintenance effort: single-node is marked 'extremely low', the two cluster forms 'low', RAC 'medium'—shared-storage multi-active means managing the cluster, heartbeats, and storage.

Recovery time: single-node is ten-plus minutes; RAC and RWC are under a minute; RPO is 0 for all four forms.

Figure: Recovery capability and cost comparison across the four forms, data from the official documentation's solution comparison table; RTO is measured for network or node failures.

Shortcomings the Documentation Lists Itself

The documentation's limitations and constraints section notes two gaps in this version: incomplete isolation-level support—SSI is not available—and the async notification feature is not implemented. For conflict-heavy cross-node workloads, you'll need to re-plan module distribution; conflicting operations will respond at 200% of single-node.

On the distributed side, three things must be designed: how to choose a shard key, how to split cross-shard transactions, and how to build global indexes. No tool does this for you.

For the decision, three questions give you the answer: will data volume stably exceed the TB level in three years, is there a clear expectation of 10k-level concurrency, and does your team have anyone who has actually managed a distributed cluster? If all three are no, start centralized; the same kernel can add modules later. If any is yes, you don't need to switch products—just add modules. When you do reach the switchover point, budget three costs ahead of time: cutover window, code rewriting, and retraining.