The Third Weapon of GBase 8a: The Nunchaku – Visual Sync Tool GVR

Published on 2026-05-07

In the data arena, the nunchaku is not a weapon of brute force; it wins through two sections working as one. This is just like the active-active synchronization of GBase 8a MPP Cluster (GBase 8a for short), a cloud-native data warehouse developed by GBase. The weapon we're breaking down in this issue is the visual sync tool GVR, which allows two clusters to operate with the fluidity and control of a nunchaku.

What is GVR?

GVR is GBase's self-developed active-active sync tool, purpose-built for GBase 8a MPP Cluster. It hides the hardcore technologies—like binary file synchronization and metadata snapshots—under the hood, while presenting you with a clean configuration page and a real-time monitoring dashboard. Building active-active with it is just like wielding a nunchaku: easy to pick up, yet astonishingly powerful.

Three Killer Moves – Each Targeting a Core Pain Point

Move 1: Rapid Setup – Say Goodbye to Scripting

In the past, setting up active-active meant writing Python scripts, tweaking crontab, and starting over at the slightest mistake. GVR turns all that into filling out a form: select the source and target clusters in the UI, set a sync interval, click 'Create,' and the job is up and running. Deployment efficiency doubles, and even a novice can get it done in half an hour.

Move 2: High-Performance Sync – Data That Flies

GVR reads and writes binary data files directly at the lower level, bypassing SQL parsing detours, delivering up to 500 MB/s per node. Even more impressive, it supports pre-sync and metadata snapshots: pre-sync transmits the full data once, then subsequent syncs only move the deltas. Metadata snapshots keep the source tables fully readable and writable during sync, with zero impact on your business. It can easily handle active-active clusters at the petabyte scale.

Move 3: Flexible Configuration – Sync Exactly the Way You Want

Different business scenarios demand varied sync requirements: some need metadata replicated alongside data, others only want data; some worry about network congestion and need throttling, while others need to overwrite target tables... GVR turns all these into toggles. Just tick a few checkboxes, and it handles the rest. You decide the sync mode, parallelism, and whether to limit the rate.

Ideal Battlefields: Wherever There's Active-Active, There's GVR

Local and Geo-Redundant Disaster Recovery: With a two-site, three-center deployment, the primary database handles writes while the standby replicates in real time. If the primary fails, the standby takes over within seconds, achieving near-zero RPO and RTO in minutes. This is the solution for large, geographically distributed enterprises and core financial systems.

Read/Write Splitting Active-Active Cluster: During peak loads, write operations are directed to cluster A while reads are offloaded to cluster B. GVR syncs new data from A to B within the time window. A handles all insert/update/delete operations, and B takes care of reports and queries—each cluster operates unhindered, and load is naturally balanced.

Four Core Capabilities: Making Operations Worry-Free

This "nunchaku" called GVR connects the primary cluster on one end and the standby on the other—appearing separate, yet working as one. It lowers the barrier to active-active through a visual interface, ensures real-time data consistency with high-performance sync mechanisms, and adapts to countless business scenarios with flexible configuration. Whether for disaster recovery or read/write splitting, GVR lets you handle both clusters with masterful ease.

Coming up next: The Three Weapons of GBase 8s · Part 1 – stay tuned.