Choosing the Right Database High‑Availability Architecture: Lessons from GBase 8s

Background and Motivation

Critical business systems require "no data loss, no service interruption". This drives the need for robust high‑availability (HA) mechanisms in database platforms, including domestic Chinese products.

Evolution of Database HA Architectures

Early databases relied on periodic backups and log archiving, exposing a single point of failure. HA was introduced through OS‑level clustering tools (e.g., IBM HACMP). With the growth of the Internet in the 1990s, redundancy and failover mechanisms evolved from simple master‑slave pairs to shared‑storage clusters and finally to distributed clusters.

Oracle pioneered several HA models that later became reference points:

Active Data Guard (ADG) – provides synchronous or asynchronous standby replication with three protection levels (maximum protection, maximum availability, maximum performance).

Real Application Clusters (RAC) – a shared‑everything architecture that allows multiple servers to access a single database instance, delivering both HA and load balancing.

Oracle GoldenGate (OGG) – table‑level real‑time data replication.

GBase 8s HA Architecture Overview

GBase 8s implements a full HA stack that mirrors the Oracle models. The main components are:

HAC / RHAC Cluster – master‑slave configurations with three redo‑log replication modes: synchronous (full data protection, equivalent to ADG maximum protection) near‑synchronous (short latency, equivalent to ADG maximum availability) asynchronous (best performance, equivalent to ADG maximum performance)

RHAC extends HAC to a one‑master‑multiple‑standby topology, using asynchronous transfer and optional compression to reduce bandwidth usage.

SSC (Shared‑Storage Cluster) – a shared‑disk cluster comparable to Oracle RAC. Data resides on a single logical volume that is concurrently readable and writable by up to 16 nodes. SSC guarantees strong consistency and eliminates data duplication. It is recommended for workloads below 100 TB where low latency (10 Gbps + network) is available.

ER (Real‑Time Data Exchange) – table‑level, near‑real‑time synchronization similar to OGG. It is suited for inter‑regional data sharing or cross‑system data exchange.

Technical Characteristics

Replication latency for synchronous mode is sub‑second; asynchronous mode may incur seconds‑level lag depending on network bandwidth.

Failover time for HAC/RHAC is typically 10–15 seconds, achieving RPO = 0 and RTO < 30 seconds in production.

SSC requires a high‑speed heartbeat network (minimum 10 Gbps, with 40 Gbps common in large RAC deployments) to maintain node health checks and lock coordination.

Node count limits: HAC/RHAC – 2 nodes (HAC) or 1 master + N standby (RHAC); SSC – up to 16 nodes; ER – independent of node count, operates on top of any cluster.

Choosing an HA Strategy

Selection should be based on data volume, consistency requirements, network topology, and budget:

Master‑Slave (HAC/RHAC) – suitable for small‑to‑medium datasets (<10 TB) and scenarios where occasional brief consistency windows are acceptable. Advantages: lower hardware cost, simpler deployment. Drawbacks: additional storage for standby copies, longer failover windows for large data sets.

Shared‑Storage (SSC) – ideal for large datasets (10–100 TB) that demand strong consistency and minimal storage overhead. Requires high‑speed inter‑node networking and skilled DBA/ops staff. Provides the best performance‑to‑cost ratio for centralized workloads.

Hybrid Deployments – combining SSC with HAC (same‑city dual‑center) or SSC + HAC + RHAC (two‑city three‑center) can achieve active‑active cross‑region replication with zero RPO.

Representative Deployments

National Grid Dispatch Cloud Platform – 50 TB dataset migrated from Oracle to an SSC + RHAC configuration. Achieved active‑active cross‑region replication, continuous operation > 600 days, and failover within 10–15 seconds.

Shenzhen Metro CLC Phase II – Deployed SSC + HAC to support 4 000 concurrent users and millions of records, delivering millisecond query response times.

Regional Commercial Bank Core System – Adopted SSC + HAC, maintaining uninterrupted service for > 760 days after migration.

Future Enhancements

Planned improvements for GBase 8s HA include:

Finer‑grained resource control to isolate failed transactions while allowing unaffected tables to continue processing.

Session and transaction preservation across failover, reducing application‑level reconnection overhead.

Data sharding within SSC to mitigate write‑write conflicts and improve scalability for datasets exceeding 100 TB.

Key Diagrams