Important

The SingleStore 9.1 release candidate (RC) is available now. It will be promoted to general availability (GA) soon and at that time it will be renamed to SingleStore 10.

In the interim, SingleStore 9.1 RC can be used to preview, evaluate, and provide feedback on the new and upcoming features in SingleStore 10, while SingleStore 9.0 is recommended for production workloads.

Enable Master Aggregator High Availability

To enable high availability for the Master Aggregator (MA HA), set masterAggregatorSpec.count to the desired number of Master Aggregator replicas in the sdb-cluster.yaml cluster custom resource (CR) file.

spec:
masterAggregatorSpec:
count: 3

SingleStore recommends an odd number of Master Aggregator replicas. Any count ≥ 2 can form a quorum (quorum size is floor(n/2) + 1), but even counts do not improve failure tolerance over the next-lower odd count. For example, 4 replicas tolerate the same single failure as 3, so the extra replica adds cost without adding resilience, an odd number of replicas so the consensus voters can form a quorum. Three replicas are recommended for most deployments.

For improved fault tolerance, configure pod scheduling so that Master Aggregator pods are not scheduled on the same host. Use pod anti-affinity or another scheduling rule under the top-level schedulingDetails section of the cluster custom resource. Refer to Pod Scheduling for more information.

After you apply the cluster custom resource, verify that MA HA is enabled:

SHOW VARIABLES LIKE 'consensus_enabled';
SHOW AGGREGATORS EXTENDED;

The following are the expected results:

  • consensus_enabled is ON.

  • One Master Aggregator is the leader.

  • The remaining Master Aggregators are voting members.

With MA HA enabled, if the current leader fails, another voting Master Aggregator replica is automatically promoted to leader. Child aggregators are not promoted and do not participate in leader election; they continue to serve query workload. Refer to Change Master Aggregator Disk with MA HA Enabled for more information.

Last modified:

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.