GBase 8s High Availability Cluster Architecture
For mission-critical business applications in certain industries, 24/7 uninterrupted service is a must. This requires the database to have high availability to avoid single points of failure at database nodes. The choice of database high availability architecture directly impacts the level of service availability for business applications. Mission-critical applications in typical industries demand extremely high availability, i.e., 99.999% availability.
Oracle has introduced various high availability architectures such as host HA (Highly Available), ADG (Active DataGuard), RAC (Real Application Cluster), and OGG (Oracle GoldenGate). These HA architectures can be used individually or in combination. Many financial institutions have leveraged combinations of Oracle's HA architectures to build extremely high availability business services with a two-site, three-center deployment model.
In the push towards domestic database substitution, homegrown databases must reach parity or even breakthroughs in high availability technology to gradually replace mission-critical systems across all sectors. Currently, most Chinese database vendors have built comprehensive HA architectures modeled after Oracle. GBase 8s, for instance, offers a complete HA technology stack comparable to Oracle's to ensure high availability for industry business systems.
GBase 8s Primary-Standby Cluster
GBase 8s provides primary-standby clusters based on real-time redo log synchronization and replay. Data transmission between the primary and standby nodes supports multiplexed connections, reducing network resource requirements and improving communication efficiency between servers.
The primary-standby cluster supports two modes: HAC and RHAC.
HAC is a typical primary-standby cluster mode with one primary and one standby. It supports three redo log replication modes—fully synchronous, near-synchronous, and asynchronous—based on network conditions, perfectly matching Oracle ADG’s Maximum Protection, Maximum Availability, and Maximum Performance modes.
Fully synchronous: When a transaction completes on the primary node, its redo log must be copied to the standby node before commit. The standby node receives and replays the redo log, and only after the replay completes on the standby do both nodes commit together. The biggest advantage is guaranteed transaction reliability—once a transaction is successful, its redo log has been written successfully on both primary and standby.
Near-synchronous: When a transaction completes on the primary node, its redo log is sent over the network to the standby. Once the standby confirms receipt of the redo log, the transaction commits on the primary immediately.
Asynchronous: After a transaction completes on the primary node, the redo log is sent to the standby node without waiting for any acknowledgment before commit. However, at checkpoint time, the cluster compares the checkpoints on the primary and standby to ensure consistency. In other words, the database allows asynchronous operation between two checkpoints, but the checkpoints themselves must be consistent across nodes.
For HAC cluster deployment, a dual-NIC server configuration is recommended, with business traffic going through the north-south interface and redo log synchronization traffic through the east-west interface.
HAC cluster features:
1. Simple deployment with data redundancy;
2. Transparent database access for applications;
3. Failover completed within 30 seconds;
4. Flexible choice of data synchronization modes;
5. Both primary and standby nodes support read and write operations.
HAC cluster use cases:
1. Recommended for deployments in the same rack, same server room, or same city, as network latency is a key factor for HAC clusters;
2. Suggested for data sizes up to 10 TB, considering the limitations of single-server disk capacity.
RHAC clusters are another form of GBase 8s cluster, supporting one primary with multiple standbys, primarily used for long-distance data transfer and remote disaster recovery scenarios. RHAC uses a typical asynchronous transmission mechanism: the primary node accepts and processes transactions and continuously sends redo logs to the target nodes without waiting for acknowledgment or checkpoint alignment. Only after the target node replays the redo log does it return the redo log position information to the primary.
RHAC cluster features:
1. Replication via database redo log ensures that during standby recovery, the standby can automatically catch up from the last checkpoint, guaranteeing data integrity and consistency between primary and standby nodes;
2. Minimal impact on primary node performance;
3. Transparent application access;
4. Failover completed within 30 seconds;
5. Both primary and standby nodes can read and write.
RHAC cluster use cases:
1. Long-distance data transfer or remote disaster recovery scenarios;
2. Tolerant of network latency and bandwidth constraints.
HAC and RHAC deployment architecture:
Connection Manager (CM)
The Connection Manager (CM) is a built-in database cluster management component of GBase 8s. It serves two purposes: handling application client connections to GBase 8s and managing failure detection and failover for the database cluster.
The component can be deployed independently or collocated with the database. To avoid a single point of failure, multiple CMs can be deployed.
GBase 8s Shared Storage Database Cluster
For large-scale business systems, shared storage-based two-node or multi-node database clusters are commonly used to support high availability. GBase 8s Shared Storage High Availability Cluster (SSC) uses shared disks for node high availability with only one copy of data, effectively utilizing hardware resources and avoiding data duplication. The shared storage supports both disk arrays and distributed storage, and I/O devices can be raw devices or shared file systems.
The cluster uses a peer-management model where queries access local cache, incurring no network overhead and providing good linear scalability, with up to 16 nodes, all fully read-writable. When the primary node fails, a secondary node can be promoted to primary to ensure high availability.
SSC cluster features:
1. RAC-like technology, shared storage, ensuring strong data consistency;
2. Transparent application access;
3. All nodes in the cluster support read and write;
4. Cluster failover completed within 30 seconds;
5. For business scenarios with data up to 100 TB, SSC is the most cost-effective database cluster solution compared to distributed databases.
SSC cluster use cases:
1. Business scenarios with data sizes between 10 TB and 100 TB;
2. Scenarios where a single node or primary-standby cluster capacity is insufficient.
Deployment architecture:
For mission-critical systems with stricter SLA requirements, GBase 8s also offers a two-site, three-center high availability solution. Deployment architecture:
As shown, the primary site employs a 4-node SSC cluster, an HAC node is deployed in the same-city disaster recovery site, and an RHAC disaster recovery node is deployed in the remote site, perfectly realizing a two-site, three-center deployment architecture.
Applications access the database cluster through the CM, remaining unaware of the cluster's deployment details, which adds a layer of security for the database.
When the primary node fails, one SSC node is automatically promoted to primary and takes over services, while other nodes automatically resynchronize with the new primary without manual intervention. A failure of a standby node does not affect access to the database cluster or the continuous operation of services.
GBase 8s Real-Time Data Exchange and Sharing Cluster
GBase 8s includes built-in table-level real-time data synchronization capabilities, comparable to Oracle GoldenGate (OGG).
Features of this capability:
1. The database can have two or more nodes, each fully read-writable;
2. Table synchronization supports unidirectional and bidirectional modes;
3. Supports full-row data synchronization as well as specific column synchronization;
4. Supports full and incremental synchronization with resumable transfers;
5. Supports fast data comparison;
6. When a node fails, business systems can switch to other nodes in under 1 second, maximizing business continuity;
7. Supports one-click deployment;
8. Table replication capability can be used to connect two database clusters, enabling active-active cluster capability.
Use cases for this capability:
1. Field or unattended environments requiring minimal database intervention;
2. Scenarios demanding extremely short database switchover times;
3. Real-time data exchange and sharing across ministry, provincial, city, and county levels;
4. Real-time data exchange and sharing between parallel units.