Cluster Config Files

On this page

Cluster Overview

SingleStore is a distributed, relational, database that consists of a set of hosts and nodes.

  • Each host has a collection of SingleStore binaries and one or more instances of a running memsqld process.

  • Each memsqld process is a node, which can be of type aggregator or leaf.

  • The set of nodes is referred to as a cluster, which constitutes a singular SingleStore database with a single point of entry. Refer to Cluster Components for more information.

During deployment, SingleStore server binaries are installed on each host. One set of binaries can run multiple nodes on the same host. While a single node can be deployed on a single host, multiple nodes are typically deployed on multiple hosts which have multiple processors.

The SingleStore server is used to run multiple nodes, where each node is comprised of the following core components:

  • Two memsqld processes:

    • The main memsqld engine process, which has:

      A port on 3306:

      sudo lsof -p <memsqld_pid> | grep localhost
      memsqld 2388 memsql 71u IPv4 156936 0t0 TCP localhost:mysql->localhost:41648 (ESTABLISHED)

      An open socket for external connections:

      sudo lsof -p 2388 | grep -i memsql.sock
      memsqld 2388 memsql 13u unix 0xffff9d2f26f7b180 0t0 31573 memsql.sock
    • A child memsqld process, referred to as the "command process.

      This process has a socket open to communicate with the main memsqld engine process and for spawning other child memsqld processes for async compilation / extractors / transforms for pipelines and other related tasks.

  • A few auxiliary processes, such as memsqld_safe which starts up memsqld in the event of a crash. Refer to memsqld and memsqld_safe processes for more information.

  • A node configuration file, memsql.cnf

SingleStore ensures high availability (HA) by storing redundant node data in the cluster. If a node fails to serve its data when requested, a copy of the node's data will be served instead. This automatic failover mechanism prevents data loss due to single-node failures. Refer to High Availability for more information.

In this section

Last modified: January 2, 2025

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