GBase 8s High Availability Series: SSC Shared Storage Cluster – The Hardcore Engine for High Concurrency
GBase 8s High Availability Four-part Series | Part 3
SSC – Shared Storage Cluster
“GBase 8s High Availability Four-part Series” previously covered HAC for same-city protection and RHAC for remote-site survival, both following a “one primary, multiple standby” relay model—the primary runs, and the standbys wait. But what if your business requires all nodes to read and write the same data simultaneously while ensuring strong consistency? SSC is the answer: with just one copy of data, every node pitches in.
One Copy of Data, All Nodes Read and Write
The core idea of SSC is straightforward: all computing nodes share the same storage device—deployed on disk arrays or logical volume managers—so there is only one copy of data with no replication latency. The write node writes logical logs and synchronizes the log sequence number (LSN) to other nodes via the SMX protocol; upon receiving the LSN, other nodes read the corresponding logs from the shared disk, redo them in memory buffers, and do not write back to disk—this ensures data consistency while avoiding redundant disk write overhead.
Under this architecture, any node can read and write, making it a truly “all hands on deck” multi-active setup.
Elastic Scalability: More Queries? Just Add Nodes
One of SSC’s most powerful capabilities is horizontal scaling. As data volumes grow and query loads increase, adding SSC secondary nodes to the cluster increases processing power linearly—handling high-volume OLAP analytical operations and a large number of concurrent queries.
Even better is the fault tolerance mechanism: if a secondary node fails, other nodes automatically take over its workload without service interruption; failover occurs only when the primary node fails, with switchover completed within 5 seconds. This means the larger the cluster, the less impact from a single point of failure—every node adds capacity, and more is always better.
Compared to RAC: Simplicity Prevails
When talking about shared-storage multi-active databases, many think first of Oracle RAC. They appear similar, but the underlying logic is quite different:
In a nutshell: SSC achieves multi-active with “logical logs + shared storage,” offering a simple architecture, secondary node fault tolerance, and flexible scalability; RAC achieves multi-active with “shared memory + dual-primary synchronization,” but has complex architecture and tends to degrade under heavy writes. When replacing Oracle RAC with a China-developed alternative, SSC proves that simplicity is best.
Applicable Scenarios: The Best Partner for Critical Business
SSC is not a cure-all, but it is the optimal solution in the following scenarios:
Core Transactions: For environments requiring strong consistency, global transactions ensure data integrity, while secondary nodes handle read queries
Medium-to-Large Databases (2 TB–100 TB): Shared storage eliminates replication latency; adding nodes for more queries enables elastic scaling
Replacing Oracle RAC with a China-developed database + dual-site three-center architecture: Simple architecture and flexible scalability, combined with HAC + RHAC to realize same-city high availability, remote disaster recovery, and horizontal scaling—a powerful combination for comprehensive coverage
SSC turns “all nodes engaged, shared storage, and elastic scalability” from a slogan into architectural reality. However, the battlefield of high availability extends beyond a single cluster. When data is scattered across different cities and multiple database instances, who will bridge the gap?
Next: ER – The Connecting Thread of High Availability