So, the point in the previous blog post was to leverage Persistent Volume Claims – PVC for data when using SQL server that it is needed in a stateful manner. But what happens when we don’t create SQL server in AKS without a PVC?
Following on from my last post after creating AKS, I now want to work with SQL server. First step, load up Azure cloud shell.
What is Azure Kubernetes Service? Probably makes sense to tell you what Kubernetes is first. As Kubernetes states themselves “also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.” If you want to dig into the depths then head over to Andrew – http://www.dbafromthecold.com
Just a really quick FYI for the readers. If you are using Managed Instances in Azure (If not, why not?) and you connect vis SSMS (SQL Server Management Studio) and run the classic commands SELECT @@VERSION, what will you see?
It is quite a common requirement to restore a copy of a database to the same Azure SQL server, you just issue a COPY OF command. What if you need to restore a copy to a different target Azure SQL server? Well its similar, just with a slight difference in that you need to refer back to the source server within your code.
Being aligned to a global cloud like Microsoft Azure you have choices. Whether that is Azure SQL Database or Azure Database for MySQL for your relational database, it does not matter that is down to you are your design choices. The point here is that Azure has variations and flexibility with so many choices and this is no different within the “Big Data” analytics space.
When moving to a cloud model for your database stack no doubt you will be involved in a costing exercise. The good news is if you have Software Assurance with your existing licenses then expect some cost savings when moving to the cloud. You can save up to 70% cost when compared to a pay as you go model.
I always follow a contained user model when setting up users within my Azure SQL Database. I do this so the user in question has access to only specific database(s) and does not have a login to the server. It becomes even more apparent the importance of this when you design a solution based on failover groups.
When a failover occurs to the secondary, I want a pleasant experience for the user. With the contained user model, the user goes with the database. I don’t want to do admin work on the new primary (post failover). Let’s see.
There is a new (ish) interface to looking and configuring backups for your Azure SQL Database. This can be found within the settings section of the SQL Server.
As you can see, by default we have 7 days retention to allow for PITR – Point In Time Recovery, anything longer you will need to setup long term retention.
If you are building database solutions in Azure , using Azure SQL Database then you will know that you have a purchasing option decision to make. That being should you use a vCore model or DTU approach?