数据库镜像出错了咋办，常见问题和解决思路分享

前几天我在一个技术社区里，看到有人发帖问：“数据库镜像突然断开了，主库和镜像库不同步了，业务系统报错，急死人了，这该怎么办？” 下面跟了几十条回复，有分析原因的，有给解决步骤的，还有分享自己踩坑经历的，我花了点时间把这些信息，连同我自己遇到过的一些情况，整理了一下，希望能给遇到类似问题的朋友一个清晰的解决思路，别慌,一步步来。

第一步：别急着动手，先搞清楚状况

当监控系统报警或者业务方反馈数据库连接有问题时，第一反应不应该是马上跑去重启服务或者执行修复命令，你得先像医生一样“望闻问切”,诊断清楚。

1. 确认错误现象：到底是应用程序完全连不上了，还是只是报连接超时？错误日志里具体说了什么？是明确提示“无法连接到镜像数据库”，还是说“在镜像数据库上尝试了只读操作”？这些信息非常关键，微软的MSDN文档里就提到，应用程序的连接字符串如果配置了Failover Partner，那么在主体服务器断开时，它会尝试连接镜像服务器,错误信息会体现这个过程。
2. 检查镜像状态：这是最直接的一步，连接到你的主数据库服务器，执行一个简单的查询命令来查看镜像的状态，在SQL Server里，你可以查询sys.database_mirroring这个系统视图，你会看到几种状态，比如SYNCHRONIZED（已同步）、SYNCHRONIZING（正在同步）、SUSPENDED（已挂起）或者DISCONNECTED（已断开），状态不同,处理方式天差地别。
3. 查看日志：无论是数据库的错误日志还是操作系统的系统日志，都藏着问题的蛛丝马迹，可能是网络瞬间闪断的记录，可能是磁盘空间不足的警告，也可能是权限问题的报错，有个朋友分享过他的经历，镜像老是莫名挂起，最后查操作系统日志才发现是防火墙策略被改动,阻塞了镜像端口的通信。

第二步：针对常见问题，逐个击破

根据第一步的诊断,你大概率会碰到下面这几种常见情况：

镜像状态变成 SUSPENDED（挂起）

这是最常见的问题，意思是同步过程中断了，但TCP连接可能还在,原因通常有：

• 网络问题：这是头号嫌疑犯，可能是网络交换机重启、网卡故障、或者网络带宽被其他应用占满，导致镜像双方“失联”超过超时时间（默认是10秒）。解决思路：首先检查网络连通性，用ping和telnet [镜像服务器IP] [镜像端口]命令测试两端是否能通，如果网络确实有问题，先联系网络工程师解决，网络恢复后，镜像有时会自动恢复，如果不能,可能需要手动恢复。
• 磁盘空间不足：如果主库的日志文件快速增长，而镜像服务器的磁盘没有足够空间来存放这些日志，镜像也会被挂起。解决思路：检查镜像服务器上存放数据库文件和日志文件的磁盘空间，如果满了，赶紧清理磁盘或者扩容，腾出空间后,再恢复镜像。
• 日志文件过大：如果主库执行了一个非常大的事务（比如批量删除历史数据），会产生巨大的日志量，可能超过网络传输或镜像服务器应用日志的能力，导致超时挂起。解决思路：尽量避免在镜像环境下运行超大型事务，如果已经发生，可以尝试先恢复镜像，如果不行,可能需要进行一次完整的主从重新初始化。

镜像状态变成 DISCONNECTED（断开）

这比挂起更严重,意味着TCP连接都断开了。

• 原因：通常是更持久的网络中断、防火墙阻止、或者镜像数据库服务本身宕机了。
• 解决思路：检查镜像服务器实例是否还在运行，确认防火墙规则没有阻止镜像端口（默认5022），确保连接双方的服务账号有必要的权限，这些问题解决后,需要重新建立镜像连接。

主从数据不同步，但状态显示正常

有时候状态显示是SYNCHRONIZED，但业务方反馈两边查询的数据不一致,这非常危险。

• 原因：极有可能是有人在镜像数据库上进行了误操作，因为正常情况下，镜像数据库是处于“正在还原”状态，不可写，但可能有人为了临时查数据，误用了RESTORE WITH RECOVERY命令恢复了镜像库，导致镜像关系破坏，之后又偷偷用RESTORE WITH NORECOVERY挂回去,但这中间已经丢失了一部分数据同步。
• 解决思路：这种情况几乎没有完美的在线修复方法。预防远大于治疗！必须严格管理权限，禁止任何人在镜像数据库上进行任何操作，一旦发生，最常见的做法是：删除原有的镜像关系，从主库做一个全新的完整备份+日志备份，在镜像库上恢复（使用NORECOVERY），然后重新建立镜像,这会中断服务较长时间。

故障转移失败

这是最棘手的场景，主库真的宕机了，但你执行手动故障转移时失败,或者转移后应用无法访问新的主库。

• 原因：
  • 连接字符串问题：应用层的连接字符串没有正确配置Failover Partner,导致它不知道故障后该连接谁。
  • 镜像端点损坏或权限问题：故障后,剩余的镜像服务器端点可能存在问题。
  • 数据库孤立用户：故障转移后，新主库上的数据库用户可能和服务器登录名失去了映射关系（成为“孤立用户”）,导致应用登录失败。
• 解决思路：定期测试故障转移流程！这是最重要的教训，在测试环境模拟主库宕机，确保整个切换流程顺畅，对于孤立用户问题，可以编写脚本，在故障转移后自动执行sp_change_users_login存储过程来修复。

最后总结一下核心思路：出错了先别乱，查状态、看日志，从最简单的网络、磁盘空间问题入手，平时就要做好监控，设置好镜像状态和磁盘空间的告警，最重要的是，一定要定期在非业务时间进行故障转移演练，真到出事的时候才能心里不慌，数据库镜像是个好东西，但它也需要细心维护,希望这些来自实践的经验能帮到你。