GBase 8a Mirror Cluster: Using Fewer High‑Spec Nodes for Backup

In a GBase 8a mirror cluster, the standard recommendation is to keep the primary and backup clusters topologically identical. However, for real‑time backup scenarios, you can use a smaller number of high‑capacity nodes for the backup cluster. This guide demonstrates a working configuration with a 3‑node cluster in a gbase database, where the primary cluster has 2 nodes and the backup cluster has only 1 node.

Test Environment

Three nodes are split into two virtual clusters:

• VC1: 2 nodes (101, 102), each with 1 primary shard (p1 d0), giving a total of 2 primary shards.
• VC2: 1 node (115), configured with 2 primary shards (p2 d0), also giving a total of 2 primary shards.

The prerequisites for mirroring are met because:

• Both VCs have the same number of primary shards (2).
• The hashmaps are identical (VC2 initialises its nodedatamap from VC1).

Creating the Mirror Database

Initialise the hashmaps and set up the mirror relationship:

-- Initialise VC1
USE VC vc1;
INITNODEDATAMAP;

-- Initialise VC2 from VC1 to ensure identical hashmaps
USE VC vc2;
INITNODEDATAMAP FROM vc1;

-- Create the database on both VCs
CREATE DATABASE vc1.testdb;
CREATE DATABASE vc2.testdb;

-- Set VC1.testdb to mirror to VC2
ALTER DATABASE vc1.testdb SET DEFAULT MIRROR = vc2;

-- Verify the mirror relationship
SHOW MIRROR DATABASES;

The output confirms that testdb now has MIRROR_VC = vc2, indicating the mirror is active.

Verifying Mirror Replication

Create a table and insert data on VC1, then check that it appears on VC2:

USE VC vc1;
USE testdb;

CREATE TABLE t1(id INT, name VARCHAR(100));
INSERT INTO t1 VALUES(1, 'From vc1');

-- Query on VC1
SELECT * FROM vc1.testdb.t1;
-- Output: | 1 | From vc1 |

-- Query on VC2 — data is automatically synchronised
SELECT * FROM vc2.testdb.t1;
-- Output: | 1 | From vc1 |

Key Prerequisites for Mirroring

• Equal number of primary shards: Both VCs must have the same total count of primary segments.
• Identical hashmaps: VC2 must be initialised with initnodedatamap from vc1, ensuring that the nodedatamap table has the same data_distribution_id count and content on both sides.

You can verify hashmap consistency with this query:

SELECT DISTINCT(res.r), COUNT(res.r)
FROM (
    SELECT COUNT(*) r
    FROM gbase.nodedatamap t
    WHERE t.data_distribution_id IN (1, 2)
    GROUP BY t.hashkey, t.nodeid
) res
GROUP BY res.r;

A correct setup returns a single row with count(res.r) = 65536, confirming the hashmaps match.

This configuration proves that a gbase database mirror cluster can operate with an asymmetric topology — fewer backup nodes — as long as the shard count and hashmap alignment rules are strictly followed. This approach saves hardware while still providing real‑time data protection.