Interesting Aurora MySQL Feature: The Buffer Pool Survives Restarts
Lemme start this off by saying this is probably irrelevant to you. (It's irrelevant to me, too.)
If you're strapped for time, just skip past this blog post.
Lemme start this off by saying this is probably irrelevant to you. (It's irrelevant to me, too.)
If you're strapped for time, just skip past this blog post.
Amazon just announced new X2iedn instance types for Amazon RDS SQL Server. They're a sweet deal for people who want a high-performance managed database, with really fast cores and more memory per core than you can get in Azure's managed SQL offerings.
Say your workload needs 8 CPU cores. Here's a quick comparison between a few instance types, all priced with SQL Server Standard Edition licensing included:
In May, Amazon brought out a new Aurora I/O Optimized Serverless instance type. By switching to it, we cut our database costs by 43% overnight, saving us about $1,200 per month.
No strings attached. Just lower prices.
You, dear reader, are most likely a Microsoft SQL Server user - either a DBA or developer.
Set your pencil down for a second because you're not going to learn about a Microsoft product today, nor are you going to learn something that is going to be immediately useful to you in your job. Today, I'm writing about a completely different product just to give you a better insight on what else is out there.
Our SQL Server monitoring product, SQL ConstantCare®, uses Amazon Aurora on the back end. I blogged about our choice of database back in 2018, and at the time, I said: I know, I know. The Microsoft geek in you – and me – wants us to use SQL Server on the back end, but here’s…
If you're looking for SQL Server news, just skip this post. I'm going to talk about general business & capacity planning type stuff here today.
Our SQL ConstantCare® customers install an app that polls diagnostic data from their SQL Servers and Azure SQL Databases, upload it to us daily, and then automatically get advice on what they should do next.
In our behind-the-scenes posts about building SQL ConstantCare®, I've written about how we picked serverless architecture for the application layer, and how we picked AWS Aurora for the database layer. Hosting costs were a big driving factor in those decisions - so how has that worked out?
Presented for your enjoyment, here are our total SQL ConstantCare® hosting costs (including both production and development environments) from AWS Billing Explorer for a rolling 30-day period as of when I'm writing this post:
I just updated PasteThePlan, and the change you'll notice first is that we're using the latest version of Justin Pealing's html-query-plan. It adds missing index hints, yellow bangs for warnings like implicit conversions and no join predicate, and more. Check out this example plan:
Plus variable line widths for different amounts of data:
Staving off obsoletion
Brent has recently set aside "free" time to learn about stuff up in the cloud. I only put free in quotes because we do have to do something with a cloud theme, but we can pick whatever we want.
Naturally, I chose the hardest thing with the least practical use.
Brent had an idea that we should set aside a day per month where we could build things in the cloud and blog about our experiences. I was tasked with Amazon RDS for SQL Server: create an instance, configure backups and test point-in-time restores. After grabbing some coffee, I logged into the AWS console. We…
We're trying something new at the company: Builder Day. We define a slightly-out-of-the-norm task, and then the team splits up and tackles the task on different cloud platforms, writing it up as we go. These posts aren't going to make you an expert on the topic - they're just meant to let you skim through technologies you might not otherwise get the chance to play with. The cloud changes fast, so some of this is just about seeing what providers are up to these days.
Richie and I attended the AWS re:Invent conference in Vegas last week. Here's some of my favorite takeaways about Amazon Aurora, their homegrown relational database with MySQL compatibility.
1. AWS has a grudge against Larry Ellison. Andy Jassy's keynotes made repeated jokes about Oracle's cloud product (or lack thereof), the high cost of proprietary databases, and expensive sailboat hobbies. Larry's big, bold personality makes for an easy target, but I couldn't help but wonder if AWS will come after SQL Server's costs next.
So you're hosting your SQL Server in the cloud - say Amazon EC2, Azure VM, or Google Compute Engine - and you've noticed that when you're running a backup or a DBCC CHECKDB, you suffer from extreme performance problems.
Queries run slow, and even worse, applications report timeout errors even just trying to connect to SQL Server. More symptoms can include database mirroring and cluster failovers. What's going on?
Platform-as-a-Service users (Azure SQL DB, Amazon RDS) often ask me: How can I move my data into the cloud? Can I just take a backup on-premises, and restore up in the cloud? How can I use the cloud as inexpensive disaster recovery? Once I go to PaaS, why can't I just get a backup file with…
You're hosting your SQL Server databases in Amazon RDS, and performance has been getting slower over time. You're not sure if it's storage IOPs, instance size, SQL Server configuration, queries, or indexes. What's the easiest way to find out?
Ask a few questions:
When you build SQL Servers in your data center, and you license the host with Enterprise Edition, you get the ability to run as many virtual SQL Servers as you want on that hardware.
In the cloud, though, you haven't had that luxury. In the past, with Azure VMs and Amazon Web Services' EC2 VMs, you've had to license each individual VM. You weren't able to guarantee that your VMs all lived on the same host, so you had to pay through the nose.
... is to use a SQL Server where a robot does it for you! Let's take a look at how you can do this in AmazonRDS's hosted SQL Server these days. Normally, restoring transaction logs is super tedious. You've got to restore all the files in the right order, for every single database. Even if…
Let's skip the shenanigans and get right down to it - you're responsible for SQL Server and someone in your company wants to move things into Amazon Web Services (AWS). You've got SQL Server setup covered thanks to our helpful SQL Server setup checklist and you're confident you've got hardware under control, but things are different up in the clouds.
Amazon Relational Database Service (RDS) now supports multi-availability-zone SQL Servers. This means you can have a primary database in one data center, and a secondary replica in another data center.
When your primary server goes down, OR when the entire AZ goes down, you can fail over to the secondary with zero data loss and keep right on going. When the primary comes back online, you can fail right back, again with no data loss.
Time for a thought exercise.
You've got a database application that has bursty and unpredictable loads. Out of nowhere, you'll suddenly get socked with a large amount of SELECT queries. Due to the way the app is written, you can't cache the query results - the queries keep changing, and the business wants data from within the last couple of minutes.