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，包罗康健搜查、资源打点、漫衍式元数据关照维护以及妨碍转移，以是这时辰就必需我们本身去办理这个题目。

为此我们也做了许多全力，最终实现了支持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数据库的要领

（编辑：湖南网）

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