SqlServer 灾备高可用对比

我对Sql Server的灾备，高可用方案做了一下对比。

那数据库版本是：

Microsoft SQL Server 2017 (RTM) - 2017 Microsoft Corporation Standard Edition (64-bit)

一 简单比较：

HA (High-Availability)

DR(disaster recovery)

发布订阅

Mirror

AlwaysOn

策略

DR

HA

DRHA

当前数据库版本是否可用该技术

可用

可用，只能支持full safety mode

可用，需要企业版Sql Server 。

对于Standard版本（BI数据库版本），只支持一个数据库做AlwaysOn

是否支持IAAS –> PAAS

支持

不支持，只能IAAS -> IAAS

不支持，只能IAAS -> IAAS

二深度比较：

为了更好的方便大家理解，我设计了一下场景：

BI 现有生产数据库是MASTER，MASTER宕机之后， Slave会如何工作呢？

MASTER 恢复正常之后，MASTER和Slave之间身份是如何调整的？

发布订阅

Mirror

AlwaysOn

MASTER脱机，切换Slave

程序需要修改DBconnectionString

程序需要修改DBconnectionString

程序不需要修改DBconnectionString。AlwaysOn前端有虚拟映射

MASTER修复之后，MASTER可以切换回原来

不可。不可逆

可以手动切换MASTER

可以手动切换MASTER，也可以不切换。因为前端代码可漂移数据库。

MASTER修复之后，MASTER和Slave之间是否有数据Gap

有。MASTER会漏数据。恢复复杂，且找回数据期间，数据库是hang住不可用状态。

几乎没有。MASTER和Slave之间几乎没有数据gap。

几乎没有。MASTER和Slave之间几乎没有数据gap

三总结

AlwaysOn：

优点：

1 MASTER脱机，再Setup。MASTER和Slave之间几乎没有数据gap。

2 设置虚拟映射，前端程序不需要修改任何代码，就可漂移数据库。

3 对于Standard版本（BI数据库版本），只支持一个数据库做AlwaysOn

从监控上看，BI 热点库恰好只有一个： EDC

缺点：

1 IAAS ->IAAS

2 Standard版本AlwaysON只可用基础可用性组，不可备份不可读

Mirror：

缺点：

1 鉴于我们数据库版本是Sql Server 2017 Standrad Edition，只能支持full safety mode。

何为full safety mode？

MASTER提交事务A之后，需要等Slave也提交事务A。MASTER才能处理事务B。

对于早上BI 跑批的情况，这是一种极大的性能消耗，执行会比现在要慢。

2 Mirror技术在未来版本可能被删除

3 IAAS -> IAAS

发布订阅：

优点：

1 IAAS -> PAAS

2 如果业务接受恢复T-1(恢复到前一天的数据)，并且接受建立发布订阅时间越来越长.也是可以的。

缺点：

1 因为MASTER一旦脱机，发布订阅“关系链“就丢失了。

2 MASTER重新SetUp之后，丢失的数据，必须通过事务日志还原找回。找回数据期间，数据库不可用。

3 MASTER再次建立发布订阅的话，耗时会越来越长，因为数据量越来越大。

相关文章