Upgrade via SingleStore Toolbox

With Internet Access

sudo yum install singlestoredb-toolbox -y

Without Internet Access

Use one of the following buttons to download the latest RPM, Debian, or tarball singlestoredb-toolbox file to a location accessible by your cluster.

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

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

Pre-Upgrade Confirmation

Note:  The cluster will not be upgraded when running this command.

sdb-deploy upgrade --precheck-only

Typical output from a cluster that is ready to be upgraded:

Toolbox will perform the following actions:
  · Download singlestoredb-server x.yy.zx

Would you like to continue? [y/N]: y
✓ Downloaded singlestoredb-server production:latest
Toolbox is about to perform following checks:
  · Cluster health checks:
    - Check that all nodes are online and healthy
    - Check that all partitions are healthy
  · Check that there are no pending rebalance operations
  · Take snapshots of all databases

Would you like to continue? [y/N]: y
Checking cluster status
✓ Nodes are online
✓ Partitions are healthy

✓ Snapshots completed
✓ All checks passed successfully
Operation completed successfully

Clusters with Internet Access

Offline Upgrade

sdb-deploy upgrade --version 7.3

Online Upgrade

sdb-deploy upgrade --online --version 7.3

Clusters without Internet Access

Use one of the following buttons to download the latest RPM, Debian, or tarball singlestoredb-server file to a location accessible by your cluster. This file contains both the SingleStore binary and the low-level management tool, memsqlctl.

Run the sdb-deploy upgrade command and reference the appropriate file in the --file-path option. Running sdb-deploy upgrade (versus upgrading the package via the package manager) will perform an offline restart of all the nodes to ensure the cluster is using the new version.

Offline Upgrade

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

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

Online Upgrade

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

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

Synchronous Replication On by Default

In previous versions of SingleStore, in clusters with high availability enabled, replication between primary 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.