次の方法で共有

SQL Server Mirroring 各种模式下发生异常的情景演练

  • [アーティクル]

 

镜像数据库是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 <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以继续服务。

 

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

 

 

 

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

· PRINCIPLE数据库服务器有问题，服务停止，这时候，witness和mirror服务器会组成新的仲裁, 由mirror数据库转换成Principle. 处于(Principle, Disconnected) 状态，继续服务。当原先的PRINCIPLE数据库服务器恢复正常时，镜像会自动形成，原先的Principle数据库会变成新的镜像服务器。如果PRINCIPLE数据库服务本身并没有中止，而是处于无法连接状态，这种情况，我们下面会进一步解释。

· WITNESS服务器有问题，这时候，没有影响，PRINCIPLE数据库还是处于(Principle, Synchronized)状态。当然，这时候系统处于有风险状态，万一Principle数据库再有危险，无法连接，整个镜像无法自动提供服务。

· WITNESS服务器和MIRROR数据库有问题。跟Principle数据库处于断网状态。

o 如果MIRROR和WITNESS之间，能够互联，这时候MIRROR和WITNESS会组成新的仲裁，以继续提供服务。为避免两个数据库同时提供服务，原先的Principle的数据库一旦无法同时连接到WITNESS服务器和MIRROR服务器，它会把自己设为暂停状态。无法打开该数据库，这样以避免两份数据库同时提供服务的情况，导致两边数据不一致。

o 如果WITNESS和MIRROR服务器之间也不能互联，这时候，整个镜像会停止工作。

· WITNESS服务器和PRINCIPLE服务器有问题。跟Mirror数据库处于断网状态。

o 如果PRINCIPLE和WITNESS之间，能够互联，则PRINCIPLE处于(Principle, Disconnected)状态，但数据库继续提供服务。

o 如果Principle和Witness之间，不能互联，则整个镜像会停止工作。

· PRINCIPLE服务器和Mirror服务器有问题。跟witness服务器处于断网状态。

o 如果PRINCIPLE和MIRROR之间，能够互联，则PRINCIPLE处于(Principle, Disconnected)状态，但数据库继续提供服务。

o 如果Principle和MIRROR之间，不能互联，则整个镜像会停止工作。

 

 

【小结】

 

在有witness服务器的情况下，数据库要能提供服务，必须要求三方中的至少两方能够互联。

 

我们要么不用Witness服务器，一旦用witness服务器，则这台witness服务器很重要。因为如果witness和mirror数据库同时连不上，则会导致Principle数据库停止工作。

 

Witness服务器应该跟Principle和mirror放在不同的网段中。如果一定要放在一起，那么宁可跟Principle放在一起，也不要跟mirror服务器放在一起。

 

在做维护的时候，如果有witness服务器，建议先把WITNESS去掉。不然有可能会导致我们所不期望的切换。

 

在做维护的时候且没有witness，则镜像数据库可以在High Satefy模式，也可以在High Performance模式。从风险角度来看，这两个模式差别不大。当然，如果可能，最好切换到High Performance模式做维护。

Comments

  • Anonymous
    November 25, 2013
    是否意味着在高安全模式下一定要有见证服务器？？？如果没有见证服务器是否不能切换到高安全模式？？？