[Video] SQL Server Always On Availability Groups 101
I got a few closely related Availability Groups questions at https://pollgab.com/room/brento and decided to do a half-hour introduction to AGs:
https://www.youtube.com/watch?v=faeOAugqxcs
I got a few closely related Availability Groups questions at https://pollgab.com/room/brento and decided to do a half-hour introduction to AGs:
https://www.youtube.com/watch?v=faeOAugqxcs
SQL Server Always On Availability Groups help you build a more highly available database server by spanning your database across two or more SQL Server instances. When the primary goes down, the secondary can take over. You can also scale out reads to the secondary servers. Distributed Availability Groups take this a step further and…
Questions about the overall project:
What are your RPO and RTO goals?
Are there financial penalties if we miss the goals? (Like contracts, refunds to customers, etc)
Does this app have regularly scheduled maintenance windows, or is it 24/7?
What’s the ballpark size of the data today? In 3 years?
Easy Lover I don't blog a lot about AGs. If we're being honest (and I do try to be honest with you, dear reader), I just like performance tuning topics way more. When new features get announced for AGs, some of you may ooh and aah, but not me. I Make A Face I don't…
Cash Rules
Most people, when they get through paying for Azure, and SQL Server Enterprise Licensing, are left with a hole in their wallet that could only be filled with something that says "Bugatti", and has a speedometer with an infinity sign at the end.
A commenter commented
That the "New AG Wizard" in SSMS 2017 had surfaced the Direct Seeding mode for AGs.
I was pretty psyched about this because I think it's a great feature addition to AGs that can solve for a pretty big hump that people run into when they create databases regularly.
You’re a database administrator, Windows admin, or developer. You want to build a Microsoft SQL Server environment that’s highly available, and you’ve chosen to use Always On Availability Groups.
In this white paper we built with Google, we’ll show you:
I'm excited to finally be able to talk about something Erik, Tara, and I have been working on for the last few months.
Here in the SQL Server community, when I mention cloud, you probably think of two companies: Microsoft and Amazon. We've been blogging about SQL in AWS for years, and Microsoft throws a ton of marketing money at the SQL Server community, talking about Azure at every possible conference and user group.
Today's brief Stack Overflow outage reminded me of something I've always wanted to blog about:
There's a gray bar across the top that says, "This site is currently in read-only mode; we'll return with full functionality soon."
I often hear companies say, "We can never ever go down, so we'd like to implement Always On Availability Groups."
Let's say on January 1, 2016, you rolled out a new Availability Group on SQL Server 2014. It's the most current version available at the time, and you deploy Service Pack 1, Cumulative Update 4 (released 2015/12/22). You're fully current, and it's a stable engine from 2014 - how many more bugs can they find, right?
When Database Mirroring came out in SQL Server 2005 Service Pack 1, we quickly dropped Log Shipping as our Disaster Recovery solution. Log Shipping is a good feature, but I can failover with Asynchronous Database Mirroring faster than I can with Log Shipping.
When Always On Availability Groups (AG) came out in SQL Server 2012, we were excited to get rid of Transactional Replication, Failover Clustering and Database Mirroring. It solved our reporting needs (your mileage may vary), our High Availability needs and our Disaster Recovery needs.
One of the most popular things in our First Responder Kit is our HA/DR planning worksheet. Here's page one: In the past, we had three columns on this worksheet - HA, DR, and Oops Deletes. In this new version, we changed "Oops" Deletes to "Oops" Queries to make it clear that sometimes folks just update…
I'll get right to the point While you're Direct Seeding, you have to be careful with any other full or differential backup jobs running on the server. This is an artifact of the Direct Seeding process, but it's one you should be aware of up front. In the screencap below, courtesy of sp_whoisactive there's a…
From the Mailbag In another post I did on Direct Seeding, reader Bryan Aubuchon asked if it plays nicely with TDE. I'll be honest with you, TDE is one of the last things I test interoperability with. It's annoying that it breaks Instant File Initialization, and mucks up backup compression. But I totally get the…
As of this writing, this is all undocumented
I'm super interested in this feature, so that won't deter me too much. There have been a number of questions since Availability Groups became a thing about how to automate adding new databases. All of the solutions were kind of awkward scripts to backup, restore, join, blah blah blah. This feature aims to make that a thing of the past.
This post covers two scenarios
You either created a database, and the sync failed for some reason, or a database stopped syncing. Our setup focuses on one where sync breaks immediately, because whatever it's my blog post. In order to do that, I set up a script to create a bunch of databases, hoping that one of them would fail. Lucky me, two did! So let's fix them.
One of my least favorite things about Availability Groups
Well, really, this goes for Mirroring and Log Shipping, too. Don't think you're special just because you don't have a half dozen patches and bug fixes per CU. Hah. Showed you!
How hard is it for a systems administrator who's used to running SQL Server on Windows Clusters to tackle Availability Groups? Our example system administrator knows a bit of TSQL and their way around Management Studio, but is pretty new to performance tuning. Well, it might be harder than you think. First, let's look at…
One of your SQL Servers is going to fail.
When one of your AG members goes down, what happens next is just like opening a new SSMS window and typing BEGIN TRAN. From this moment forwards, the transaction log starts growing.
In theory, when you configure AlwaysOn Availability Groups with synchronous replication between multiple replicas, you won't lose data. When any transaction is committed, it's saved across multiple replicas.
That's the way it works, right? I mean, except when you restart your synchronous replicas, or patch them, or they just stop working for any number of reasons. The primary keeps right on trucking, accepting deletes/updates/inserts, without telling end users that all their eggs are in a single basket.