GBase 8s High Availability Quartet: RHAC Remote High-Availability Cluster – Extending the Reach of High Availability

Published on 2026-05-14

GBase 8s High Availability Quartet | Part Two
RHAC – Remote High-Availability Cluster

The first part of the 'GBase 8s High Availability Quartet' introduced HAC same-city protection – dual-node primary/standby with sub-second failover. However, same-city disaster recovery has a fatal weakness: a fire, earthquake, or tsunami could wipe out the same-city data center entirely. That's when you need an offsite insurance policy. RHAC is GBase 8s's thousand-mile mirroring technology: the primary node is in Guangdong, and the secondary node can be deployed in Jiangsu, Zhejiang, Hubei, or even Inner Mongolia – hundreds to thousands of kilometers apart, data synchronizes seamlessly, and business continues without interruption.

Async First: Zero Burden on the Primary Node

The most significant difference between RHAC and HAC, in a nutshell: HAC guards the same city, RHAC spans thousands of miles; HAC offers three synchronous modes, while RHAC relies solely on asynchronous replication.

Why only asynchronous? Because over long distances, waiting for confirmation before committing is too slow. RHAC uses the SMX asynchronous communication framework, minimizing impact on the primary server – the primary node simply sends logs without waiting for RHAC acknowledgment. In full-duplex mode, the sending thread does not wait for the previous acknowledgment before pushing the next buffer, resulting in minimal performance overhead.

In other words, the primary node barely notices RHAC's existence, much like an 'offsite auto-renewal insurance policy' for your database – with extremely low premiums (performance overhead) and sky-high coverage (disaster recovery capability).

Readable and Shareable: More Than Just 'Cold Backup'

The RHAC secondary node is not just a decoration – it is readable, capable of handling some query workloads and offloading read pressure from the primary. When combined with the connection manager for load balancing, query traffic can be distributed to the secondary node, allowing the primary to focus on writes.

Moreover, RHAC has low bandwidth requirements and can run over standard wide area networks without dedicated fiber lines, saving cost and effort. It handles hardcore disaster scenarios: server software failures, hardware failures, fires, earthquakes, tsunamis – anything a same-city data center cannot withstand, RHAC steps in to cover.

RHAC's Rules: Two 'No-Supports'

Powerful as it is, there are boundaries. RHAC has two 'not supported' features to keep in mind:

  1. No synchronous mode: Asynchronous only, with a slight delay in data sync, unsuitable for financial transaction scenarios requiring strong consistency.

  2. No synchronous checkpoints: The primary node does not wait for RHAC to confirm checkpoints; during failover, a small amount of data may need manual handling.

So RHAC's role is clear: the last line of defense for remote disaster recovery, not a real-time active-active setup, but a 'survive-the-catastrophe' backup plan. Used together with HAC – HAC guards the same city with sub-second failover, RHAC guards the remote site to keep the business alive, completing each other.

RHAC extends the disaster recovery radius from same-city to thousands of miles away, but remote backup is only one piece of the high availability puzzle. What if business demands multiple nodes reading and writing the same data simultaneously, with strong consistency required? How can the architecture evolve further?

Next Part: SSC – The Heavyweight for High-Concurrency