A Fine Slice Of SQL Server
Chris Taylor has a point updates to jump in Azure Kubernetes Service:
As it is late at night my brain wasn’t working as it should be but thought I’d put a quick blog out there to say that if you are on v1.11.5 and want to upgrade to >= v1.13.10 then you have to do this in a 2 stage process by upgrading to v1.12.8 first:
Fortunately, upgrading is pretty easy using the Azure command line or even the Azure portal.
Comments closedAnthony Nocentino shows us how we can use kubectl logs to read the SQL Server Error Log:
We can use follow flag and that will continuously write the error log to your console, similar to using tail with the -f option. If you remove the follow flag it will write the current log to your console. This can be useful in debugging failed startups or in the case below, monitoring the status of a database restore. When finished you can use CTRL+C to break out and return back to your prompt.
Read on for a brief demonstration.
Comments closedChris Adkin shows off parallelism in Azure DevOps continuous integration pipelines:
A SQL Server data tools project is checked out of GitHub, built into a DacPac, four containerized SQL Server instances are spun up using clones of the ‘Seed’ docker volume. The DacPac is applied to a database running inside each container, which a tSQLt test is then executed against, finally, at the end very end the tSQLt results are aggregate and published.
This is an interesting approach to the problem of lengthy tests: run them on several separate machines concurrently.
Comments closedAllan Hirt makes a disappointing discovery:
This one is going to be a short post. One of the big capabilities of SQL Server 2019 – the ability to deploy AGs using containers – is not shipping when SQL Server 2019 is released.
Read the whole thing, which isn’t much longer than my snippet. But Allan does promise an update for when it does hit.
Comments closedI have a solution to a problem which vexed me for quite some time:
Quite some time ago, I posted about PolyBase and the Hortonworks Data Platform 2.5 (and later) sandbox.
The summary of the problem is that data nodes in HDP 2.5 and later are on a Docker private network. For most cases, this works fine, but PolyBase expects publicly accessible data nodes by default—one of its performance enhancements with Hadoop was to have PolyBase scale-out group members interact directly with the Hadoop data nodes rather than having everything go through the NameNode and PolyBase control node.
Click through for the solution.
Comments closedAnthony Nocentino tries using strace to diagnose SQL Server process activity in a container:
We’re attaching to an already running docker container running SQL. But what we get is an idle SQL Server process this is great if we have a running workload we want to analyze but my goal for all of this is to see how SQL Server starts up and this isn’t going to cut it.
My next attempt was to stop the sql19 container and quickly start the strace container but the strace container still missed events at the startup of the sql19 container. So I needed a better way.
Don’t worry—Anthony finds a better way.
Comments closedAndrew Pruski shows off Kubernetes port forwarding and how to connect to a SQL Server instance:
The load balanced service’s IP can be usually be used to connect into the SQL instance running in the pod, but what if we’re unable to connect? Does the issue lie with the service or the pod?
In order to narrow this down, port forwarding can be used to directly connect to the pod: –
Read the whole thing.
Comments closedAnthony Nocentino has a three-part series on persisting SQL Server data in Docker containers. Part 1 takes us through volumes:
Let’s talk about how we can use Docker Volumes and SQL Server to persist data. If we want to run SQL Server in a container we will want to decouple our data from the container itself. Doing so will enable us to delete the container, replace it and start up a new one pointing at our existing data. When running SQL Server in a container will store data in /var/opt/mssql by default. When the container starts up for the first time it will put the system databases in that location and any user databases created will also be placed at this location by default.
Part 2 looks at how volumes differ between the Linux and Mac/Windows versions of Docker:
So in my previous post, we discussed Docker Volumes and how they have a lifecycle independent of the container enabling us to service the container image independent of the data inside the container. Now let’s dig into Volumes a little bit more and learn where Docker actually stores that data on the underlying operating system.
Part 3 ties it in with SQL Server:
Makes sense…we changed where SQL Server is reading/writing data. macOS doesn’t support a file mode called O_DIRECT which allows for unbuffered read/write access to the file opened using the open system call. O_DIRECT is used by systems that manage their own file caching, like relational database management systems (RDBMS). So as SQL starts up and tries to open the master database with O_DIRECT the files can’t be opened because the macOS kernel doesn’t support this mode. And this is the reason why we have to have that Linux VM around. That Linux VM will support O_DIRECT option on the file opened. See more about this at the GitHub issue here.
Definitely worth getting a handle on this if you’re interested in containers.
Comments closedSteve Jones continues a series on continuous integration, containers, and all that is good in life:
The only way to build a database project in SQL Server is with an actual SQL Server. In this case, I don’t have any code that would error on LocalDB, so I’ll just use that. I coudl specify my local SQL Server development database if I had the need.
This is a test build, so I also don’t need any SQL Compare options or other switches.
Getting code into source control and building continuous integration around it has become a lot easier over the past several years. Easy enough that you can work a simple system out in a day or two of experimentation.
Comments closedSteve Jones shows how to expose multiple ports when spinning up a container:
I was working with containers recently with Jenkins. I didn’t want the server process running on my machine all the time, but I did need to allow some communication. Jenkins uses 8080 by default, but agents need another port.
I figured there was a way to do this, and I found it on Stack Overflow, which is the perfect forum for a question like this. The answer?
You’ll need to click through for the answer.
Comments closed