GBase 8s High Availability Quartet: HAC Primary-Standby Replication Cluster — From ‘Running Bare’ to Self-Healing Resilience

Published on 2026-05-12

GBase 8s High Availability Quartet | Part One
HAC — Active-Standby Replication Cluster

Database high availability is never a single choice. Intra-city disaster recovery, geo-distributed active-active, multi-node concurrency, cross-instance synchronization — business continuity demands a complete safety net. GBase 8s brings four aces: HAC, RHAC, SSC, and ER, corresponding to “local protection, remote extension, hardcore concurrency, and cross-domain connectivity,” progressively woven into a panoramic defense that spans from within a cluster to across instances. The GBase 8s High Availability Quartet series delivers four in-depth articles; today we start with the first ace.

The story starts with “running bare.” In the early days, a single database server was simple and direct — but hardware failures, system crashes, and human errors could interrupt service at any moment. A disk failure meant total data loss, and upgrades demanded downtime. The ops team lived with constant nightmares: “If this database goes down, the business is finished!”

Step One: Deploy HAC Intra-City Disaster Recovery Cluster

The primary node handles production workloads while the standby synchronizes logs in real time over the dedicated SMX protocol (round-trip latency of only 10 microseconds) with parallel replay. If the primary fails, the standby takes over in seconds with zero data loss and failover completed in under 8 seconds.
Three synchronization modes are available on demand, much like tiers of courier service:

  • Fully synchronous: commits only after the standby has written, ensuring zero data loss — the top choice for financial transactions

  • Nearly synchronous: commits upon receiving acknowledgment from the standby, offering maximum availability with near-zero data loss, the recommended default

  • Asynchronous: the primary fires and forgets, requiring no standby response, delivering the best performance — the top choice for long-distance disaster recovery

High availability is now in place, but challenges remain: after a failover, only a single node is left. If that node crashes, you’re truly down — and the failed node still requires personnel to travel to the data center for repairs, a real headache in remote locations.

Step Two: Unleash the Ace — the hac_alline Cluster Daemon

The daemon continuously monitors database and network health. In the event of non-hardware failures, it automatically restarts services and rejoins the node to the cluster — completely hands-free. Before bringing a failed node back online, it performs automatic pre-checks to eliminate split-brain scenarios.

This architecture has been deployed at scale across critical infrastructure sectors such as power and water utilities, proving rock-solid reliability.

  • One-click deployment at initialization — cluster ready in minutes, no manual per-node configuration

  • Self-running operations — auto-detection, auto-failover, auto-repair, eliminating manual monitoring

  • 24/7 uninterrupted service, even if the primary crashes, the standby takes over in seconds

  • Zero data loss with dual safeguards of real-time replication and automatic repair

No more late-night runs to the data center, no more holiday alert calls — ops can finally get a full night’s sleep.

At this point, HAC has completed its journey from “running bare” to self-healing resilience — but the high availability landscape extends beyond a single city. When your business spans thousands of miles, can the standby also take on read/write splitting workloads?

Coming up next: “RHAC — Extending the Radius of High Availability”