Skip to main content

SingleStoreDB v8.1

SingleStoreDB Server and memsqld

Overview

SingleStoreDB is a distributed, relational database that runs on a set of hosts. Each host has an installation of SingleStoreDB, and has one or more instances of a running memsqld process. Each memsqld processes is called a node, which can either be an aggregator or a leaf.

One set of SingleStoreDB binaries can be used to run more than one node on the same host. While a single node can be deployed on a host, multiple nodes are typically deployed on hosts with multiple processors.

A collection of nodes is called a cluster, which constitutes a singular SingleStoreDB database with a single point of entry.

Refer to Cluster Components for more information.

Node Configuration

During deployment, SingleStoreDB server binaries are installed on each host, where the server is then used to run multiple nodes. Each node is comprised of the following core components:

  • Two memsqld processes:

    • The main memsqld engine process, which has both a port on 3306:

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

      ...and a socket open 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 child memsqld process has a socket open to communicate with the main memsqld engine process and for spawning other 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 memsql.cnf configuration file

The following directory structures show the locations of these components in a minimal, single-host cluster consisting of:

An aggregator node:

  • /opt/singlestoredb-server-<version>/memsqld -- or --

    /opt/memsql-server-<version>/memsqld

  • /var/lib/memsql/<aggregator-node-ID>/memsql.cnf

A leaf node:

  • /opt/singlestoredb-server-<version>/memsqld -- or --

    /opt/memsql-server-<version>/memsqld

  • /var/lib/memsql/<leaf-node-ID>/memsql.cnf

Note that this structure is equivalent for both nodes, differing only by the node ID.

SingleStoreDB ensures high availability by storing redundant node data in the cluster. Should a node fail 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.

Important

The memsqld process runs under the memsql user and group on each host, which owns all of the SingleStoreDB data and configuration files. This user and group are automatically created when SingleStoreDB is deployed using a Debian or an RPM package. Consequently, memsqld can only be started or stopped by either the memsql user or the Linux root user (where, as root, the command is run as the memsql user).

In addition, memsqlctl, which can start or stop memsqld, must be run by either the memsql user or the Linux root user. The user and group that can run memsqld in lieu of the memsql user can be changed in the memsql.cnf file.

Finally, creating a memsql user and group manually is only recommended in a sudo-less environment when working with a tarball-based deployment of SingleStoreDB.

In this section: