How to Block User Access on a Specific GBase 8a Coordinator Node

In a gbase database cluster, all coordinator nodes (gcluster) are peers and store identical user authentication data. If you need to temporarily block access to a specific coordinator — for maintenance or security reasons — you can modify the local password hash on that node. This method only affects new connections and does not propagate to other nodes.

How It Works

Each gcluster node stores user password hashes in its local gbase.user table. Replacing a user's password hash with an arbitrary value causes all subsequent login attempts on that node to fail. Existing connections remain active but can be manually killed if needed.

Important: Only apply this to non‑DBA accounts. If you accidentally change the password for root or gbase, you will lock yourself out of that node entirely. The only recovery path is to copy the user table files from a healthy node and restart the gcluster service. Always back up the password hashes before making changes.

Step‑by‑Step

1. Save the Current Password Hashes

From a healthy coordinator, export the password hashes so you can generate a recovery script.

-- View the hash for a specific user
SELECT password FROM gbase.user WHERE user = 'testdb';

-- Generate recovery statements for all users
SELECT CONCAT('UPDATE gbase.user SET password=\'', password, '\' WHERE user=\'', user, '\';') sq
FROM gbase.user;
SELECT 'FLUSH PRIVILEGES;';

2. Modify the Local Password on the Target Node

Log into the coordinator you want to restrict and run an UPDATE on the target user. The new "password" can be any string that doesn't match the original hash.

-- Replace with a random string
UPDATE gbase.user SET password = 'XXXX' WHERE user = 'testdb';

-- Or generate a new hash with the PASSWORD function
UPDATE gbase.user SET password = PASSWORD('123') WHERE user = 'testdb';

-- Repeat for multiple users as needed
-- Bulk change all users (high risk! backup first)
UPDATE gbase.user SET password = PASSWORD('NEWPASSWORD');

3. Flush Privileges

Apply the change immediately without restarting any service.

FLUSH PRIVILEGES;

4. Verify the Restriction

After modifying node 201, that node rejects the user while other nodes still allow access. Applications with failover configured will automatically switch to a working node.

# Node 202 still works
[gbase@localhost ~]$ gccli -utestdb -p1234 -h10.0.2.202

# Node 201 now denies access
[gbase@localhost ~]$ gccli -utestdb -p1234 -h10.0.2.201
ERROR 1045 (28000): Access denied for user 'testdb'@'10.0.2.201' (using password: YES)

# Automatic failover in action
[gbase@localhost ~]$ gccli -h10.0.2.201,10.0.2.202,10.0.2.203 -utestdb -p1234 -e "select now()"
ERROR 1045 (28000): Access denied for user 'testdb'@'10.0.2.201' (using password: YES)
+---------------------+
| now()               |
+---------------------+
| 2024-05-15 09:13:53 |
+---------------------+

Reverting the Change

Restore the original password hash and flush privileges.

UPDATE gbase.user SET password = 'original_hash' WHERE user = 'testdb';
FLUSH PRIVILEGES;

Emergency Recovery (Admin Account Locked Out)

If you accidentally locked out all users, copy the user table files from a working node and restart gcluster on the affected node.

scp 10.0.2.202:/opt/gcluster/userdata/gcluster/gbase/user.* /opt/gcluster/userdata/gcluster/gbase/
gcluster_services gcluster restart

When to Use This Technique

This method is ideal for temporary isolation scenarios — for example, when you need to take a coordinator out of rotation for maintenance while the rest of the cluster continues serving traffic. It's a lightweight, quickly reversible operation that doesn't require altering the cluster topology.

In a gbase database environment, this gives you fine‑grained control over which coordinators are reachable, without touching the load balancer or firewall rules.