Duplicate Hosts

As of SingleStore Toolbox 1.4.4, a check for duplicate hosts is performed before SingleStore is deployed, and will display a message similar to the following if more than one host has the same SSH host key:

✘ 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. Identical host keys can be present if you have instantiated your host instances from images (AMIs, snapshots, etc.) that contain existing host keys. When a host is cloned, the host key (typically stored in /etc/ssh/ssh_host_<cipher>_key) 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 script that deploys SingleStore will interpret a duplicate host key as an attempt to deploy to the same host twice, and the deployment will fail.

The following steps demonstrate a potential remedy for the duplicate hosts message. Please note these steps may slightly differ depending on your Linux distribution and configuration.

sudo root
ls -al /etc/ssh/
rm /etc/ssh/<your-ssh-host-keys>
ssh-keygen -f /etc/ssh/<ssh-host-key-filename> -N '' -t rsa1
ssh-keygen -f /etc/ssh/<ssh-host-rsa-key-filename> -N '' -t rsa
ssh-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.5.3, 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

The service port values are configurable if the default values cannot be used in your deployment environment. For more information on how to change them, see:

• The cluster file template provided in this guide

• The SingleStore configuration file

• 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.

Download SingleStore Files

Download the singlestoredb-toolbox, singlestore-client, and 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:

curl https://release.memsql.com/production/index/<singlestore-file>/latest.json

Replace <singlestore-file> with memsqltoolbox, memsqlclient, and singlestoredbserver to download the list of available file types.

• To download the latest patch release of a major version, substitute the desired major version for latest. For example:

  curl https://release.memsql.com/production/index/singlestoredbserver/8.1.json

• To download a specific patch release of a major version, substitute the desired patch release for latest. For example:

  curl https://release.memsql.com/production/index/singlestoredbserver/8.1.24.json

The JSON you receive contains relative file paths in the following format:

"Path": "production/tar/x86_64/<singlestore-file>-<version>-<commit-hash>.x86_64.tar.gz"

Use wget to download the file by copying, pasting, and appending the path (minus the quotes) to https://release.memsql.com/. Examples are shown below.

wget https://release.memsql.com/production/tar/x86_64/<singlestore-file>-<version>-<commit-hash>.x86_64.tar.gz

Alternatively, download the following SingleStore tarball files onto a device with access to the main deployment host.

Transfer SingleStore Files

Transfer the singlestoredb-toolbox, singlestore-client, and 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 /opt/singlestore.

Unpack SingleStore Files

Note: For the remainder of this document, <version>-<commit-hash> will be written simply as <version>.

Unpack singlestoredb-toolbox and singlestore-client into the singlestore directory.

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. It will be installed as part of deployment, which is shown in the next step.

Notes on Users and Groups

The user that deploys SingleStore via SingleStore Toolbox must be able to SSH to each host in the cluster. When 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. The user that deploys SingleStore is added to the memsql group. This group allows most Toolbox commands to run without sudo privileges, and members of this group can perform many Toolbox operations without the need to escalate to sudo. Users who desire to run SingleStore Toolbox commands must be added to the memsql group on each host in the cluster. They must also be able to SSH to each host.

Manually creating a memsql user and group is only recommended in a sudo-less environment when performing a tarball-based deployment of SingleStore. In order to run SingleStore Toolbox commands against a cluster, this manually-created 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.

Create the memsql.service File

By creating the following memsql.service file and enabling the memsql service, all nodes on a host will be restarted after the host is rebooted.

Performing the following steps on each host in the cluster.

1. Create a memsql.service file in the /etc/systemd/system directory.

   Shell

   Copy

   sudo vi /etc/systemd/system/memsql.service

2. Using the following example, replace the directory in the ExecStart and ExecStop lines with the directory in which the memsqlctl file resides on the host.

   In this example, the directory is /opt/singlestore/singlestoredb-server.

   Copy

   [Unit]
   Description=SingleStore
   After=network.target
   
   [Service]
   Type=oneshot
   RemainAfterExit=yes
   ExecStart=/opt/singlestore/singlestoredb-server/memsqlctl start-node  --yes --all
   ExecStop=/opt/singlestore/singlestoredb-server/memsqlctl stop-node  --yes --all
   Slice=system-memsql.slice
   TasksMax = 128000
   LimitNICE=-10
   LimitNOFILE=1024000
   LimitNPROC=128000
   
   [Install]
   WantedBy=multi-user.target

3. Ensure that this file is owned by root.

   Shell

   Copy

   sudo chown root:root /etc/systemd/system/memsql.service

4. Set the requisite file permissions.

   Shell

   Copy

   sudo chmod 644 /etc/systemd/system/memsql.service

5. Enable the memsql service to start all of the nodes on the host after the host is rebooted.

   Shell

   Copy

   sudo systemctl enable memsql.service

   Created symlink from /etc/systemd/system/multi-user.target.wants/memsql.service to /etc/systemd/system/memsql.service.

Additional Deployment Options