数据库镜像到底是怎么运行的，SQL Server里那些细节和流程讲讲

数据库镜像,你可以把它想象成给数据库请了一个实时的“影子”或“替身演员”，这个替身演员时刻准备着，一旦主角（主数据库）出事，它能立刻顶上去，保证演出（业务运行）不中断，在SQL Server里，这个过程涉及三个关键角色，它们之间通过一系列严谨的步骤来协同工作。

三个核心角色

得有三个“人”参与这场戏：

1. 主体服务器：这是主角，也叫主服务器，它承载着当前正在被大家使用的、可读可写的那个数据库（主体数据库），所有用户的操作，比如增删改查，都直接对着它来。
2. 镜像服务器：这就是那个“替身演员”，也叫备服务器，它上面有一个和主角一模一样的数据库（镜像数据库），但这个数据库平时处于一种“只恢复不开放”的静止状态，你不能直接去读它写它，它的唯一任务就是不停地从主角那里接收数据变化，让自己保持和主角同步。
3. 见证服务器：这个角色是可选的，但它非常关键，尤其是在我们后面要讲的“自动故障转移”模式下，你可以把它理解成一个“裁判”，它不存储数据库本身，它的任务就是盯着主体服务器和镜像服务器，看谁还“活着”，当意外发生时，它负责判断是否真的需要启动替身演员上场。

运行的核心流程：日志传送

主角的数据是怎么实时同步到替身身上的呢？靠的不是复制整个数据库文件，而是传送“操作日志”，这就像是主角在写一本详细的“操作日记”。

1. 日志生成：当用户在主体数据库上做了任何修改（比如更新了一条客户信息），SQL Server会先把这些改动记录在一种叫做“事务日志”的文件里，这是数据库确保数据安全的核心机制。
2. 日志捕获与发送：主体服务器上有一个专门的进程（日志发送器），它会不断地扫描事务日志，把新产生的日志记录打包成一个个“日志块”。
3. 日志传输：打包好的日志块通过网络，被发送到镜像服务器，为了保证数据不丢失，SQL Server通常要求使用“高性能”模式或“高安全”模式，这两种模式对日志发送的确认机制有不同要求。
4. 日志重做：镜像服务器收到日志块后，另一个专门的进程（重做器）会把这些日志记录按照顺序，在镜像数据库上重新执行一遍，这就好比替身演员看着主角的表演笔记，把主角刚才的动作一模一样地做一遍，正因为只是重放日志，所以镜像数据库才能保持和主体数据库的实时同步。

需要注意的是,为了确保重放过程不会乱套，镜像数据库必须始终处于“还原状态”，这意味着用户不能直接连接它进行读取或写入，它专心致志地做同步这件事。

两种主要的运行模式

根据你对数据安全性和切换速度的要求,SQL Server提供了两种主要的镜像模式，区别主要在于第3步“日志传输”的确认方式：

1. 高安全性模式：在这个模式下，主角非常谨慎，它每发送一个日志块给替身，都必须收到替身的确切回复“老弟，我收到了并且已经成功写入磁盘了”，主角才会认为这个事务提交成功了，然后才会告诉用户“操作完成”，这样做的好处是绝对保证数据不会丢失，即使主角立刻崩溃，数据也肯定在替身那里存好了，但缺点是网络延迟会影响主角的响应速度，因为每次都要等待确认。

   

2. 高性能模式：在这个模式下，主角比较“奔放”，它把日志块发送给替身后，不等替身回复“收到”，就直接告诉用户“操作完成”了，这样可以获得非常高的性能，因为不受网络延迟的影响，但风险在于，如果主角在替身还没来得及把数据写入磁盘前就崩溃了，那么最近的一小部分数据可能会丢失，这种模式通常用于对性能要求极高、且能容忍少量数据丢失的场景。

自动故障转移

当引入了“见证服务器”（裁判）并采用高安全性模式时，就构成了一个能自动故障转移的配置。

• 平时,裁判和主角、替身保持心跳连接。
• 假设主角所在的服务器突然断电了（比如机房故障），替身会发现和主角失联了，同时裁判也会发现和主角失联了。
• 这时,替身会去问裁判：“裁判，你还能联系上主角吗？”裁判说：“我也联系不上了。”
• 替身和裁判都确认主角“死亡”后，替身就会立刻挺身而出，将自己的数据库恢复成正常可读写的状态，接管所有的业务，这个过程通常是秒级的，对应用程序的影响很小，应用程序只需要配置好连接字符串，就能自动连接到新的主角上。

总结一下

SQL Server数据库镜像的运行，本质就是通过实时传输事务日志，在一个备用的服务器上维持一个数据同步的、热备的数据库副本，通过选择不同的同步模式（高安全性或高性能）和是否引入见证服务器，你可以在数据安全零丢失、高可用性自动切换、以及高性能低延迟之间做出权衡，它是一种非常重要且经典的数据库高可用性和灾难恢复技术。 综合参考了微软官方SQL Server文档中关于数据库镜像的架构说明、以及像SQL Server Central、TechNet Wiki等技术社区中对镜像原理的解读。）