SQL Server 数据库镜像

---

故障转移群集技术 vs 日志传送技术

故障转移群集技术和日志传送技术都不完美，有各自的优缺点

优缺点	故障转移群集技术	日志传送技术
优点	系统在遇到故障时能自动恢复	提供冗余的数据
缺点	不能提供数据冗余，以对抗数据库损坏事故	主从库数据延迟可能会过大，故障切换麻烦

数据库镜像 vs 故障转移群集技术

相对故障转移群集来说数据库镜像同样能够为客户端应用提供统一的连接方式，且同时具备故障转移群集所没有的抵御数据损失的能力

数据库镜像 vs 日志传送技术

相对日志传送，数据库镜像进行灾难切换要快的多，基本对客户端应用透明。

数据库镜像的设计目的

提供一个能实时同步数据的灾难恢复技术，即既能提供数据冗余备份，又能自动进行故障切换。

2.4.1 数据库镜像的基本概念

基本术语和角色

数据库镜像会为目标数据库创建一个副本数据库。这两个数据库分别运行在不同的 SQL Server 实例上，作为“伙伴”建立一个会话（Session）。通过这个对话，两个数据库互相进行通信和协作，扮演互补的角色：“主体角色” 和 “镜像角色”，以实现“镜像”的效果。在任何给定的时刻，都是一个伙伴扮演主体角色，而另一个伙伴扮演镜像角色。

• 主体数据库（Principal Database）
  扮演主体角色的数据库
• 镜像数据库（Mirror Database）
  扮演镜像角色的数据库
• 主体服务器
  运行主体数据库的 SQL Server 实例
• 镜像服务器
  运行镜像数据库的 SQL Server

镜像数据库的作用

镜像数据库作为主体数据库的一个副本，在主体数据库发生故障、不可访问时能迅速恢复数据库访问，即提供了灾难恢复的功能。

镜像技术的限制

1. 主体数据库的恢复模式必须为完整恢复模式
2. 主库不能执行一些操作（比如还原数据库备份）
3. 镜像数据库由于一直处于“恢复”状态，因此不能被访问，可通过建立数据库快照来访问
4. 只有用户数据库才能配置数据库镜像，所有的系统数据库都不能被镜像，对于系统数据库需通过备份的方式来保障安全
5. 由于镜像数据库相互独立，这些数据库不能作为一个组来进行故障转移

数据库镜像会话

上图说明了作为伙伴参与两个镜像会话的两个服务器实例，一个会话用于名为 Db_1 的数据库做镜像，另一个会话用于名为 Db_2 的数据库。

每个数据库镜像的会话都只针对一个用户数据库，而且是独立的。例如，一个应用程序需要同时访问一个 SQL 服务器实例上的两个数据库，那管理员需要配置两个镜像会话。如果其中一个数据库发生故障，它的镜像会将数据库转移到镜像服务器上，而另一个工作正常的数据库则继续在主体服务器上运行。这时对 SQL Server 来讲，两个数据库都能被使用。但是对应用程序来讲，连接哪个服务器都不能正常工作。由于镜像数据库相互独立，这些数据库不能作为一个组来进行故障转移

见证服务器的作用

见证服务器只作为一个中立的仲裁，无数据副本，其和主体/镜像服务器建立会话，判定数据库的健康状况，并在主库发生异常时，触发自动的故障转移，让镜像数据库和主库转换角色。

配置了见证服务器的数据库镜像兼备了高可用性和灾难恢复的功能，如果数据库镜像没有配置见证服务器，就无法实现自动的故障转移。一旦主体数据库发生异常，DBA需手动进行故障转移

见证服务器的的特点

• 必须独立于主体服务器和镜像服务器的实例
• 多个数据库镜像伙伴（无论它们是否使用相同的主体服务器和镜像服务器）可以共用一个见证服务器

主体、镜像、见证服务器实例通信原理

主体、镜像、见证服务器实例上都会建有一个叫作“端点”（Endpoint）的对象，每个端点都侦听在一个 TCP 的端口上，默认是 5022 端口。主体、镜像、见证服务器三者就是通过建立在实例上的端点向另两个服务器发送 TCP 数据包来进行“会话”。一个 SQL Server 实例上，无论配置有多少个数据库镜像会话，它们都只使用唯一的端点。若这三个实例中的某两个运行在同一台机器上，要确保这两个实例上的端点侦听在不同的 TCp 端口上。

主体数据库和镜像数据库数据同步原理

SQL Server 数据库中任何的数据变化都会先记录到事务日志中，然后才会真正更新数据页面。而事务日志是先保存在该数据库的日志缓存里（Log Buffer）里，然后将缓存中的日志块固化到磁盘上的 LDF 文件中。在数据库镜像中，主服务器在将主体数据库的日志从日志缓存固化到磁盘的同时，还会使用另一个线程来将日志块发送到镜像服务器的端点。当镜像服务器通过端点接收到日志快之后，它现将日志块放到镜像数据库的日志缓存里，然后将缓存里的日志块固化到磁盘上。一旦日志块被固化之后，镜像服务器会根据日志来对镜像数据库执行“重做”（Redo），最终更新数据页面。当镜像服务器重做日志时，镜像数据库实际就是在执行日志的前滚操作。如果重做失败，则镜像服务器通过将数据库置于 SUSPENDED 状态来暂停会话。DBA 必须找到问题的原因并解决问题才能继续会话。当主体服务器阶段或收缩数据库的日志时，镜像服务器也将在日志的同一点收缩日志。

数据压缩的优点

从 SQL Server 2008 开始，日志块在被主体服务器发送到网络之前会做压缩处理，这会带来以下好处

1. 提升日志发送和接受的效率
2. 降低日志块传输对网络链路和网络设备所带来的负载
3. 对异常繁忙的生产系统，降低了由于网络不胜负荷导致的镜像对话异常中断，也降低由于网络延迟导致的数据库镜像性能问题

发送队列

• 产生发送队列的原因
  主库上新日志生成的速率可能会快于日志发送的速率，有些日志记录来不及发送，而在主库上暂时“累计”起来。

• 发送队列标记
  发送队列不会占用主库上额外的存储空间和内存，其存在于主库的事务日志文件（LDF）上。事务日志里会有一个标记，指向所有没被发送到镜像服务器的日志记录中最早的那个。即从这个标记开始到最新的日志为止，就是“发送队列”。主体服务器就不断地从这个队列中取出最早的日志，并发送给镜像数据库

重做队列

• 产生重做队列的原因
  在镜像数据库中，如果日志重做的速率赶不上日志在镜像端固化的速度，那么也在镜像数据库的 LDF 文件中等待重做的事务也会产生一个队列。

• 重做队列标记
  重做队列也不实用额外的存储空间和内存，它仅是使用一个标记，指向镜像数据库的事务日志文件中最早的那个还未重做的日志。镜像服务器从这个标记开始按顺序重做日志，更新数据。重做队列中等待的为重做日志数量决定了故障转移到镜像数据库所要花费的时间。

数据库镜像技术和日志传送一样，其同步的信息也是日志记录，而不是数据操作命令。不同的是，日志传送是通过数据库日志备份和恢复。而数据库镜像更直接，其直接读取和标记日志文件里的日志记录。因此镜像技术的实时性会更好。

2.4.2 数据库镜像操作模式

数据库镜像有 3 种操作模式：高可用、高保护和高性能。使用哪一种模式取决于两点：

• 数据库镜像的 “事务安全性” 设置
• 是否有见证服务器

数据库镜像 3 种操作模式及它们之间的区别

操作模式	事务安全	传输模式	见证服务器</