Online Deployment Using YAML File - Red Hat Distribution

As of SingleStoreDB Toolbox 1.4.4, a check for duplicate hosts is performed before SingleStoreDB 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 SingleStoreDB 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 SingleStoreDB 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.

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:

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:

We also highly recommend configuring your firewall to prevent other hosts on the Internet from connecting to SingleStoreDB.

The user that deploys SingleStoreDB via SingleStoreDB 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 SingleStoreDB, 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 SingleStoreDB 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 SingleStoreDB 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 SingleStoreDB. In order to run SingleStoreDB Toolbox commands against a cluster, this manually-created 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:

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.

license:                           <LICENSE | /path/to/LICENSE-file> [Required to bootstrap Master Aggregator]
high_availability:                 <true | false>
memsql_server_version:             <the version of memsql you want to install (6.7+)>
memsql_server_file_path:           <path to the downloaded memsql server file>
memsql_server_preinstalled_path:   <equivalent to using the '--preinstalled-path' option;
                                   the path to the unpacked singlestoredb-server file
                                   where the unpacked folder name must be of the form
                                   'singlestoredb-server-<version>*' or
                                   'memsql-server-<version>*'>
skip_install:                      <true | false> [ADVANCED]
skip_validate_env:                 <true | false> [ADVANCED]
allow_duplicate_host_fingerprints: <true | false> [ADVANCED]
assert_clean_state:                <true | false> [ADVANCED]
package_type:                      <deb | rpm | tar> [Required if multiple package present]
root_password:                     <default password to be used for all nodes>
optimize:                          <true | false>
optimize_config:
  memory_percentage:               <percentage of memory you want memsql to use>
  no_numa:                         <true | false>
sync_variables:                    [ADVANCED]
  <variable's name>:               <variable's value>            
hosts:
- hostname:                        <host-name> [Required]
  localhost:                       <true | false> 
  skip_auto_config:                <true | false>
  memsqlctl_path:                  <path to memsqlctl> [ADVANCED]
  memsqlctl_config_path:           <path to memsqlctl config> [ADVANCED]
  tar_install_dir:                 <path to tar install dir> [ADVANCED]
  tar_install_state:               <path to tar install state> [ADVANCED]
  ssh:                             [Required for remote Hosts]
    host:                          <ssh host name>
    port:                          <ssh port>
    user:                          <ssh user>
    private_key:                   <path to your identity key>
  nodes:
  - register:                      <true | false>
    force_registration:            <true | false> [ADVANCED] 
    role:                          <Unknown | Master | Leaf | Aggregator> (case sensitive) [Required]
    availability_group:            <availability group>
    no_start:                      <true | false>
    config: 
      auditlogsdir:                <path to auditlogs directory> [ADVANCED]
      baseinstalldir:              <path to base install directory> [ADVANCED]
      configpath:                  <path to configuration path> [ADVANCED] [Required if register is true]
      datadir:                     <path to data directory> [ADVANCED]
      disable_auto_restart:        <true | false>
      password:                    <password>
      plancachedir:                <path to plancache directory> [ADVANCED]
      port:                        <port number> [Required for node creation]
      tracelogsdir:                <path to tracelogs directory> [ADVANCED]
      bind_address:                <bind address> [ADVANCED]
      ssl_fips_mode:               <true | false > [ADVANCED]
    variables:
      <variable's name>:           <variable's value>

You can deploy your own SingleStoreDB cluster with your desired cluster configuration using the cluster file template above, and/or the example cluster files in the following sections.

After creating the cluster file, you can deploy the corresponding SingleStoreDBcluster via the sdb-deploy setup-cluster command.

Run the following with the path to the cluster file as input.

sdb-deploy setup-cluster --cluster-file </path/to/cluster-file>

SingleStoreDB uses a combination of aggregator and leaf nodes that are typically configured in a specific ratio. For more information, refer to Cluster Components.

The examples below deploy two different types of SingleStoreDB cluster:

These cluster file examples can be used as a starting point for deploying a SingleStoreDB cluster that fulfills your specific requirements.

license: <license-from-portal.singlestore.com>
memsql_server_version: 7.3
package_type: rpm
root_password: <secure-password>
hosts:
- hostname: 172.16.212.165
  localhost: true
  nodes:
  - register: false
    role: Master
    config:
      auditlogsdir: /data/memsql/Master/auditlogs/
      datadir: /data/memsql/Master/data
      plancachedir: /data/memsql/Master/plancache
      tracelogsdir: /data/memsql/Master/tracelogs
      port: 3306
  - register: false
    role: Leaf
    config:
      auditlogsdir: /data/memsql/Leaf1/auditlogs
      datadir: /data/memsql/Leaf1/data
      plancachedir: /data/memsql/Leaf1/plancache
      tracelogsdir: /data/memsql/Leaf1/tracelogs
      port: 3307
- hostname: 172.16.212.166
  localhost: false
  ssh:
    host: 172.16.212.166
    private_key: /home/<user>/.ssh/id_rsa
  nodes:
  - register: false
    role: Leaf
    config:
      auditlogsdir: /data/memsql/Leaf2/auditlogs
      datadir: /data/memsql/Leaf2/data
      plancachedir: /data/memsql/Leaf2/plancache
      tracelogsdir: /data/memsql/Leaf2/tracelogs
      port: 3307

license: <license-from-portal.singlestore.com>
high_availability: true
memsql_server_version: 7.3
package_type: rpm
hosts:
- hostname: 172.16.212.165
  localhost: true
  nodes:
  - register: false
    role: Master
    config:
      password: <secure-password>
      port: 3306
- hostname: 172.16.212.166
  localhost: false
  ssh: 
    host: 172.16.212.166
    private_key: /home/<user>/.ssh/id_rsa
  nodes:
  - register: false
    role: Aggregator
    config:
      password: <secure-password>
      port: 3306
- hostname: 172.16.212.167
  localhost: false
  ssh: 
    host: 172.16.212.167
    private_key: /home/<user>/.ssh/id_rsa
  nodes:
  - register: false
    role: Leaf
    config:
      password: <secure-password>
      port: 3306
- hostname: 172.16.212.168
  localhost: false
  ssh: 
    host: 172.16.212.168
    private_key: /home/<user>/.ssh/id_rsa
  nodes:
  - register: false
    role: Leaf
    config:
      password: <secure-password>
      port: 3306