数据库高可用实战：化繁为简搭建一套轻量级架构

吴虞 2016-09-22 10:45:22

作者介绍

吴虞，SQL专家云团队成员，擅长解决SQL SERVER数据库性能、高可用、负载均衡等问题。

说到高可用，看官们会想到很多方案，也许是自亲身经历过系统从单机变成高可用的痛苦过程，也许有的看官只是在自己的虚机上搭建过测试的玩具。本文以我自己的真实经历给大家讲述，不管怎样，实战和测试玩耍还是很大区别的，可能你觉得搭建一套高可用方案很简单，配置下就OK了，但在真正的复杂系统中一切就没那么轻松了！

本文主要讲述升级并搭建AlwaysOn高可用的过程，以实施的思路为主。文中并没有搭建集群的步骤，搭建步骤请自行学习。（个人认为会搭建可用组并不是关键，而一系列的调研细节才是项目成功的关键）

一、背景

客户的现有方案是一套使用发布订阅构建的读写分离方案，总体来说系统构建的很不错。也是在SQL2012之前很常见的一套架构。

架构图如下：

客户的需求：SQL Server 2008 R2升级到SQL Server 2014使用AlwaysOn替换现有发布订阅架构。实现本地高可用、读写分离，异地灾备等，并应用部分2014的新功能，如内存优化表等提升系统性能和并发能力等。

二、前期调研

1数据收集

前期对系统的了解很重要！那么怎样对系统有一个初步直观并且详细的了解呢？用脚本收集？这时就体现出工具的专业和协作价值。工欲善其事，必先利其器！

三、确定方案

通过前期的需求分析，并对客户系统结构有了一个初步的了解后，我们用了将近一周的时间从架构的复杂度，易用性，客户程序改动程度，性能，稳定性等多个角度敲定了最终的方案。

架构图如下：

从原来复杂的架构变成如此清爽的架构，使用AlwaysOn取代复杂的发布订阅，使用AlwaysOn的只读节点实现读写分离，另外使用异地灾备节点取代原有的异地发布数据库，很不错吧~这也是用户最倾向的架构，因为复杂度低，相对稳定易于维护。这里要注意，凡事有利必有弊！要说“但是”了。

但是，升级改动的成本大大提升！为什么这么说？我们接着看！

四、详细调研

这样一个复杂系统前期的详细调研是需要很长时间的，几套系统不仅仅是架构上设计得比较复杂，功能应用、接口等更是复杂。下面是主要的一些梳理过程：

1原有系统结构

我们首先要对原有系统的设计有透彻的了解，客户在两地分别有一个数据中心，三套系统有大量的业务要使用其他系统的数据，所以这里使用发布订阅准时地把其他系统中的数据发布到系统中的一个数据库，并使用同义词指向订阅来的数据。这种结构降低了使用链接服务器跨实例甚至跨机房访问的性能消耗。并且多份数据订阅到多个只读的节点，从而实现了报表、接口等业务的读写分离。

2系统对象整理

因为要做升级迁移，所以对象的整理是很重要的工作，业务对象的遗漏可能会带来不可挽回的灾难，甚至有可能会导致整个升级、架构部署的回滚。几套系统中涉及的对象列表过于庞大，比如帐号几十个，几十个作业，上百个同义词，实例级触发器等等……

服务器划分：

主库对象

读写分离各个只读库对象

发布到其他业务系统的数据服务器配置对象

其他应用程序对象

对象划分：

数据库帐号

链接服务器

实例级触发器

作业

系统参数

维护计划

cdc

BI相关

同义词

程序集

邮件

操作员

只读库多出来的索引、视图等对象

等等等

五、测试过程

1搭建测试环境

所有的升级、高可用项目测试环节都是必不可少的。首先是测方案配合业务的可行性，因为作为第三方公司不能对用户所有的应用关系，系统架构了如指掌，甚至客户方自己的工程师可能也做不到这一点。其次是测试功能在新环境下是否出现异常。还有就是对收集并迁移的系统对象进行一次查缺补漏。这样也可以尽量保证系统上线时发生故障的概率。

测试环境无疑是任何升级、架构变更的必要步骤，也只有经过充分的测试才能做到心中有数，进而实现零故障上线。

2上线演练

上线演练？这是个什么东西？

