数据库高可用实战 .docx

数据库高可用实战 说到高可用，看官们会想到很多方案，也许是自亲身经历过系统从单机变成高可用的痛苦过程，也许有的看官只是在自己的虚机上搭建过测试的玩具。本文以我自己的真实经历给大家讲述，不管怎样，实战和测试玩耍还是很大区别的，可能你觉得搭建一套高可用方案很简单，配置下就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性能优化 这里的性能优化，我们主要针对语句系