Chaos Engineering for SQL Server
summary
Shows concrete experiments: use PowerShell and T‑SQL to stop the SQL Server service on a primary VM in Azure and observe availability group behavior; initial failback stays failed because the clustered role default allows one unexpected failure per six hours, so tests change it to 2 failures per hour and the AG then fails back successfully. Also demonstrates backup pain—an “instant restore” hangs at 99% for five hours requiring a six‑hour manual restore—and Kubernetes tests that delete a pod and spin up 10 SQL Server pods with stress tests to watch auto‑healing and capacity limits.
AI-written summary · about
chapters (9)
- 0:00Introduction to chaos engineering
- 1:47Defining chaos engineering
- 4:36Real-world implementations
- 7:47Environment analysis
- 11:18Identifying failure scenarios
- 15:21Potential testing scenarios
- 24:20SQL Server failover experiment
- 35:17Kubernetes and SQL Server
- 42:12Conclusion and resources
related talks
30mChaos Engineering for SQL Server
47mPerfecting business continuity for Azure SQL DB
47mDisaster Recovery Strategies for SQL Server
50mSQL Server to Azure SQL: Performance and Availability
47mPods & Pages: Databases in Kubernetes
25mChaos Engineering for Cloud native Apps- 47mDisaster Recovery Strategies for SQL Server
46mChaos Experiments - Datacenter Stress Testing