In a GBase 8a cluster, setting a node to unavailable is a drastic action intended for irrecoverable hardware failures. Once applied, the system stops recording inconsistency events for that node, and the only official way forward is a full node replacement. But what if you set the wrong node to unavailable by mistake? If the mistake is caught early and business operations are quiesced, you can forcibly recover by editing the gcware snapshot data. This article details the step‑by‑step emergency procedure and its risks.
Risk Warnings
- The
unavailablestate stops recording primary‑replica inconsistency events. The longer you wait, the greater the potential impact. - If tables were modified while the node was
unavailable, subsequent operations may produce incorrect results or DML errors. If this is unacceptable, node replacement is the only safe path. - If the database was already in
readonlymode and all business jobs were stopped, there is no impact. - The cluster must be taken offline during this procedure. Proceed only after careful evaluation.
Terminology
- Management service = gcware
- Scheduling service = coordinator
- Data service = gnode + syncserver
Recovery Steps
1. Stop All Scheduling and Data Services
gcluster_services all stop
2. Flush the gcware State Machine
Create a Python script flushstatement.py that calls flush_statemachine() twice:
import gcware
gcware.flush_statemachine()
gcware.flush_statemachine()
python flushstatement.py
3. Stop All Management Services
gcware_services all stop
4. Back Up All gcware Data
On every management node, back up the data directory before making changes. The data is located at: <install_dir>/<IP>/gcware/data/gcware/.
5. Edit the Snapshot Files to Restore Node State
In every SNAPSHOT directory on every management node, locate these two files and change the nodestate of the affected node from 3 to 1.
SNAPSHOT.*/statemachine/COORDINATORSTATESNAPSHOT.*/statemachine/vc00001/DATACLUSTERSTATE
Example: COORDINATORSTATE before (nodestate:3 = unavailable)
{
"coordinatornodes":[
{
"nodeid":1744961546,
"nodestate":3,
...
}
]
}
After changing to 1
{
"coordinatornodes":[
{
"nodeid":1744961546,
"nodestate":1,
...
}
]
}
Edit DATACLUSTERSTATE in the same way. If a node was not mistakenly marked unavailable (i.e., its nodestate is not 3), you can skip it. Use gccli to run show nodes to find the mapping between IPs and node IDs.
6. Restart Management Services and Verify
gcware_services all start
At this point, scheduling and data services are still stopped, so a CLOSE status is normal. If the node now shows CLOSE instead of UNAVAILABLE, proceed. If it's still UNAVAILABLE, return to step 2, flush again, and re‑check for missed edits.
7. Start All Scheduling and Data Services
gcluster_services all start
The cluster is now back online and can serve traffic normally.
Summary
This procedure forces a node out of the unavailable state by directly editing the persisted gcware snapshots. It must be performed with the cluster fully stopped, and backups of the gcware data are mandatory before any edits. The key to minimising impact is catching the mistake early and acting before any further data changes occur.
In a gbase database cluster, the unavailable state is a powerful but irreversible safeguard. When it is applied to the wrong node by accident, this emergency method gives you a controlled path back to a healthy cluster — provided you act quickly and follow every step precisely.
Top comments (0)