演练不同模式下镜像数据库SQLServer的异常处理

镜像数据库是SQL Server高可用性方案的一种。配置比较简单，但是有多种模式。如果镜像数据库出现异常，在不同模式下的表现形式也是各异的。这里，我们演练在不同模式下，服务器出现异常后，可能的效果，这样能帮助我们选择合适的模式，以及了解在对数据库镜

镜像是SQL Server高可用性方案的一种。配置比较简单，但是有多种模式。如果镜像出现异常，在不同模式下的表现形式也是各异的。这里，我们演练在不同模式下，出现异常后，可能的效果，这样能帮助我们选择合适的模式，以及了解在对数据库镜像做维护期间，需要注意的地方。

【数据库镜像的模式】

数据库镜像主要有这么几种模式:

· High Performance模式 （也就是异步模式）

数据库在Principle的事务，不需要得到Mirror的确认，可以直接完成。Principle数据库性能会比较好。但是Mirror跟Principle之间事务传递可能延迟。

· High Safety 模式 （也就是同步模式）没有 witness服务器

数据库在Principle的事务，需要马上得到mirror的确认，才能完成。这种情况下，Mirror和Principle的数据是同步的。但是因为所有的事务需要mirror的确认，所以性能可能会有所影响。

· High Satefy模式 （也就是同步模式）有 witness服务器

如果带有witness，那么一旦Principle数据库有异常，无法连通，则在witness服务器的见证下，会做自动切换。镜像数据库会变成主数据库，以继续提供服务。

【High Performance模式下，出现异常】

· MIRROR数据库有问题，这时候PRINCIPLE数据库会处于 (Principle, Disconnected) 状态。在这种情况下，Principle数据库依旧能正常服务。当Mirror数据库恢复正常后，数据会自动进行同步，同步后，PRINCIPLE服务器会恢复到 (Principle, Synchronized) 正常状态。这种情况虽然不会对服务造成问题，但是我们应该尽快恢复Mirror数据库，否则，在Principle端，日志会累积，变得越来越大。会占满磁盘空间。

· Principle数据库有问题，无法连接，这时候应用当然不能使用。Mirror数据库处于 (Mirror, Disconnected/In Recovery) 状态。这时候我们有两种选择，1. 尽快恢复Principle数据库运营。2. 使用Forcing Service方法把Mirror数据库改为主数据库以继续服务。对于Forcing Service方法，我们要注意:

1. 完全停掉旧的PRINCIPLE 数据库，以避免出现两边同时做数据更新。

2. 在mirror服务器上，我们用下面命令把mirror数据库改为主数据库:

ALTER DATABASE SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS

3. 使用Forcing Service会导致数据有丢失的可能。如果在原先的主数据库数据还没来得及传送到镜像数据库, 那么该部分数据会被丢失。所以使用Forcing Service我们需要权衡。

4. 原先的主数据库起来后，Mirror会处于暂停状态，我们可以恢复镜像，把原来的主数据库为新的镜像数据库 (当然，会导致部分数据永久丢失) 。或者把原先的主数据库去除镜像设置，改为普通数据库，查看在原主数据库上写入而在原镜像数据库上没有写入的记录，然后手工倒入到新的主数据库上。用这种办法倒数据，我们需要对应用非常熟悉。

【High Satefy模式没有witness，出现异常】

· MIRROR数据库有问题，无法连接，PRINCIPLE数据库会处于 (Principle, Disconnected) 状态。在这种情况下，PRINCIPLE数据库依旧能正常服务。当MIRROR服务器恢复正常后，数据会自动进行同步，同步后，PRINCIPLE数据库会处于 (Principle, Synchronized) 正常状态。这种情况虽然不会对服务造成问题，但是我们应该尽快恢复MIRROR数据库，否则，在PRINCIPLE数据库上，日志会累积，变得越来越大。最后可能导致磁盘满。

· PRINCIPLE服务器有问题，这时候应用当然不能使用。MIRROR数据库处于 (Mirror, Disconnected/In Recovery) 状态。这时候我们有两种选择，1. 尽快恢复PRINCIPLE数据库。2. 使用Forcing Service方法把Mirror数据库改为Principle以继续服务。