I am reading this summary from the book 'Pro SQL Server 2019 Administration' from Carter:
And it specifies:
hot → automatic failover → used for high availability (HA)
warm → manual failover → used for disaster recovery (DR)
Since 'high availability' is usually planned and 'disaster recovery' is not, shouldn't we aim for manual failover in 'high availability' scenarios?
What's the point of having automatic failover for high availability?
It makes sense to me that if DR occurs, failover should be automatic, and if we have something planned (patching, etc.) and we have HA, we can do the failover manually…
Best Answer
It is tricky with generalizations and simplifications. However, here's an attempt:
My feeling is that HA generally is closer geographically. In such cases it is more realistic to use synchronous methods, like sync Availability Groups. In such cases, it is reasonable to failover automatically.
But when we talk DR, it is reasonable to imagine longer distances, since having some distance is part of the resilience architecture itself. And with longer distance, it is likely that you have async methods to get changes across. Like async AGs. Log shipping is by its very nature async. I.e., failover with an async solution and you lose data! Not something you want to happen "behind the scenes".