遇到Sql Server 2012 AlwaysOn的同步事务传输问题

时间:2021-05-23 01:19:26

新版的Sql Server 提供了AlwaysOn技术为高可用性系统提供了极大的便利,而且可以实现我们以前需要花很多工作实现的读写分离机制,我们当然受不了诱惑,去尝试这种新技术。开始就像所有的故事一样,平稳甜蜜,没啥问题,数据库在负载不大的情况下,完美的实现的负载均衡,我们的代码也几乎无改动,虽然有一些奇怪的小问题(这些奇怪的小问题其实是一个巨大问题显露出来的一丢丢),总体上可用,也简单。这些小问题是啥呢?我们的系统会有一些非常复杂的Sql查询视图,我们不得不用一些中间结果表来加速查询,中间结果表会有来源的关联表,这些关联表发生变动后,我们会有一个服务去更新这些中间结果表,类似于SSAS的Cube吧,不过比那个节省很多。这个更新中间表有时会有莫名其妙的失败,日志都是记录超时,我们在测试环境和模拟的生产环境数据量下都无法捕捉到,搞不定就算了,无非再重试一下就完了。另外我们还有一些公用的主数据,用数据库作业来同步到各个用户的业务数据库,在测试环境和模拟的环境中,这种同步都是以百毫秒级完成的,可是就会有这么几下会同步上十几分钟,这个也太奇怪了。我们怀疑数据库中有一些锁导致无法更新主数据表,可是无论我们怎么努力就是无法解决偶尔的同步上十几分钟,那就算了吧,反正主数据都是缓变数据,别那么频繁的去同步就好了呗。

在我们的数据库服务器承载了500+的用户数据库的时候,事情开始变的非常坏。某个周一早上,本来是开开心心的,蓝瘦,香菇,AlwaysOn的副本失效,全部数据库都无法访问,还无法分离副本,显示在同步中,不是说好的高可用吗?怎么回事啊?连切掉副本都不行?没办法,windows的最后办法,重启了服务器,然后一切都平静了,20分钟后恢复了服务,我们反复的查找原因,为什么副本会显示同步中?网络断了吗?然后检查交换机的日志,没有任何记录说网络断过,网络风暴?检查了日志依然没有发现。大概是偶发的事故,大概是谁在机房不小心踢断了网线又立刻接回去了吧,呵呵。然后悲剧了,第二天上午又发生了,第三天上午又发生了.....。无奈之下只好关闭了副本服务器,结果又是平稳安静,好像什么都没发生。数据库运维不干了,他说没有副本,服务器坏了,他无法保证数据完整,必须要打开副本。怎么办?到底发生了什么?

查阅了AlwaysOn的各种文档,还问了微软的工程师,最后说AlwaysOn只测过在同一个实例上承载100个数据库,超过太多怕是不行,我们去买数据库服务器吗?运维最后说把同步改为异步吧,什么?我惊呆了,我说你再说一遍,他说AlwaysOn现在是设置为事务同步传输的,性能损耗可能比较大,测试的时候没观察到过性能问题,只能先试试。我再次惊呆了,当然要改成异步方式了,否则不变成准分布式事务了嘛,这怎么能接受啊!居然漏掉了这个部分,我想当然的认为他是异步事务传输,否则也太耗费性能了,关键是在高写入环境下会有大量的阻塞。一切问题似乎都有解释了,比如为什么主数据会偶尔同步十几分钟,因为他在等待另很多事务完成,这个事务在等待副本更新完成,然后数据库会有大量的这样的等待。同步主数据算法本身也有问题,就是他总是会去更新而不管数据是否真的变化,这种偷懒的写法在遇到AlwaysOn同步事务传输的时候就麻烦了,想想看,主数据大概2000条,500个数据库更新,然后.....。还有缓存的中间结果表的更新为什么会偶尔超时,因为被主数据更新卡住了,主数据更新被其他事务同步卡住了。

找到问题后,改进了算法,所有的数据都要比对不同后才更新,相同的就不要更新了,AlwaysOn改为异步事务传输,修改了Sql Server的线程池线程数量上限(AlwaysOn使用线程池线程做同步),数据库太多需要更多的线程去给AlwaysOn使用。然后又平稳了。

总结:

1、AlwaysOn运行在大量小数据库的实例上需要特别小心。

2、有大量的突发的写入的时候,AlwaysOn可能是无法承受的,特别是结合1的前提下

3、不要使用AlwaysOn的同步事务传输模式,特别是结合了2和1的前提下。