首先数据库的操作一定要确定可实施的时间窗口，保证在固定的时间窗口完成工作很重要。这就是上线演练的最大好处，我们使用准备出的新机器完全模拟上线的全部步骤，并记录每个步骤使用的时间，可能出现的风险，最迟的完成时间等等。其次搭建完成后我们可以用这个环境（就是完成后正式环境的配置）进行压力测试。

上线演练是一个很必要的步骤，但这个步骤要视实际的情况而定，比如升级的方式，环境的配置等。在这样的一个项目中我们做了两轮的上线演练。

六、实施过程

1制定性能基线

这样一个大的变动，数据库在各个阶段的性能指标是什么样子的呢？这里我们依然使用Expert for SQL Server工具对每一个阶段实施前后性能进行对比，这样不仅能对实施的影响进行监控，更能清晰地分析出每个实施阶段对性能的影响。

对每个指标也都做相应的对比分析，指标比较多这里不一一介绍了。

2性能优化

这里的性能优化，我们主要针对语句系统的一些常规参数、慢语句进行第一轮的优化，另外一个重点就是为了应对升级到2014后可能变慢的语句进行调整。具体什么样的语句可能变慢？这个...

系统的重点语句（执行最频繁的）

语句复杂的

大面积测试吧.....哈哈哈

这里为什么要在升级前就做这样的优化工作，而不是升级后系统运行时在针对慢的语句进行分析呢？这个道理很简单，如果上线了才发现变慢的功能很多，或变慢的是频繁的功能，那么上线的效果就是"失败"两个字。虽然有的看官知道可以使用提示或降低兼容级别解决这个问题，但是这只是特殊场景下的极端手段，并不是解决的根本。所以建议如果你有升级到2014的需要，那么这样的优化手段一定要提前做好。

七、升级到2014

升级数据库完全可以写成好几篇博客，甚至写本小书都可以。这里只做简单介绍，和一些要重点注意的问题。

1升级方式

升级方式有2种：in place 和side by side，这里采用的是side by side。通俗地说就是准备新的服务器，安装对应版本的数据库，然后把数据还原上去。side by side的好处就是升级不会影响原有的环境，即使失败也能修改程序指向回退到原环境。

升级2014最大的一个问题

2014的新特性 “参数估计” ！这个让人兴奋又苦恼的新功能会导致很多语句在升级到2014后变慢，因为前面的优化阶段已经对这部分重点关注了，所以这部分的问题基本已经消灭。但是，万恶的分区表（200多个分区）依然导致了批处理的性能严重问题。

2集群搭建

集群搭建可能没有过多的可说支出，正常创建故障转移集群，搭建AlwaysOn等，但这其中的细节还是很多的，比如仲裁的方式？异地节点的虚拟IP设置？节点个数与业务的配合？……等等的问题，这里也就不一一细说了。

3程序修改

这个架构的修改也必然导致程序上的变化，这也是前文中提到的为什么客户最倾向的架构，因为复杂度低而使成本大大提升。原始系统中的关联性无法通过发布订阅实现本地化访问，又不能使用性能非常差的链接服务器。那么路只有一条，那就是修改程序访问方式，简单理解为在程序中分别在各自的数据库中查出相应的数据，然后通过程序在内存中操作处理。

八、细节问题处理

总体的实施步骤可以说就是这样了，但是在这个整体步骤中充斥着无数的细节，每一个细节可能都决定着方案的可行性，升级、架构变更的成败。限于篇幅这里只举几个可能常见的问题说明一下。

CDC功能与AlwaysOn：官方文档上说CDC与AlwaysOn可以实现转移后CDC不间断，但是经过测试CDC作业在AlwaysOn切换后多次执行失败则不会再一次自动运行，CDC的logreader和发布订阅时一样的，但在没有发布订阅存在的情况下只有CDC作业会出现上述问题。解决办法：配置调控作业（节点切换作业控制）
重建索引操作：由于配置异地节点。日志重建变成问题，测试中重建索引的日志量是单机下日志量的好几倍！这样会导致异地日志队列过长。解决办法：使用手工脚本拆分细化索引重建，根据队列大小和传输速率控制每天的日志量。
2014下语句变慢：具体就不细说了，2014参数估计和200+分区表组合产生的语句变慢问题至今没有答案。目前只是使用一些方法避免了这个问题！（这个问题也请遇到的朋友给些思路，谢谢）
只读副本上有写操作：由于一些报表操作使用中间临时表，这里临时表不是#temp 这种而是真正的物理表作为临时表。解决办法：修改为临时表，或创建单独数据库（不在可用性组中），在使用同义词指向新库实现写操作。