CLI Online Deployment - Red Hat Distribution
On this page
Introduction
Installing SingleStore 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 SingleStore 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 SingleStore 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.
Note
There are no licensing costs for using up to four license units for the leaf nodes in your cluster.
Prerequisites
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 SingleStore 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 For SingleStore 8.
1 or later, glibc
2.17 or later is also required. -
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 SingleStore services and own the corresponding runtime state
-
-
SSH access to all hosts
-
Installing and using
ssh-agent
is recommended for SSH keys with passwords.Refer to ssh-agent and ssh-add and Use ssh-agent to Manage Private Keys for more information. -
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.
Duplicate Hosts
As of SingleStore Toolbox 1.
✘ Host check failed.host 172.26.212.166 has the same ssh
host keys as 172.16.212.165, toolbox doesn't support
registering 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 SingleStore Toolbox 1.sdb-deploy setup-cluster
supports an --allow-duplicate-host-fingerprints
option that can be used to ignore duplicate SSH host keys.
Network Configuration
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 SingleStore aggregators -
Allow all nodes in the cluster to talk to each other over the SingleStore protocol (3306)
-
Allow you to connect to management and monitoring tools
Protocol |
Default Port |
Direction |
Description |
---|---|---|---|
TCP |
22 |
Inbound and Outbound |
For host access. |
TCP |
443 |
Outbound |
To get public repo key for package verification. |
TCP |
3306 |
Inbound and Outbound |
Default port used by SingleStore. |
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 SingleStore.
Install SingleStore Tools
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 SingleStore onto your hosts, assigning and configuring nodes in your cluster, and other management operations.
Note: If SingleStore is installed as a sudo
user via packages, systemd
will automatically start the associated SingleStore processes when a host is rebooted.
Online Installation - Red Hat Distribution
Run the following commands to install SingleStore Tools.
sudo yum-config-manager --add-repo https://release.memsql.com/production/rpm/x86_64/repodata/memsql.repo && \sudo yum install -y singlestoredb-toolbox singlestore-client
Troubleshooting
If SingleStore Tools cannot be installed using the above commands, verify the following and re-run the above commands to install SingleStore Tools.
-
Verify that the SingleStore repo information is listed under
repolist
.sudo yum repolistrepo id repo name status memsql MemSQL 125
-
Verify that the
which
package is installed.This is used during the install process to identify the correct package type for your installation. rpm -q which-
If
which
is not installed, you must install it before proceeding.sudo yum install -y which -
If you cannot install
which
, you will need to specify the package asrpm
during the deployment phase.
-
-
If you receive an error that the GPG check failed, which resembles the following:
Importing GPG key <gpg-key>: Userid : "MemSQL Release Engineering <security@memsql.com>" Fingerprint: <fingerprint> From : https://release.memsql.com/release-aug2018.gpg Key import failed (code 2). Failing package is: singlestore-client-1.0.7-1.x86_64 GPG Keys are configured as: https://release.memsql.com/release-aug2018.gpg Public key for singlestoredb-toolbox-1.13.13-9fa4ef2d34.x86_64.rpm is not installed. Failing package is: singlestoredb-toolbox-1.13.13-1.x86_64 GPG Keys are configured as: https://release.memsql.com/release-aug2018.gpg The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'yum clean packages'. Error: GPG check FAILED
-
View the current crypto policies.
update-crypto-policies --show -
If
SHA1
is not present, update the crypto policies to work with SingleStore Tools.sudo update-crypto-policies --set DEFAULT:SHA1Refer to Using system-wide cryptographic policies for more information.
-
Deploy SingleStore
Prerequisites
Warning
Before deploying a SingleStore 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 SingleStore in a production environment.
Notes on Users and Groups
The user that deploys SingleStore via SingleStore Toolbox must be able to SSH to each host in the cluster.singlestoredb-server
is installed via an RPM or Debian package when deploying SingleStore, a memsql
user and group are also created on each host in the cluster.
This memsql
user does not have a shell, and attempting to log in or SSH as this user will fail.memsql
group.sudo
privileges, and members of this group can perform many Toolbox operations without the need to escalate to sudo
.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 SingleStore.memsql
user must be configured so that it can SSH to each host in the cluster.
Minimal Deployment
SingleStore 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 SingleStore node on each host.
While additional aggregators and nodes can be added and removed as required, a minimal deployment of SingleStore always consists of at least these two nodes.
CLI Online Deployment
You can deploy SingleStore onto each host from the main deployment host and create the SingleStore nodes for your cluster.
From the main deployment host, deploy the SingleStore on all of your hosts using the setup-cluster command.--master-host
, --aggregator-hosts
, and --leaf-hosts
flags as comma-separated host names.--password
flag specifies the password for the root
database user.
Other than the main deployment host being specified as the --master-host
, the other hosts in your cluster can be used as hosts for the child aggregator or leaf nodes.
sdb-deploy setup-cluster -i /path/to/yourSSHkey \--license <license> \--master-host <main_IP_address_or_hostname> \--aggregator-hosts <child_agg_IP_address_or_hostname> \--leaf-hosts <leaf1_IP_address_or_hostname>,<leaf2_IP_address_or_hostname> \--password <secure_password> \--version 8.9
For large clusters with many hosts, it may be inconvenient to have to input all the host names in the command line.
Note: If your license is not shown in the code block above, you can retrieve it from the Cloud Portal.
Note
If your host does not have the which
command available, you will need to specify the package through the --force-package-format {rpm | deb}
flag when running the setup-cluster
command.
The setup-cluster
command does several things for you:
-
Installs the latest
singlestoredb-server
package on all hosts in your cluster. -
Deploys SingleStore engine across all of the hosts in your cluster.
-
Creates the master aggregator.
In this tutorial, the master aggregator resides on the main deployment host. -
Creates any child aggregators specified in either the host file or in the command-line.
-
Creates leaf nodes for your cluster.
Note: The setup-cluster
command only creates one node per host.If your host is NUMA capable and has more than one NUMA node, you can install additional leaf nodes. -
By default, the
setup-cluster
command will also enable High Availability.To disable High Availability, use the flag --high-availability=false
in thesetup-cluster
command.
After you have deployed your cluster, run sdb-admin optimize
.
sdb-admin optimize
If you encounter errors running either of these commands, verify that your deployment environment satisfies the following conditions:
-
You can SSH to every host in the cluster using the IPs or hostnames specified in the
setup-cluster
step above. -
Your deployment user has root or sudo privileges in order to install packages on all hosts:
sudo apt-get install ... -
Port 3306 on all hosts is open to all other hosts in the cluster.
Additional Deployment Options
Note
If this deployment method is not ideal for your target environment, you can choose one that fits your requirements from the Deployment Options.
Connect to Your Cluster
The 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 --help
.
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 SingleStore for additional options for connecting to SingleStore.
Next Steps After Deployment
Now that you have installed SingleStore, check out the following resources to learn more about SingleStore:
-
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.
-
How to Load Data into SingleStore: Describes the different options you have when ingesting data into a SingleStore cluster.
-
How to Run Queries: Provides example schema and queries to begin exploring the potential of SingleStore.
-
Configure Monitoring: SingleStore’s native monitoring solution is designed to capture and reveal cluster events over time.
By analyzing this event data, you can identify trends and, if necessary, take action to remediate issues. -
Tools Reference: Contains information about SingleStore Tools, including Toolbox and related commands.
Last modified: September 18, 2023