GBase Database(GBase 8c) instances report three states: running, stopped, and unstable.

The first two are relatively easy to understand. The third is where database operators often make mistakes.

Understanding these three states is essential for GBase Database cluster monitoring, troubleshooting, and deployment acceptance.

1. What Do the Three States Mean?

Each state describes a different operational condition.

running

The instance is running and participating in its expected cluster role and replication activities.

stopped

The instance has stopped. This may be intentional, such as during planned maintenance, or unexpected due to a failure.

unstable

The instance is in an intermediate state. Its process may exist, but its role or replication status has not fully converged.

The important distinction is that a running process does not necessarily mean a usable database component.

2. Why Is Unstable Easy to Misinterpret?

The most common reaction is: "It is probably still starting. Let's wait another minute."

That may be correct immediately after startup, but it is not a safe assumption in a distributed GBase Database deployment.

An unstable state may be associated with several conditions:

  • A DN group is electing a new primary.
  • A standby instance is catching up with replication.
  • Network jitter is causing heartbeat interruptions.
  • Cluster roles are repeatedly switching instead of converging.

These conditions can affect application behavior.

A connection may succeed once and fail on the next attempt. A component that has not reached a stable role may also affect query execution and transaction processing.

Therefore, unstable should be treated as a not-ready state until the underlying condition is understood.

3. Three Things to Investigate

When a GBase Database instance remains unstable, check three areas before attempting recovery.

Check 1: DN Group Primary Distribution

Verify whether each DN group has exactly one primary.

Pay particular attention to two abnormal conditions:

  • Two primaries in one group
  • No primary in one group

Both indicate that the expected replication role relationship is not established.

Check 2: DCS Health

Check the DCS health list and confirm that all expected nodes are healthy, with one isLeader.

GBase Database relies on DCS for quorum and cluster coordination. An unhealthy DCS layer can affect role election and the stability of components above it.

Check 3: Instance Logs

Inspect the affected instance logs for repeated role changes, election events, heartbeat failures, or replication errors.

The monitoring output tells you the current state, while the logs help explain why the instance has not converged.

GBase Database reports the state, but identifying the underlying cause requires further investigation.

4. Do Not Ignore the Startup Exception

There is one important exception.

Immediately after a cluster starts, an instance may temporarily report unstable while the cluster converges.

In this situation, the key question is whether the instance transitions to running within the expected startup period.

If it does, the intermediate state may be part of normal startup behavior.

If it remains unstable, investigate it as a fault rather than assuming that waiting longer will solve the problem.

The expected convergence time should be evaluated against the deployment environment and version-specific behavior.

5. Read All Four Monitoring Tables Together

Another common mistake is checking only the DataNode (DN) table.

GBase Database(GBase 8c) has four important monitoring sections:

  • gha_server: Management leadership
  • gtm: Transaction management roles
  • coordinator (CN): SQL access components
  • datanode (DN): Data storage and replication roles

An unstable GTM can affect transaction management. An unstable CN can make SQL access unreliable. An unstable DN can affect data availability and replication.

Checking only DN status does not establish that the entire cluster is ready.

Read all four sections together, and check DCS health as the underlying coordination layer.

Key Takeaway: Unstable Means Not Ready

The most important lesson is simple:

State is a result, not a cause.

unstable does not tell you exactly what is broken. It tells you that the instance has not reached a stable operational condition.

For GBase Database cluster monitoring, do not treat unstable as equivalent to running, and do not assume that every unstable state will resolve itself.

Wait for normal startup convergence when appropriate. If the state persists, investigate primary distribution, DCS health, and instance logs before declaring the cluster ready.

A database process being alive is not the same as a database component being usable.