Upgrade to SingleStore 7.8

Important Notes About Upgrading

This topic describes how to upgrade SingleStore. Please read the following information thoroughly before upgrading.

Once the upgrade is complete, refer to the Post-Upgrade Considerations section for additional information on behavioral changes that you should be aware of.

If upgrading from a version of MemSQL earlier than SingleStore 7.0, please note the following.

Verify Your Cluster is Ready for Upgrade

Prior to upgrading your cluster, SingleStore recommends that you take a backup as a standard precautionary measure. See Back Up and Restore Data.

In addition, run the following SQL commands from the Master Aggregator to confirm that the following are true.

• All leaf nodes ("leaves") are online.

  SQL

  Copy

  SHOW LEAVES;

• All aggregators are online.

  SQL

  Copy

  SHOW AGGREGATORS;

• There are no partitions with an Orphan role.

  SQL

  Copy

  SHOW CLUSTER STATUS;

• No rebalance or restore redundancy is necessary.

  SQL

  Copy

  EXPLAIN REBALANCE PARTITIONS;

  SQL

  Copy

  EXPLAIN RESTORE REDUNDANCY;

After you have backed up your data and verified your cluster is ready, you are ready to upgrade your cluster to the latest version of SingleStore using the SingleStore management tools.

Upgrade Your Cluster

sudo yum install singlestoredb-toolbox -y

sudo yum install /path/to/singlestoredb-toolbox.rpm -y

sudo apt install /path/to/singlestoredb-toolbox.deb -y

sdb-deploy upgrade --file-path /path/to/singlestoredb-server.rpm

sdb-deploy upgrade --file-path /path/to/singlestoredb-server.deb

sdb-deploy upgrade --online --file-path /path/to/singlestoredb-server.rpm

sdb-deploy upgrade --online --file-path /path/to/singlestoredb-server.deb

Confirm that the Upgrade Succeeded

Toolbox displays the progress of the upgrade and reports whether the upgrade succeeded. While typically not required, you may also perform an in-depth review of the post-upgrade cluster to reaffirm that the upgrade succeeded.

1. Confirm that all nodes are online and healthy.

   The State column should display online for each node.

   Shell

   Copy

   sdb-admin show-cluster

   ✓ Successfully ran 'memsqlctl show-cluster'
   +---------------------+-----------+------+--------------------+-----------+-----------+--------+--------------------+------------------------------+--------+-------------------+
   |        Role         |   Host    | Port | Availability Group | Pair Host | Pair Port | State  | Opened Connections | Average Roundtrip Latency ms | NodeId | Master Aggregator |
   +---------------------+-----------+------+--------------------+-----------+-----------+--------+--------------------+------------------------------+--------+-------------------+
   | Leaf                | 127.0.0.1 | 3307 | 1                  | null      | null      | online | 2                  |                              | 2      |                   |
   | Aggregator (Leader) | 127.0.0.1 | 3306 |                    | null      | null      | online | 0                  | null                         | 1      | Yes               |
   +---------------------+-----------+------+--------------------+-----------+-----------+--------+--------------------+------------------------------+--------+-------------------+

2. Confirm that all databases are healthy.

   The summary column should display healthy for each database.

   Shell

   Copy

   sudo memsqlctl query --sql "SELECT * FROM information_schema.MV_DISTRIBUTED_DATABASES_STATUS;"

   +---------------+----------------+--------------------+---------+--------+-------------+------------+---------+------------+---------------+---------+---------------+
   | database_name | num_partitions | num_sub_partitions | summary | online | replicating | recovering | pending | transition | unrecoverable | offline | sync_mismatch |
   +---------------+----------------+--------------------+---------+--------+-------------+------------+---------+------------+---------------+---------+---------------+
   | test          | 16             | 64                 | healthy | 16     | 16          | 0          | 0       | 0          | 0             | 0       | 0             |
   +---------------+----------------+--------------------+---------+--------+-------------+------------+---------+------------+---------------+---------+---------------+

3. Confirm that all nodes reflect the version specified in the sdb-deploy upgrade command.

   The Version column displays the version that each node is running.

   Shell

   Copy

   sdb-admin list-nodes

   +------------+--------+-----------+------+---------------+--------------+---------+----------------+--------------------+--------------+
   | MemSQL ID  |  Role  |   Host    | Port | Process State | Connectable? | Version | Recovery State | Availability Group | Bind Address |
   +------------+--------+-----------+------+---------------+--------------+---------+----------------+--------------------+--------------+
   | CBDC2807B7 | Master | 127.0.0.1 | 3306 | Running       | True         | 8.7.11  | Online         |                    | 127.0.0.1    |
   | EC33CC5A08 | Leaf   | 127.0.0.1 | 3307 | Running       | True         | 8.7.11  | Online         | 1                  | 127.0.0.1    |
   +------------+--------+-----------+------+---------------+--------------+---------+----------------+--------------------+--------------+

Roll Back from a Failed Upgrade

Currently, SingleStore does not support downgrading directly. Use the following steps to roll back to an earlier version of SingleStore using the backup made at the beginning of this upgrade guide.

Note that a backup created from a given version of the SingleStore engine can only be restored to the same engine version or later.

1. Make a backup of the cluster configuration.

   Shell

   Copy

   sdb-deploy generate-cluster-file

2. Delete all of the nodes in the cluster.

   Shell

   Copy

   sdb-admin delete-node --stop --all

3. Use the following command to roll back to an earlier version of the SingleStore engine by removing the engine version(s) you do not want.

   For example, if upgrading to SingleStore 7.8 fails, remove 7.8.

   Shell

   Copy

   sdb-deploy uninstall --version 7.8

4. Unregister all hosts in the cluster.

   Shell

   Copy

   sdb-toolbox-config unregister-host --all

5. Recreate the cluster using the cluster configuration captured in the cluster file. Note that the cluster file may contain the engine version, so be sure to update the cluster file with the engine version you wish to restore.

   Shell

   Copy

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

6. Restore the cluster's data from the backup that was made earlier. Refer to Back Up and Restore Data for more information.

Post-Upgrade Considerations

When upgrading to SingleStore 7.8, you should be aware of the following changes to system behavior or default configuration settings. The behavior of a cluster upgraded from an earlier version to SingleStore 7.8 may differ compared to a newly installed cluster on SingleStore 7.8 as described below. Most of the changes fall into two categories:

• In some versions, the default value for a configuration variable was changed compared to previous versions, but clusters upgraded from earlier versions retain their previous setting, both if it was set to a specific value or if it was not explicitly set and hence using the previous default. In some of these cases, SingleStore recommends to update your configuration to the new default if you were previously using the old default, after appropriate testing.

• Some new features are automatically enabled by default on newly installed SingleStore 7.8 clusters but not automatically enabled on clusters upgraded from an earlier version to 7.8. In some of these cases, SingleStore recommends to enable the new features, after appropriate testing.