In my previous posts, I showed you how to deploy a single node cluster and a multi-node cluster. That’s find and dandy but how do you upgrade to the newest SQL Server CU? This blog post will show you how to easily upgrade a SQL Server Big Data Cluster. This method applies to a single node or multi-node cluster. It does not matter how many nodes your BDC has, this upgrade process will work.
How to Upgrade a SQL Server Big Data Cluster
My specific scenario: I deployed a Big Data Cluster on a single node kubeadm cluster. The version of SQL Server that was installed is 2019 RTM-GDR as shown in the Azure Data Studio screenshot below:
The current release of SQL Server (at the time of this publishing) is RTM-CU1.
So I will upgrade my single node cluster from GDR to CU1.
The actual upgrade command is quite simple. You run the below azdata command:
azdata bdc upgrade -n mssql-cluster -t 2019-CU1-ubuntu-16.04 -r mcr.microsoft.com/mssql/bdc
Before I do that, here’s a break down of the command:
-n (required) is the namespace. By default, when you deploy a dev/test Big Data Cluster the namespace is set to “mssql-cluster.”
-t (required) is for the image tag. Microsoft will always release a new image tag for each image. So in my upgrade example, I will be using the 2019-CU1-ubuntu-16.04 image tag.
-r (optional) is for the repository. This option is not mandatory since by default the azdata command will search the default Microsoft image repository. But if you wanted to specify it, it is mcr.microsoft.com/mssql/bdc
Once I have all the options set, I press Enter and sit back. Below is a screenshot of every service that was upgraded:
Once the update was completed successfully, I ran the same “SELECT @@VERSION” and this time got:
Yay! Now my Big Data Cluster is running RTM-CU1. The upgrade did take a while. Every SQL Server instance has to be upgraded on all the pods so that can take some time.
There is a known issue that a timeout can occur during the upgrade process. The error is, “Control plane upgrade failed. Failed to upgrade controller.” If you get that error, you can modify the “controller-upgrade-configmap” by running the command below:
kubectl edit configmap controller-upgrade-configmap
and edit the following parameters:
controllerUpgradeTimeoutInMinutes from default 5 to 20
totalUpgradeTimeoutInMinutes from default 10 to 40
componentUpgradeTimeoutInMinutes from default 30 to 45
Save and Exit.
This should allow for longer timeouts. You might have to test a couple options based on how many nodes your BDC has.
The above scenario was updating a Big Data Cluster from a supported release. Microsoft officially supports BDCs starting from SQL Server 2019 GDR1. But what if you have a previous version of BDCs, say CTP or release candidate? In that case you’ll have to backup any data you have, delete your cluster, uninstall azdata, install the updated azdata, and deploy your big data cluster anew. A little cumbersome but that’s how it is. In fact, no one should be running an unsupported release of Big Data Clusters anyway!