SQL Server高可用性解决方案概述公开课【第四十四、五期】

定位你的能力缺口：别把高可用只当成装个集群

这门课只讲一件事：SQL Server 在生产环境里怎么尽量不宕机、宕了怎么接得快。它解决的核心问题不是教你怎么写 T-SQL，而是补上很多开发转 DBA、或者运维接手数据库时最缺的一块——怎么选对高可用架构。很多人一提高可用就只会喊 AlwaysOn，但真碰到主库挂了、副本不同步、或者见证服务器抽风，根本不知道故障转移到底会不会成功、会丢多少数据。如果你现在只会单机装实例、只会做完整备份，连镜像和复制都分不清用途，这门课就是给你扫盲用的。建议基础至少要有独立建库、写多表联查的能力，没摸过 SQL Server 管理台的先补基础再来看。

建议先看哪几块以及资料怎么配合练习

资料包里是上下两讲的理论串讲，没有跟着敲代码的实操录屏。所以别指望光看视频就能学会配置，必须自己搭测试环境配合练。建议先看上半部分，把几种主流方案（数据库镜像、故障转移群集、事务复制、AlwaysOn 可用性组）的适用场景和原理界限理清，这部分重点听它们在数据同步方式上的本质区别。然后暂停视频，自己开两台虚拟机装好 SQL Server 实例，照着上半段讲的逻辑去手动配一次数据库镜像，体会下主体服务器、镜像服务器和见证服务器之间的通信过程。看完下半部分讲 AlwaysOn 的部分后，再去测试环境里建个可用性组，手动模拟主库宕机，观察应用程序的连接是怎么自动切到辅助副本的。光看不练，过几天绝对全忘。

看完应能独立回答的几个问题

• 业务要求零数据丢失且故障切换要在十秒内完成，该选哪种高可用方案？如果业务能容忍少量丢数据但要求读性能分流，又该怎么选？
• 故障转移群集和 AlwaysOn 可用性组到底有啥区别？它们各自保护的是实例级别还是数据库级别？
• 同步提交模式和异步提交模式在性能和网络延迟上的代价分别是什么？怎么根据实际网络带宽做取舍？
• 配置好高可用后，如果辅助副本出现严重延迟，该怎么排查是网络瓶颈还是磁盘 IO 问题？

学完这门课，你不一定能立刻去给银行做架构设计，但至少能独立给一个中型业务系统挑出合适的高可用方案，并在测试环境里完整跑通一次故障转移演练，而不是遇到服务器报警只会重启。