Sign inTry Free

Important

The SingleStore 9.1 release candidate (RC) gives you the opportunity to preview, evaluate, and provide feedback on new and upcoming features prior to their general availability. In the interim, SingleStore 9.0 is recommended for production workloads, which can later be upgraded to SingleStore 9.1.

High Availability

An availability group is set of leaves which store data redundantly to ensure high availability. Each availability group contains a copy of every partition in the system - some as primaries and some as replicas. Currently, SingleStore supports up to two availability groups. You can set the number of availability groups via the redundancy_level variable on the Master Aggregator. From this point forward, we’ll discuss the redundancy-2 case.

The placement of replica partitions in a cluster can be specified via the leaf_failover_fanout variable. SingleStore supports two modes for partition placement: paired and load_balanced. In paired mode, each leaf in an availability group has a corresponding pair node in the other availability group. Each leaf has its own primary partitions, which SingleStore synchronizes to its pair as replica partitions. In other words, each leaf backs up its pair and vice versa. For this reason, each leaf stores both primary and replica partitions. In the event of a failure, SingleStore will automatically promote replica partitions on a leaf’s pair.

In load_balanced mode, primary partitions are evenly placed on leaves. The primary partitions on every leaf in an availability group have their replica partitions spread evenly among a set of leaves in the opposite availability group.

For more information, see Managing High Availability.

By default, the ADD LEAF command will add a leaf into the smaller of the two groups. However, if you know your cluster’s topology in advance, you can specify the group explicitly with the INTO GROUP N suffix. By grouping together machines that share resources like a network switch or power supply, you can isolate common hardware failures to a single group and dramatically improve the cluster’s uptime.

SingleStore automatically displays which availability group a leaf belongs to in the SHOW LEAVES command.

Last modified: June 13, 2024

Was this article helpful?

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