Upgrade to SingleStoreDB 7.3

Step 1: Upgrade SingleStoreDB Toolbox

To upgrade to SingleStoreDB7.3, you must have Toolbox 1.5.3 or later installed prior to the SingleStoreDB upgrade process. It is recommended that you use the latest version of Toolbox when upgrading your cluster.

Run the install command to either install Toolbox if it is not already installed, or upgrade an existing version of Toolbox to the latest version of the package.

Red Hat

sudo yum install singlestoredb-toolbox -y

Debian

1. SingleStore packages are signed to ensure integrity, so the GPG key needs to be added to this host. When done, verify that the SingleStore signing key has been added using apt-key list.

   Shell

   Copy

   wget -O - 'https://release.memsql.com/release-aug2018.gpg' 2>/dev/null | sudo apt-key add - && apt-key list

2. Upgrade Toolbox.

   Shell

   Copy

   sudo apt install singlestoredb-toolbox -y

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

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

Step 2: Upgrade SingleStoreDB

The simplest and preferred upgrade option is an offline cluster upgrade. It is the least error-prone and easiest to perform; however, it requires downtime as all of the nodes in the cluster will be upgraded at the same time, shutting down the entire cluster for the duration of the upgrade.

If the cluster is running with High Availability, you also have the option to perform an incremental online cluster upgrade, which maintains cluster availability throughout the upgrade process. See the instructions in the online upgrade section for more details.

Select an option below to upgrade your cluster.

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

Roll Back from a Failed Upgrade

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

Note that a backup created from a given version of the SingleStoreDB 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 SingleStoreDB engine by removing the engine version(s) you do not want.

   For example, if upgrading to SingleStoreDB 7.3 fails, remove 7.3.

   Shell

   Copy

   sdb-deploy uninstall --version 7.3

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 Backing Up and Restoring Data for more information.

Step 1: Upgrade MemSQL Ops

If you manage your cluster with MemSQL Ops, you must upgrade it to the latest 7.0 version of MemSQL Ops before you can upgrade to SingleStoreDB 7.3.

If you are running Ops 6.0 or later, you can upgrade Ops to the latest version by running the agent-upgrade command.

memsql-ops agent-upgrade

sudo memsql-ops agent-upgrade --file-path /path/to/memsql-ops-XYZ.tar.gz

Step 2: Upgrade SingleStoreDB

The currently supported upgrade option is an offline cluster upgrade. It requires downtime as all of the nodes in the cluster will be upgraded at the same time.

memsql-ops memsql-upgrade --version 7.3

sudo memsql-ops memsql-upgrade --file-path /path/to/memsqlbin_amd64.tar.gz

Synchronous Replication On by Default

In previous versions of SingleStoreDB, in clusters with high availability enabled, replication between master partitions and replica partitions happened asynchronously. Starting with 7.0, synchronous replication is enabled by default for all new databases. And as noted in the upgrade section of this topic, you have the option to opt-out of synchronous replication for the existing databases in your cluster. For more information on synchronous replication, see Replication and Durability and CREATE DATABASE.

Security Change for Resource Pools

Between MemSQL 6.5 to 6.8, all users were able to access all resource pools. Access had to be controlled externally from the database, such as in a client application. Starting in 7.0, users can only access resource pools that they have explicit permission to access when sync_permissions is enabled. Otherwise, no permission checking is done for any user for any resource pool. Refer to Synchronizing Permissions Across Your Cluster for more information.

To ensure current users will be able to access pools immediately after upgrading to 7.3, all existing users will be granted USAGE permissions to all existing and future resource pools if sync_permissions was enabled prior to upgrade (i.e. for each user GRANT USAGE ON RESOURCE POOL '*' TO <user>@<host> is run internally on upgrade to 7.0 or later) unless REVOKE USAGE ON RESOURCE POOL '*' FROM <user>@<host> is run. You will then have to explicitly grant USAGE permissions to specific resource pools for those users and any other new users created. Refer to Set Resource Limits for more information.

Many Existing Engine Variables are Now Sync Variables

The following engine variables from 6.8 are now Sync Variables, which means you set the value on the master aggregator and the change is propagated across your cluster. You no longer have to set and manage these variables on each node in the cluster.

Global variables

• auditlog_disk_sync

• columnstore_disk_insert_threshold

• columnstore_flush_bytes

• columnstore_ingest_management_queue_timeout

• columnstore_segment_rows

• disk_plan_expiration_minutes

• enable_columnstore_ingest_management

• enable_disk_plan_expiration

• explain_expression_limit

• forward_aggregator_plan_hash

• geo_query_info

• geo_sphere_radius

• internal_columnstore_window_minimum_blob_size

• load_data_internal_compression

• load_data_max_buffer_size

• load_data_read_size

• load_data_write_size

• materialize_ctes

• max_connect_errors

• max_prepared_stmt_count

• multi_insert_tuple_count

• pipelines_batches_metadata_to_keep

• pipelines_extractor_debug_logging

• pipelines_kafka_version

• pipelines_max_concurrent

• pipelines_max_concurrent_batch_partitions

• pipelines_max_errors_per_partition

• pipelines_stderr_bufsize

• plan_expiration_minutes

• read_advanced_counters

• replication_timeout_ms

• snapshot_trigger_size

• sync2_timeout

• synchronize_database_timeout

Session Variables

• character_set_server

• collation_connection

• collation_database

• collation_server

• enable_binary_protocol

• enable_broadcast_left_join

• enable_local_shuffle_group_by

• enable_multipartition_queries

• enable_skiplist_sampling_for_selectivity

• explain_joinplan_costs

• ignore_insert_into_computed_column

• inlist_precision_limit

• leaf_pushdown_default

• leaf_pushdown_enable_rowcount

• lock_wait_timeout

• max_broadcast_tree_rowcount

• max_subselect_aggregator_rowcount

• optimize_constants

• optimize_expressions_larger_than

• optimize_huge_expressions

• optimize_stmt_threshold

• optimizer_warnings

• report_mpl_optimizations

• reshuffle_group_by_base_cost

• sampling_estimates_for_complex_filters

• sql_select_limit

• statistics_warnings

See the List of Engine Variables for more information on these variables.