Understanding GBase 8a Rebalance Logs: Stage‑by‑Stage Timing

During a scale‑out or scale‑in operation in a gbase database cluster, the rebalance process is critical for redistributing data. The cluster‑level express.log records detailed execution information, breaking the rebalance into distinct stages, each with its own timing. Analysing these stages helps you pinpoint performance bottlenecks quickly.

Sample Log

Below is a typical rebalance log entry from express.log:

Stage Descriptions

Each line in the log represents a stage, with the elapsed time shown in seconds.

Stage Name	Description
REB_MAKE_POLICY	Time spent generating the redistribution policy
REB_EXEC_POLICY	Time spent executing the redistribution policy
REB_CREATE_TABLE	Time spent creating intermediate table structures
REB_CREATE_SLICE	Time spent creating table slices
REB_SIS	Time spent executing SELECT INTO SERVER
REB_GC_SYNC	Time spent synchronising data via gc_sync_client
REB_RENAME	Time spent renaming the intermediate table to the target table
REB_CHANGE_DIST_ID	Time spent updating the distribution ID
REB_DELETE_SLICE	Time spent removing old table slices
REB_GC_LOCK	Time spent acquiring the cluster lock
REB_UPDATE_STATUS	Time spent updating progress information in system tables
REB_SIS_COMMIT	Time spent committing the SIS transaction
REB_SIS_ROLLBACK	Time spent rolling back the SIS transaction (appears only on failure)
REB_UPDATE_FAILOVER_INFO	Time spent updating failover information
REB_DATA_MOVE	Time spent performing the actual data migration

How to Interpret the Timings

Different table types show different bottlenecks:

• Large tables (high row count): The dominant phases are REB_DATA_MOVE (data migration) and REB_GC_SYNC (data synchronisation).
• Wide tables or tables with many partitions but few rows: The creation stages (REB_CREATE_TABLE and REB_CREATE_SLICE) may consume the most time.
• Tables that complete the entire rebalance in under 10 seconds: These generally require no tuning.

By focusing on the stages with the highest elapsed times, you can target your optimisation efforts — adjusting parallelism, redesigning table structures, or expanding disk capacity where it matters most.

In a gbase database, the express.log rebalance entries are one of the most direct windows into the cluster's internal behaviour during scaling operations. Keep them handy whenever you plan a topology change.