SQL Sever AlwaysOn在阿里云的突破

因为它一旦认定Secondary异常，就不会等这次ACK，而是退化为类似异步的模式，但会把Secondary端的异常状态记录在基表里，通过相关视图 ：sys.dm_hadr_database_replica _states、sys.database_mirroring暴露出来，就是我们常见的NOT SYNCHRONIZING / Disconnect状态。

这时候自动化运维系统或者DBA就需要做判断处理，等到Secondary修复重新联机后，会向Primary报告End of Log (EOL) LSN，Primary端再向它发送EOL LSN之后hardened的所有日志。

一旦Secondary端开始接收到这些日志，并逐步刷到日志文件中，那么整个AG或者Mirroring相关的视图又会标记其状态为Synchronizing，表明正在追赶，直到Last Hardened (LH) LSN达到主备一致状态，这时重新回到同步模式。

以前的情况一直是这样。直到SQLServer 2017 CU 1引入了REQUIRED_SYNCHRONIZ ED_SECONDARIES_TO_COMMIT这个参数，参数名字很长，但也基本包含了它的作用，应对刚才的场景是可以让Primary端一直等到Secondary节点重新联机并同步后再提供服务。

了解了AG同步、异步以及FCI，再总结下我们关心的点：

在实际方案中，这些也可以结合起来，最终再和阿里云产品整合做一个整体方案。之前也讲到，阿里云从15年就开始做类似方案来解决用户问题，一直到最终PaaS化，也过度了三个版本。

五、云上演进

第一版本我们使用了ECS、SSD云盘、OSS、VPC、SLB作为基础;在SQL技术上，我们使用SQL+WSFC+AD的方式，目前看这种方式支持的版本也非常多，从12到17都可以;验证方式既可以用域控也可以用证书。

但有2个缺点：

• 成本高。除了Primary和两个Secondary节点，还要有两个AD节点，毕竟我们每个环节都要保证高可用;
• 稳定性不够。网络抖动的情况非常容易让WSFC判断异常，SQL端DB同时出现不可用。

这是第二版的架构，跟第一版相比，我们用到了HAVIP来解决监听器问题，去掉了AD只能用证书做验证，但也因此最小资源开销降低到3。

这个方案也是之前在阿里云上用的比较多的，但同第一个方案一样，在网络稳定性上会有很多挑战，因为我们未来面对的场景不只是同城跨可用区，还会有更多跨Region以及打通海外的场景，所以这个方案也只能Cover一部分用户的需求，但对我们不是一个最终方案。

最终我们找到了方案三，去除了WSFC和AD，只关注基础云产品和SQL本身。

最重要的是跟方案二相比，对网络的抖动敏感度会更低也更可控，最多是在Primary端出现Send Queue的堆积，这个我们完全可以通过SQLServer相关的Performance Counter监控并做一些修复调整。

但没有方案是完美的，可控性强的代价是，这种无群集无域控架构原生是不具备HADR能力的，这点熟悉WSFC的同学可以知道。之前架构的HA都是依赖WSFC，包括健康检查、资源管理、分布式元数据通知维护以及故障转移，所以这时候就必须我们自己去解决这个问题。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!