CLI Deployment - Tarball
On this page
Installing SingleStoreDB on bare metal, on virtual machines, or in the cloud can be done through the use of popular configuration management tools or through SingleStore’s management tools.
In this guide, you will deploy a SingleStoreDB cluster onto physical or virtual machines and connect to the cluster using a SQL client.
A four-node cluster is the minimal recommended cluster size for showcasing SingleStoreDB as a distributed database with high availability; however, you can use the procedures in this tutorial to scale out to additional nodes for increased performance over large data sets or to handle higher concurrency loads.
For this tutorial you will need:
One (for single-host cluster-in-a-box for development) or four physical or virtual machines (
hosts) with the following:
Each SingleStoreDB node requires at least four (4) x86_
64 CPU cores and eight (8) GB of RAM per host
Eight (8) vCPU and 32 GB of RAM are recommended for leaf nodes to align with license unit calculations
Running a 64-bit version of RHEL/AlmaLinux 7 or later, or Debian 8 or later, with kernel 3.
10 or later
Port 3306 open on all hosts for intra-cluster communication.
Based on the deployment method, this default can be changed either from the command line or via cluster file.
Port 8080 open on the main deployment host for the cluster
A non-root user with sudo privileges available on all hosts in the cluster that be used to run SingleStoreDB services and own the corresponding runtime state
SSH access to all hosts
If your environment does not support the use of
ssh-agent, make sure the identity key used on the main deployment host can be used to log in to each host in the cluster.
Refer to How to Setup Passwordless SSH Login for more information.
A connection to the Internet to download required packages
If running this in a production environment, it is highly recommended that you follow our host configuration recommendations for optimal cluster performance.
As of SingleStoreDB Toolbox 1.
✘ Host check failed.host 172.26.212.166 has the same sshhost keys as 172.16.212.165, toolbox doesn't supportregistering the same host twice
Confirm that all specified hosts are indeed different and aren’t using identical SSH host keys.
/etc/ssh/ssh_) will also be cloned.
As each cloned host will have the same host key, an SSH client cannot verify that it is connecting to the intended host.
The following steps demonstrate a potential remedy for the
duplicate hosts message.
sudo rootls -al /etc/ssh/rm /etc/ssh/<your-ssh-host-keys>ssh-keygen -f /etc/ssh/<ssh-host-key-filename> -N '' -t rsa1ssh-keygen -f /etc/ssh/<ssh-host-rsa-key-filename> -N '' -t rsassh-keygen -f /etc/ssh/<ssh-host-dsa-key-filename> -N '' -t dsa
For more information about SSH host keys, including the equivalent steps for Ubuntu-based systems, refer to Avoid Duplicating SSH Host Keys.
As of SingleStoreDB Toolbox 1.
sdb-deploy setup-cluster supports an
--allow-duplicate-host-fingerprints option that can be used to ignore duplicate SSH host keys.
Depending on the host and its function in deployment, some or all of the following port settings should be enabled on hosts in your cluster.
These routing and firewall settings must be configured to:
Allow database clients (e.
g. your application) to connect to the SingleStoreDB aggregators
Allow all nodes in the cluster to talk to each other over the SingleStoreDB protocol (3306)
Allow you to connect to management and monitoring tools
Inbound and Outbound
For host access.
To get public repo key for package verification.
Inbound and Outbound
Default port used by SingleStoreDB.
The service port values are configurable if the default values cannot be used in your deployment environment.
The cluster file template provided in this guide
The sdb-toolbox-config register-host command
We also highly recommend configuring your firewall to prevent other hosts on the Internet from connecting to SingleStoreDB.
The first step in deploying your cluster is to download and install the SingleStore Tools on one of the hosts in your cluster.
These tools perform all major cluster operations including downloading the latest version of SingleStoreDB onto your hosts, assigning and configuring nodes in your cluster, and other management operations.
singlestoredb-server files onto the main deployment host, or onto a device with access to the main deployment host.
To obtain the latest version of each file, use the following:
singlestoredbserver to download the list of available file types.
The JSON you receive contains relative file paths in the following format:
wget to download the file by copying, pasting, and appending the path (minus the quotes) to
Alternatively, download the following SingleStore tarball files onto a device with access to the main deployment host.
singlestoredb-server tarball files into a dedicated
singlestore directory that has been configured so that non-
sudo users can access on the main deployment host, such as
Note: For the remainder of this document,
<version>-<commit-hash> will be written simply as
singlestore-client into the
tar xzvf singlestoredb-toolbox-<version>.tar.gz && \tar xzvf singlestore-client-<version>.tar.gz
You do not need to unpack the
singlestoredb-server file in this step.
Before deploying a SingleStoreDB cluster in a production environment, please review and follow the host configuration recommendations.
In addition, SingleStore recommends that each Master Aggregator and child aggregator reside on its own host when deploying SingleStoreDB in a production environment.
The user that deploys SingleStoreDB via SingleStoreDB Toolbox must be able to SSH to each host in the cluster.
singlestoredb-server is installed via an RPM or Debian package when deploying SingleStoreDB, a
memsql user and group are also created on each host in the cluster.
memsql user does not have a shell, and attempting to log in or SSH as this user will fail.
sudo privileges, and members of this group can perform many Toolbox operations without the need to escalate to
memsql group on each host in the cluster.
Manually creating a
memsql user and group is only recommended in a
sudo-less environment when performing a tarball-based deployment of SingleStoreDB.
memsql user must be configured so that it can SSH to each host in the cluster.
SingleStoreDB has been designed to be deployed with at least two nodes:
A Master Aggregator node that runs SQL queries and aggregates the results, and
A single leaf node, which is responsible for storing and processing data
These two nodes can be deployed on a single host (via the
cluster-in-box option), or on two hosts, with one SingleStoreDB node on each host.
While additional aggregators and nodes can be added and removed as required, a minimal deployment of SingleStoreDB always consists of at least these two nodes.
/home/<user>/singlestore directory is used through this guide to hold the necessary deployment files and demonstrate the associated deployment commands, this directory can be substituted with any directory that a non-
sudo user has access to.
Run the following commands on the Master Aggregator host from the
Change to the
The following command deploys a 4-node SingleStoreDB cluster with a Master Aggregator node, a Child Aggregator node, and two leaf nodes../sdb-deploy setup-cluster -i <id_rsa-file-including-path> \--license <license-from-portal.singlestore.com> \--master-host <master-aggregator-ip-or-hostname> \--aggregator-hosts <child-aggregator-ip-or-hostname> \--leaf-hosts <leaf-1-ip-or-hostname>,<leaf-2-ip-or-hostname> \--password <secure-password> \--force-package-format tar--file-path "/path/to/singlestoredb-server-<version>-<commit-hash>.x86_64.tar.gz"
Note the inclusion of the
Note: Creating a node with an empty root password may be convenient for testing purposes.
While this is not recommended, you can specify a blank password via:
Analyze your current cluster configuration using the
This command checks your current cluster configuration against a set of best practices and either makes changes to maximize performance or provides recommendations for you.
For hosts with NUMA support, this command will bind the leaf nodes to specific NUMA nodes../sdb-admin optimize
If this deployment method is not ideal for your target environment, you can choose one that fits your requirements from the Deployment Options.
singlestore-client package contains is a lightweight client application that allows you to run SQL queries against your database from a terminal window.
After you have installed
singlestore-client, use the
singlestore application as you would use the
mysql client to access your database.
For more connection options, help is available through
singlestore -h <Master-or-Child-Aggregator-host-IP-address> -P <port> -u <user> -p<secure-password>
Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 12 Server version: 5.5.58 MemSQL source distribution (compatible; MySQL Enterprise & MySQL Commercial) Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. singlestore>
Refer to Connect to Your Cluster for additional options for connecting to SingleStoreDB.
Now that you have installed SingleStoreDB, check out the following resources to learn more about SingleStoreDB:
How to Run Queries: Provides example schema and queries to begin exploring the potential of SingleStoreDB.
How to Load Data into SingleStoreDB: Describes the different options you have when ingesting data into a SingleStoreDBcluster.
Optimizing Table Data Structures: Learn the difference between rowstore and columnstore tables, when you should pick one over the other, how to pick a shard key, and so on.
SingleStore Tools Reference: Contains information about SingleStore Tools, including SingleStoreDB Toolbox and related commands, and how MemSQL Ops commands map to SingleStore Tools commands.
Last modified: September 18, 2023