# Walking Through an Unplanned Failover: SQL Server Availability Groups on Kubernetes

DevFeed: [Walking Through an Unplanned Failover: SQL Server Availability Groups on Kubernetes](<https://devfeed.tech/articles/walking-through-an-unplanned-failover-sql-server-availability-groups-on-kubernetes-17554.md>)

Original publisher: [Read original article](<https://www.nocentino.com/posts/2026-04-19-unplanned-failover-walkthrough-sql-server-kubernetes-operator/>)

Author: Anthony Nocentino

Published: 2026-04-19T15:00:00Z

Content type: tutorial

Language: en

Sources: [Kubernetes on Anthony Nocentino's Blog](<https://devfeed.tech/sources/kubernetes-on-anthony-nocentino-s-blog.md>)

Topics: [sql-server](<https://devfeed.tech/topics/sql-server.md>), [Availability](<https://devfeed.tech/topics/availability.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Databases](<https://devfeed.tech/topics/databases.md>)

Tags: [automatic](<https://devfeed.tech/tags/automatic.md>), [availability-groups](<https://devfeed.tech/tags/availability-groups.md>), [container](<https://devfeed.tech/tags/container.md>), [containers](<https://devfeed.tech/tags/containers.md>), [crash](<https://devfeed.tech/tags/crash.md>), [database](<https://devfeed.tech/tags/database.md>), [failover](<https://devfeed.tech/tags/failover.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [load](<https://devfeed.tech/tags/load.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [operator](<https://devfeed.tech/tags/operator.md>), [recovery](<https://devfeed.tech/tags/recovery.md>), [sql-server](<https://devfeed.tech/tags/sql-server.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

This walkthrough tests unplanned SQL Server Availability Group failover on Kubernetes by force-deleting the current primary pod under idle and sustained HammerDB TPC-C load. Across six force-deletes, the operator automatically promoted new primaries and restored all three replicas, with the article examining detection, recovery behavior, logs, and timing.

## Source excerpt

In my planned failover walkthrough, I showed what happens when you deliberately move the primary role to another replica. That's the easy case. Now I want to show what happens when the primary pod just disappears unexpectedly, like during a node failure or a container crash. No graceful shutdown, no demotion, just gone. I ran two test scenarios, each cycling the primary role across all three pods by force-deleting the current primary three times in a row. First, a 5GB TPC-C database idle. Then, that same 5GB database under sustained HammerDB TPC-C load. Six force-deletes total, six successful automatic failovers. I'll walk through the error log from the promoted replica, the operator's detection and recovery behavior, and the full timing data.