SQL Sever AlwaysOn在阿里云的突破(2)

因为它一旦认定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，包括健康检查、资源管理、分布式元数据通知维护以及故障转移，所以这时候就必须我们自己去解决这个问题。

为此我们也做了很多努力，最终实现了支持AlwaysOn无域控无群集的HA系统，不依赖Cluster完全自主可控的HA。

六、产品化

最终的产品架构如下，首先会保证有2个同步节点做主备，并且尽量分配在不同的可用区，其它只读节点默认是异步，最多可以有7个只读节点;用户的访问链路可以有三种：

读写链路：会指向两个同步节点，由我们的HA来保证高可用;

统一只读链路：根据用户需求设定，把指定的Replica节点绑定到一起按照一定的权重比例分配链接;

单一只读链路：即每个只读节点会提供一个单独的链接，让用户也可以自己灵活配置，比如用户的APP Server就是在可用区A，那么就可以直接访问可用区A的只读地址，避免再通过统一只读被路由到其它区域。

至此，SQLServer AlwaysOn已经在阿里云PaaS化，当然目前只是支持最主要功能，后续还有很多可以完善丰富的地方。如果大家有任何好的建议或者问题，也很欢迎留言与我交流。

【编辑推荐】

1. 区块链，一种数据库技术
2. 读完这篇文章，就基本搞定了Redis数据库
3. 敢啃“硬骨头”，开源分布式数据库TiDB如何炼成？
4. 10月全球数据库排名：Oracle 和 PgSQL 增长令人瞩目
5. 8种手动和自动备份MySQL数据库的方法

（编辑：ASP站长网）