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.
Potential Error
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.
Gotchas
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!
Storage Issue I Encountered When Upgrading My BDC
Enjoy!
Love the Big Data Clusters content! I have been working in SQL for 2 years now in DC area, and my company is starting to look into polybase technology. To be specific, utilizing external tables to read parquet files from a data pool. I look forward to your series on the BDC! Keep it up man!
Thank you Andy!