2024: Domino Containers - The Next Step. News from the Domino Container commu...
Always on availability groups way too deep
1. AlwaysOn Availability
Groups
Way Too Deep
Joey D’Antoni
SQL Saturday #164 Cleveland
18 August 2012
2. About Me
Principal Architect SQL Server, Comcast Cable
@jdanton
Joedantoni.wordpress.com (Slides will be here and on SQL Sat site)
jdanton1@yahoo.com
3. Agenda
Overview of AlwaysOn
Extended Events Briefly
What Happens When?
Turn on AlwaysOn
We Build an Availability Group
We add data to a Primary DB
We backup the transaction log on the secondary
We query the secondary DB
4. Warning
You are going to see a few things that aren’t fully
documented
We aren’t touching anything—just looking to see what’s
going on
I’m telling you what I think is happening, I’m still trying to
get answers on some of it
10. Creating an Availability Group
Object in AD and DNS Gets Created (Listener)
Database(s) get restored onto secondary
Lots of Metadata gets created to Manage the Availability
Group
12. Moving Data
Database Mirroring used a single thread per database to move data
Always On is different—it uses a request pool that is shared between all
AlwaysOn Databases
On the primary messages the active log scanner is the log pole.
When a secondary is ready to receive log blocks a message is sent to the
primary to start the log scanning.
This message is handled by a worker in the HadrThreadPool.
15. Transaction Log Backup on Secondary
One of the new features of 2012
Allows us to flush the log on the primary database by backing up on the
secondary
17. Querying Secondary Instance
Another Big Feature of AlwaysOn Replicas
Runs in Snapshot Isolation Transaction Level to Minimize Blocking Issues
Creates Secondary Stats where missing—in TempDB
20. Summary
AlwaysOn is pretty cool
It’s clear a lot of work went into this
It’s fairly complicated, but the good news is that it’s easy to work on