上篇文章提到了WSFC群集出现时间分区时，使用磁盘见证和共享见证处理的方式会不一样，老王实作了一下，看国内目前还没这方面的博客，心血来潮决定把这篇番外博客写出

  首先我们先来看出现时间分区时共享见证的处理，所谓时间分区即是说，当你修改一个节点的资源状态时，另外一个节点不在线，然后修改的节点又宕机，另外一个节点上线时同步面临的群集数据库同步问题

我们假设这样一个场景

时间节点1：节点1和节点2同时存活，节点1上面添加DTC群集角色，群集数据库自动同步至节点2

时间节点2：节点1宕机，节点2查找群集数据库上线群集1承载DTC角色

时间节点3：节点2添加SOFS角色

时间节点4：节点2宕机

时间节点5：节点1上线 

当实际出现了这种场景的时候，你会发现共享见证下节点1无论如何也没办法进行正常的工作

打开事件管理器 - 系统，你会看到 Event ID 1561的错误，内容提示已经很清楚，由于该节点不具备群集数据库最新版本，因此无法启动，无法形成群集

这正是老王上篇文章提到的，当你使用共享见证作的情况下，出现时间分区时，共享见证是没办法处理的，因为共享见证里面没有存群集数据库

然后这时你在节点1打开群集管理器，你会发现无论如何也连接不上CNO，你试图ping群集CNO VCO域名可以ping通，但是当你访问他们，使用VCO名称，会发现连接不上

  这时候只有等节点2修复完成，当节点2加入群集后，节点1可以和节点2同步最新的群集数据库之后，节点1群集管理器才可以正常打开，可以重新加入群集工作。

  即使这时你的节点1可以打开，也千万不要执行强制仲裁，因为一旦执行了强制仲裁会覆盖paxos标签，提升节点1的paxos标签为最新，共享见证又只承认拥有最新paxos的一方，导致的结果就是让群集以为节点1的群集数据库才是最新的，然后这时候如果节点2修复打开了，之前修改的内容也将完全丢失，因为节点2要以节点1的群集数据库为准了，因此共享见证情况下出现时间分区了，只有等权威节点修复完成上线，或通过恢复群集权威数据库方式

我们再来看下同样的时间分区场景在磁盘见证下的效果

时间节点1：节点1和节点2同时存活，节点1上面添加DTC群集角色，群集数据库自动同步至节点2

时间节点2：节点1宕机，节点2查找群集数据库上线群集1承载DTC角色

时间节点3：节点2添加SOFS角色

时间节点4：节点2宕机

时间节点5：节点1上线 

节点1不在线情况下节点2新增SOFS角色

节点2宕机，节点1上线

节点1可以同步使用SOFS角色信息，并正常提供群集应用服务

   同样的情况下，节点2在节点1不在的情况下，新增了SOFS角色，之后节点2宕机，节点1上线，可以看到，节点1依然是可以正常启动的，群集管理器也可以正常打开，群集应用也可以正常对外提供服务

  为什么会是这样呢，因为群集磁盘会存着最新的群集数据库，当我们使用磁盘见证的时候，当新增或删除了群集资源，除了会把状态同步到节点本身的群集数据库注册表，也会同步一份到见证磁盘中，当出现时间分区时，会发生的只是节点1联系到见证磁盘，与见证磁盘同步到最新的群集数据库，然后正常启动服务。

  因此，大家可以看出，共享见证在一些场景下还是会有问题，老王建议能使用磁盘见证尽量一定要用磁盘见证

  2016新推出的Cloud blob见证我还没有试过时间分区的场景，不知道是类似共享见证的效果，还是磁盘见证的效果，关键在于里面会不会有最新的群集数据库，后续有时间我会去验证一下，也欢迎大家去验证下然后告诉我答案