北京哪家医院治白癜风 https://wapyyk.39.net/hospital/89ac7_labs.html
摘要：本文主要分享如何构建反脆弱性的云数据库服务体系与实践，实现分布式云数据库服务的高可用方案，同时采取措施保护分布式云数据库整体服务，实现跨机房分布式自动切换方案，并在实践过程中，实施分享SQL自动发布，实现0误操作，有效保障云数据库服务的同时，提高了DBA及研发人员的效率，并完成有效数据库评价，实现完整的反脆弱数据库服务保障体系。作者：成思敏成思敏，21CN数据库架构师/技术专家/DBA主管，长期从事数据库工作，任公司DBA主管，数据库架构师，技术专家等。擅长数据库整体架构的构建，数据库自动化运维设计，早期介入数据库服务研究，长期从事在云计算下的数据库运行情况难题解决，并长期公司内部DBA团队建设培养，对内数据库规范培训。本文根据成思敏老师在DTCC数据库大会分享内容整理而成，主要分享构建反脆弱性的云数据库服务体系与实践，实现分布式云数据库服务的高可用方案，同时采取措施保护分布式云数据库整体服务，实现跨机房分布式自动切换方案，并在实践过程中，实施分享SQL自动发布，实现0误操作，有效保障云数据库服务的同时，提高了DBA及研发人员的效率，并完成有效数据库评价，实现完整的反脆弱数据库服务保障体系。一、云数据库服务情况简介各位朋友大家下午好，我是来自21CN的成思敏，也是一名专业岗，这几年在云数据库上面我成长得比较快，我们公司的业务发展也是很快。我所带来的分享主题是云数据库反脆弱运维体系，跟大家分享一下六年来在云数据库方面遭遇的挫折和总结的经验。那云数据库的脆弱性是什么？我们如何去反脆弱？如何建设强大的数据库服务体系？这就是我们今天需要讨论的话题。脆弱性在《六西格玛》这本书上指的是质量问题，质量问题其实牵涉到有十几种，比如说故障、性能、数据的恢复、数据的备份以及同步、性能调优等。即使是数据库没有故障也很稳定的时候，但是cpu基本是在10%以下，那么也是长期低负载的情况下，它也属于质量问题，因为它浪费了公司资源；这些都属于脆弱性的范畴。当大家解决一些问题的时候，一般是很有成就感的。不知道大家是如何去判断一个问题的，希望大家在解决问题的时候深挖最根本的原因，因为解决的问题往往是表面问题，比如说杀一个会话，调一调SQL，去优化。我们往往只是触摸到问题的冰山一角。1、云计算与云数据库服务情况现在已经是云时代了，在年的时候我是被亚马逊的云计算震惊了，从那个时候我就一直在想如何去建设。对于DB来说，他们说一个DBA可以去维护台数据库实例的时候，我们该怎么去做这个事情，怎么去实现？云计算的基础是整个资源池，能够提供智能的决策，以前是帮决策者去做决策，但是云计算能够提供智能的决策，所以它现在越来越成为企业先进性的标志。因为云数据库是云计算的核心应用，所以每一个DBA、每一个数据库工作者包括研发不得不去重视云数据库。到年为止，我国的企业上云率是30.8%，美国企业上云率是80%。但并不是所有的企业都能够上云，包括美国。比如说化工类的配方、财务的核心数据甚至一些国家的军事机密，这些是不应该上云的，即使是私有云。走向网络化的时代，企业一定有自己的命根子，他要保住这些东西。我国企业上云率为什么和美国相差这么多？我个人认为，一个是因为我们的云计算起步稍微有些晚，另外就是IT行业的人工成本还是稍微低了一点。美国的人工成本是非常高的，可能对专业岗来说没有上限，在这样的情况下，美国的上云成本要稍微低一点，所以美国的上云率比较高。　2、云数据库与传统数据库那对于云数据库和传统数据库来说，主要是云数据库和传统数据库来说，因为它放在云计算上面，所以它的安全性得到了很大的保障。像MySQL的单实例性能是非常弱的，我们也是经历了六年才发现各种各样的问题，它比我们想的还要弱。SQL性能拿数据量来说，因为数据性能随着数据量增多而衰减，所以数据量不能过大。另外，在迁移方面，云数据库可以实现秒级的切换，对于传统的数据库比如Oracle来说，可能至少需要几分钟左右。云数据库可以解决IO的问题，通过分布式事务并可以实现高可用分布式的架构，能够解决存储的问题。它还可以实现高可用连续性。在服务方面，它可以建立分布式架构，也可以实现高可用和读写分离等多种连续性解决方案。对Oracle来说，我们就用各种手段去做数据库调优和保障数据库性能，但是对于云数据库来说，它一个弱不禁风的MySQL云数据库，如何去保障整个应用？拿实例来说，有可能1个Oracle实例能够顶个MySQL的实例，那你如何去维护个实例，我们就需要具备掌握综合使用工具的能力。在六年中,虽然有挫折的地方，但我们确实利用云计算的智能和全栈的技术能力，极大地提高了数据库的运维效率，并且我们根据业务需求，即使是一个小小的MySQL，也支撑了非常高的亿行数据规模的数据库。3、云数据库服务运维体系存在问题特征那云数据库的问题在哪里？这是经过六年来我们的总结，问题SQL很多，有时候一个insert语句当时也没有发生高并发高性能的问题，但它就是一个慢查询，慢查询有可能是20分钟，也有可能是7秒，这个问题是非常的严重。还有一个就是SQL不稳定，因为MySQL一个列上面可以建好几个索引，和Oracle不同。在这种情况下，执行计划会走偏。另外一个是监控不准，因为虚拟机等都OK的情况下产品发生了问题，然后客户就找我们的麻烦，这是很常见的，已经几乎每天都会发生。然后就是云数据库的服务剧增。因为我们要支撑高并发，所以我们就用中间件，不管是分表分库还是读写分离，都会存在不可知的问题。另外就是架构过高，那经过我性能压测，我们一个中间件代表一个MySQL的时候，它性能衰减有可能达到60%。另外就是云计算的资源池过于集中，有时候我们把各种服务放在一起，数据库会莫名其妙地发生奇怪的问题。其实是因为业务增多，有可能一个资源池挤不下，所以把相同的应用在不同的机房去部署，也就是跨机房的部署。再就是排查问题比较难，这个问题遇到很多次了，那时候一升级我们就发现了问题，但捕捉不到相关的SQL。但是数据库看起来是很平静的，中间件是一会儿有问题一会没问题的情况，所有的工作人员都对这些无头案很困惑。4、我司六年云数据库服务历史我们公司上云大概是年初，一直以来云数据库服务运维的复杂度是不断增高的，因为数据库类型、数据库的架构类型、服务业务类型、云数据库的资源中心以及项目数以及更新的需求数目等，其中数据量增加最高，这对DBA增加了维护、管理、技术的要求。因为都是我们自建的云数据库服务，我们所面临的问题非常的大。5、云数据库与云计算相遇，存在主要问题云数据库属于PaaS的范畴，它下面是IaaS基础设施及服务，我们前几天也遇到一个问题，数据库无故中断了十分钟，以为宕机，我去找云公司，原云公司说没宕机，性能也没有问题。后来云公司向我反馈说是云计算的软件和宿主机的网卡驱动存在着冲突。还有一个问题就是LINUX操作系统内核和云计算内核发生了冲突，这是群死群伤的问题，是几百台几百台的问题，那我们去如何去解决?我们也发生了整个机房宕机，就像阿里云一样的整个机房宕机的问题，还有类似于阿里云的整个资源池的共享存储发生了IO的争夺。另外我们也发生挖矿病毒，还有其他各种各样的问题。我们面临整个资源池要废掉的问题，成百上千的实例要搬到另外的资源池上面去，这是一个非常大的问题。在这种情况下，我们需要产生一个新的保障模式。二、反脆弱运维体系构建过程1、数据库异构上云迁移过程（年开始）下面我们看一下整个的构建过程。大概在年10月份的一个业务中，我们做了一个迁移的操作。那个时候我们一穷二白，只有MySQL和Oracle两种市场所提供的中间件，市场上提供的大概有阿米巴、ATLAS，cobar，MyCat是零点几版本，大家都不敢用。在这种情况下，为了支撑业务我们只能分表分库，即使完成了以后，我们所有的监控还是一穷二白。像MySQL这样一个完整的监控，在市场上也是不健全的，因为它的指标和之前有点不一样。在这种情况下，我们做了全部用脚本化去监控，做了最原始的脚本化。我们业务要求只能够在凌晨3点到6点施工。在迁移过程中，市场上的工具是原厂自带、第三方或SQLserver还有普通的一些迁移方法我们都尝试过，后来发现这确实是很困难的事情。所以，我们DBA就用了原始的存储过程，再加上这个DTS这样的迁移模式，把业务梯度化分类。最热的数据在停机三个小时之内完成，但是在迁移的过程中又发现了很多的挫折；我们迁移工具、存储过程等在测试的时候都是OK的，但迁移的过程出现了问题。在迁移的过程中数据是有问题的、不匹配的，所以对研发做了一个限制和标准。在这种情况下我们完成了这样一个艰巨的任务，花了三个月的时间完成了3亿多行核心数据的迁移，包括代码编写。现在最大的数据有30多亿行，一直运行得很完善，而且这个项目已经做了双节点的正常运行。总结一下，在使用云数据库过程中，我们一定要考虑到云计算的环境，不要觉得整个资源池是无限的。要注意云资源池能够给你分配多少台主机，它到时候装不下你的业务怎么办？还有我们刚才所说的云计算那么多的问题，该如何去保障？另外，目标的数据库也不要做得太花哨，要做自己能够运维的数据库。比如说MySQL就是非常好的例子，都是大家都会用，也会有保障的模式。在迁移方案中，我比较倾向于研发级的迁移，可以一个用户迁过去，然后发现不行再迁回来。现在已经成熟的一个模式，大概是迁了半年，反反复复。虽然说很慢，但它确实保障了高并发的业务连续性要求。在迁移技术当中，我还是建议自研，因为市场上的那些工具都不完整，比如说前段时间我们用了开源工具愚公，用中间件迁移的时候很不好用。我们的研发整整花了一个半月才改造好。另外，在迁移过程中，希望大家把数据的一致性和迁移的效率要做好，我们目前有五六种迁移的能力，基本上都是在去Oracle的路上。现在还有几十台核心的业务在做，这个事情是很艰巨的。还有另外一个，大家不要觉得DBA就要失业了，只是工作模式发生了变化。像我们团队来说，曾经是三个人，现在有十几个，DBA是越来越多了。大家可能以前只是维护级，现在需要研发能力，我们需要不断创建工具，多做创造性的运维工作，转换工具模式。2、云数据库服务技术原则对于云数据库我们需要坚持一个原则，我一再强调要保持云主机的特性、弹性轻巧和资源的集中，大家以前都觉得好像一个Oracle里边可以放八个项目，很多个项目去复用，但是云主机它是很有很轻巧的，4C、2C这样的都可以，但是要适当的复用。另外一个就是数据库建设的原则，不要觉得自己技术很高端，去创造性的直接拿来最成熟的工具去做。当你发生问题的时候也不要害怕，在社区上找你的盟友，然后去解决。再一个就是可实施性的原则，然后当项目去立项的时候，你做一个不可维护的、大家都不知道的工具，必然会给这个项目带来很重大的问题。我们需要架构简单灵活，解决问题非常快速，大概需要这样的一个思路。尽量不要用分布式，因为我曾经做过MySQL的分布式测试，大概系统损失2/3左右的运算，性能非常弱。那要是再放在云机上面，我做了一个测试，QPS到0的时候，事实上我用到一千的时候它就死了。这个性能我觉得是不可靠的，虽然整个云资源池给你去压测的时候是非常大的，但实际上用的时候打了折，只能把性能打折作为业务能力的评估标准。所以大家不要太信整个资源池，因为它有资源争夺的现象。我们需要

转载请注明:http://www.aideyishus.com/lkzp/5766.html