Sign inTry Free

Master Aggregator Redundancy Error Codes

On this page

During Master Aggregator (MA) failover, the voting members elect a new MA. The election protocol is internal; applications do not receive a SQL error code for each vote.

Instead, a client can receive a connection error or an MA-role error while the old MA is shutting down or the new MA is being elected. Configure the application to retry transient failures through the load-balanced MA endpoint.

For a query that cannot be forwarded or retried automatically, drop the connection, reconnect, and retry the operation according to the application's retry and transaction-safety requirements.

Client and Failover Errors

The following errors can occur during MA failover.

Error code

Available in DB release 8.9/ 9.0 / 9.1

When it occurs

Recommended action

ER_SERVER_SHUTDOWN

1053

The previous MA is shutting down. This can also be returned when a DDL term check runs during shutdown.

Retry through the load-balanced MA endpoint.

ER_CONNECT_TO_MASTER

1218

A child aggregator cannot connect to the current MA, typically while a new MA is being elected. The message is « Error connecting to master: %s ».

Retry the request after the new MA is available.

ER_DISTRIBUTED_NOT_MASTER

1752

The request reached a node that is not the current MA, including after another voting member was elected.

Retry on the current MA through the load-balanced endpoint

ER_DISTRIBUTED_NOT_MASTER_ANYMORE

2076

The node that received the request is no longer the MA, for example, after a leadership transfer.

Retry on the new MA.

ER_DISTRIBUTED_MASTER_TERM_REJECTED

2787, first appearing in 9.0.2

A DDL operation was rejected because an MA failover occurred; the request's DDL term is behind the node's consensus term.

Retry the DDL operation on the new MA.

A driver can also report a lost connection, such as « Lost connection to server during query». This should be handled as a transient failover error: reconnect before retrying the operation.

Consensus Membership and Leadership Errors

These errors apply to administrative operations that manage consensus membership or leadership. They are not SQL errors returned for individual election votes.

The consensus-family numeric codes differ between the releases 8.9 and 9.0/9.1. The family beginning with ER_CONSENSUS_BROKEN_QUORUM is absent in 8.9.1 and appears from 8.9.19.

Error code

8.9.1

8.9.19–8.9.54

9.0 / 9.1

When it occurs

Recommended action

ER_NODE_IS_VOTING_MEMBER

2481

2481

2481

Consensus is being disabled while the node is still a voting member.

Remove the node from voting membership or re-add it as a follower before setting consensus_enabled to OFF.

ER_CONSENSUS_NOT_ENABLED

2482

2482

2482

An operation requiring consensus is attempted while consensus is disabled. This can also occur when consensus is enabled while a reference database is not sync durable. The client message is then the custom durability text, not only the generic consensus-disabled text.

Enable consensus after satisfying its prerequisites; for a durability-related message, make the reference database sync durable.

ER_CONSENSUS_BROKEN_QUORUM

Not available

2749

2748

Detach, demote, or remove would leave no majority of active voting members.

Do not perform the operation until it preserves quorum.

ER_CONSENSUS_NON_VOTING_MEMBER

Not available

2750

2749

A voting-member operation is attempted on a non-voting member, such as a follower CA.

Run the operation on a voting member or add the node to voting membership first.

ER_CONSENSUS_DETACHED_VOTING_MEMBER

Not available

2751

2750

A voting member is detached when it is already detached.

Check the member state before retrying the detach operation.

ER_CONSENSUS_ATTACHED_VOTING_MEMBER

Not available

2752

2751

A voting member is attached when it is not detached.

Check the member state before retrying the attach operation.

ER_CONSENSUS_ATTACH_VOTING_MEMBER_TIMEOUT

Not available

2753

2752

Warning: ATTACH VOTING MEMBER completed, but the node may still be a demoted voting member because promotion to voting member did not finish before attach_voting_member_wait_promotion_timeout_s expired.

Check the member status and allow promotion to complete. The attach operation still succeeds; do not blindly retry it.

ER_CONSENSUS_LEADERSHIP_TRANSFER_TIMEOUT

Not available

2754

2753

Leadership transfer timed out while detaching or removing the current MA. Leadership transfer is an internal step, not a standalone user command.

Check the target voting member and quorum, then retry the DETACH or REMOVE operation.

ER_CONSENSUS_LEADERSHIP_TRANSFER_FAILED

Not available

2755

2754

Leadership could not be transferred while detaching or removing the current MA.

Check the voting-member and quorum state, resolve the underlying issue, then retry the DETACH or REMOVE operation.

Monitoring election activity - Use INFORMATION_SCHEMA.MV_EVENTS to monitor MA election and consensus activity. Relevant events include CONSENSUS_ELECTION, CONSENSUS_VOTING_EVENTS, and NEW_MASTER_AGGREGATOR.

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