# MV\_REBALANCE\_STATUS This view contains information about the status of `REBALANCE` commands such as [REBALANCE ALL DATABASES](https://docs.singlestore.com/db/v9.0/reference/sql-reference/cluster-management-commands/rebalance-all-databases.md) and [REBALANCE PARTITIONS](https://docs.singlestore.com/db/v9.0/reference/sql-reference/cluster-management-commands/rebalance-partitions.md). | Column Name | Description | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `DATABASE_NAME` | The name of the database the`REBALANCE`command is running on or within. | | `ACTION` | The action being performed. Possible values include`COPY PARTITION`,`PROMOTE PARTITION`(which may include modifiers such as`WITH DROP`or`WITH REPOINT`), and`DROP PARTITION`.`DROP PARTITION`may appear as a standalone action when executed as a separate step.In some rebalance flows, the previous partition copy is dropped as part of`PROMOTE PARTITION WITH DROP`rather than reported as a separate`DROP PARTITION`action. The associated cleanup may be visible in leaf trace logs, for example as`DeleteAllBlobFilesForDb,`while`MV_REBALANCE_STATUS`reports only`PROMOTE PARTITION WITH DROP`. | | `ORDINAL` | The`ID`of the related partition.The*Ordinal*is the target partition’s ordinal, and the*Target\_Host*and*Target\_Port*correspond to the destination leaf. Any two operations in the same*Phase*can be run in parallel and phases are run in order. For example, the aggregator can run`COPY PARTITION`on partitions`test:1`and`test:3`in parallel. The exact meaning of what each phase means is arbitrary and depends on the particular rebalance operation. | | `TARGET_HOST` | The target hostname or IP address of a`REBALANCE`command. | | `TARGET_PORT` | The target port number of a`REBALANCE`command. | | `PHASE` | The phase (group of actions occurring at the same time) that a given action is part of. | | `STATUS` | The status of the`REBALANCE`. A`REBALANCE`consists of multiple commands that are run in phases. Can be one of:Querying rebalance status during an ongoing rebalance will show some combination of success, running, and scheduled rows where the phases that completed already will show 'success', the phase that is currently ongoing will show that they are 'running', and the phases that must come next will show that they are 'scheduled'. | | `RUNNING_TIME_MS` | The amount of time in milliseconds spent on a given action. | | `ESTIMATED_TIME_REMAINING_MS` | The estimated amount of time in milliseconds remaining for a given action. | ## Estimated\_Time\_Remaining\_Ms The `Estimated_Time_Remaining_Ms` column contains an estimate (in milliseconds) for each low-level command as follows: * **Command is running** * The estimate is the remaining time for the command to complete. * For a running `COPY PARTITION` operation, the engine obtains the remaining-time estimate from the `ESTIMATED_CATCHUP_TIME_S` column in the [MV\_REPLICATION\_STATUS](https://docs.singlestore.com/db/v9.0/reference/information-schema-reference/replication-management/mv-replication-status.md) information schema view and converts it to milliseconds. For a running `PROMOTE` operation, the engine uses the larger of the catch-up estimate and the replay estimate. If the live estimates are not available, the value is `NULL`. * **Command has not started** * The estimate is the expected runtime of the command. * For commands that have not started, `EXPLAIN REBALANCE`, and other action types (such as `DROP PARTITION`), SingleStore uses a per-database, per-action-type exponential moving average of previous completed runtimes. The latest measurement has a weight of 0.1, and the stored average has a weight of 0.9. The estimate is based on historical runs for the same database and action type, and its accuracy depends on how well the previous runs reflect current conditions. It is not a confidence interval and does not automatically account for changes in data volume between infrequent rebalance operations. *** Modified at: October 15, 2026 Source: [/db/v9.0/reference/information-schema-reference/segment-column-and-merge-status/mv-rebalance-status/](https://docs.singlestore.com/db/v9.0/reference/information-schema-reference/segment-column-and-merge-status/mv-rebalance-status/) (An index of the documentation is available at /llms.txt)