Sign inTry Free

Important

Helios features are now enabled during weekly update windows and are no longer directly tied to SingleStore engine releases. Refer to the release notes to view the latest features available in your Helios cluster.

MV_REBALANCE_STATUS

On this page

This view contains information about the status of REBALANCE operations.

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:

  • cancelled - the command was cancelled (can happen if a rebalance is terminated)

  • failed - the command failed to complete

  • running - the command is currently in process

  • scheduled - the command is scheduled to run

  • success - the command ran successfully

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 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.

Last modified:

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In