Always On is sinds SQL Server 2012 de standaard voor high availability bij MSSQL. Een freelance SQL DBA met Always On-ervaring is gewild bij elke organisatie die uptime serieus neemt. Wat een productie-klare implementatie inhoudt.
Windows Server Failover Cluster als basis
Always On heeft een WSFC nodig, ook al gebruikt het zelf geen shared storage. Quorum-configuratie (file share witness, Azure Cloud Witness) is het eerste wat we vastpinnen, want een verkeerd quorum betekent split-brain bij netwerk-issues. Drie nodes met file share witness is voor de meeste organisaties de juiste configuratie.
Synchroon, asynchroon en automatic failover
Synchrone replica's geven nul data-verlies maar latency-impact op writes. Asynchrone replica's voor disaster recovery over WAN, geen impact op productie maar potentieel data-verlies bij failover. Automatic failover alleen tussen synchrone replica's binnen hetzelfde datacenter.
Listener en read-only routing
De Availability Group Listener is een DNS-name die altijd naar de primary wijst. Applicaties verbinden alleen met de listener, nooit met node-namen direct. Read-only routing stuurt readers naar leesreplicas op basis van connection string-flag (ApplicationIntent=ReadOnly), wat reporting van OLTP scheidt.
Backup-strategie in een AG
Backups op een leesreplica draaien ontlast productie. Maar transaction log backups moeten op één replica continu doorlopen. We configureren backup preference correct (Prefer Secondary) en testen restore vanaf alle nodes om te bewijzen dat de chain werkt.
Monitoring en patch-cyclus
AlwaysOn_health Extended Events-sessie, sys.dm_hadr-views, en synced/syncing-state per database. Cumulative Updates rollen we eerst op secondaries uit, daarna failover, dan de oude primary. Een goede AG laat patchen plaatsvinden zonder downtime.
Verwant: Interim SQL DBA, Failover Cluster Instance.