数据库的视角及运维

致DBA:为什么你经常犯错,是因为你做的功课不够- http://blog.chinaunix.net/uid-20639775-id-5765237.html
简单SQL也很慢?数据库端到端性能问题的解决思路探讨(运维)-https://mp.weixin.qq.com/s/aJkLJ8zTwhfo7FnYxuoDcg
  整套ZanDB 系统是采用了Python Django + Percona-Toolkit + Agent + 前端相关技术,同时利用了缓存Redis 和 MySQL 后端DB,整套系统采用的技术栈较简单,实现的功能对于目前来说比较实用。
  运维之路:备份管理,实例管理,主机管理,任务管理,元数据管理,日志管理,日常维护。
> MySQL数据
  一种视角:MySQL主要存储对数据状态有要求和更新频繁的数据;MongoDB主要用于存储计费数据、日志数据和流水数据;HBase主要用来做数据分析和存储大数据内容。
  MySQL的优化:要降低MySQL查询、修改、删除脚本的复杂度,以原子查询的方式访问数据库。其次,MySQL的优化器还不够完善。MySQL的优化器还更接近于基于规则的优化,而不是基于成本的优化,对复杂查询的智能优化有待提高。因此MySQL数据库多表联合查询的性能还不如Oracle。我们的开发规范要求开发人员尽量避免三个表以上的表关联查询。第三,原生版本的MySQL主从延迟挺严重,远高于Oracle数据库。为此我们将批量更新和批量删除的事务的粒度拆分的比较细,同时在核心业务上使用SSD硬盘来降低主从延迟对业务的影响。
    MySQL有以下优点:灵活、可配置、可二次开发、方便维护管理,集群的性能和扩展性强。 
MySQL的缺点是存储和查询的数据量、并发数有限,主从非强一致。这就要求DBA必须对数据库的业务深入理解,合理规划并发数、数据量,进行预估、拆分等架构优化来规避这些不足。

> 数据运维
   数据的安全我理解应该从两个大的维度去分析,第一是访问安全,不会出现不应该有的访问,不会因为不应该有的访问崩溃,用户的敏感数据不会泄露;第二是数据安全,数据可恢复,不丢失。
   访问安全,我们是基于操作系统的安全机制和数据库自身的安全机制来保证的;在操作系统的安全层面,我们采用IPTABLES白名单的方式,仅允许指定范围的IP的内网服务器访问数据库,同时严格隔离线上和线下。在数据库自身安全机制上面,我们针对细粒度IP进行授权,并且回收了表的创建、删除、DDL操作权限;同时我们开发、部署了数据库访问巡检工具,实时屏蔽不合法的访问。针对访问安全,为了降低授权成本,我们研发并全部使用自动化授权工具授权。
  数据安全,我们主要是通过多级备份策略来保证的,多级备份策略是指:热备份+逻辑备份+二级备份+定制备份。热备份保证数据库可以在一周内恢复到某个时间点,逻辑备份作为热备份的补充;二级备份主要是将历史上的逻辑备份做一下远程双份备份,以规避误操作带来的损失;定制备份是针对一些特殊业务需求,做按天切片备份,满足业务对某天数据恢复的需求。同时为了确保数据快速恢复,我们尽量把单实例的大小控制在100G以内。热备份+逻辑备份+二级备份可以满足大部分广告数据的恢复需求,而对于资金、计费、财务类数据,由于涉及到审计,我们会与业务方确认是否需要补充定制备份。
> 运维技术
   运维技术人员的素质:首先是知识沉淀。基础知识是做好工作的基石。系统的学习各类基础知识,熟悉数据库、操作系统的架构及相关工具的使用,熟悉主流脚本语言的开发,同时还需要对故障定位有一定的理解。其次是经验沉淀。要耐得住寂寞,不断积累经验。做运维工作需要丰富的经验,高并发、大数据量运维经验,大量服务器和实例的运维经验。在关键的时候这些经验会拯救企业的服务和数据。再次是业务沉淀。要具备较强的业务理解能力,深入并精通所在岗位的业务。技术是为业务服务的,技术人员到一个新的岗位会的只是通用技术,技术适应并结合业务才能发挥更大的作用。最后是软技能的沉淀。较强的执行力,适应业务、技术的创新能力,良好的沟通协作能力和组织能力,优秀的团队配合能力;细致、冷静、沉稳,优秀的判断能力和紧急状况择优处理能力;充分的理解和被理解。要有不断更新自己的欲望和自我驱动力。互联网技术日新月异的,行业的发展非常迅速,必须不断地学习新知识和技能,才能跟上时代,更好的成长。

  运维的艺术,运维总共有几条线呢
一是部署。由少到多,这是一种机器的控制方法;
二是从小到大。当服务器的数量达到有多少屏都看不全的时候,监控的手段就变得非常重要。这时候有一种方法是白盒运维;
三是性能,精益运维。

  运维的法宝是三位一体。
  其一是运维自动化和流程化,方法有很多种。原来我做的是车载,既然要做到12兆,里面不可能有拍摄,一个拍摄的包没三、四十兆做不到。目标是一样的,一定要会用工具,把容易出错的事情用脚本规范好。
  其二是监控常态化,及时报警及隔离,触发补救措施。事故不可能无缘无故的发生,肯定是之前的工作留下了什么隐患,需要及时查清。要对异常采取及时的处理,UPYUN 使用第一人称的脚本做监控,发生异常状况它就会出来汇报。最明显的是DDos攻击,总是事后才发现,因为流量打过来,最先感知的应该是网卡。针对这点,UPYUN用脚本捕捉网卡的异常上升流量,可以接收到它“临死前”发出的警报,运维人员就可以根据这个及时把受攻击的节点摘掉。
  其三是性能可视化,运维要对自己的业务负责,提供连续的健康度报表,以争取资源。因为运维需要拿到机器或足够的硬件,否则工作很难进行。当运维和老板或是上级讲技术点时,如果他们听不懂,就可以把报表拿给他们看。这就是性能可视化的一个重要的意义。
  部署自动化的三个要素:应用、网络、硬件+系统。第一期时UPYUN用awk、sed、bash,第二期换成了Ansible+playbook,第三期开始使用cmdb+Ansible。发布流程之前很不规范。比如运维需要cmdb+Ansible的结合,但发现还没做,怎么办呢?就可以用定时定点的方式规定好星期三做发布、星期二做测试。届时大家去一个会议室,事先设定好,届时开始观察。星期五继续观察,发现有问题就回退
  2015年5月份左右,UPYUN 开始关注Mesos+Docker,之前一直选择OpenStack主要是出于节约成本的考虑。而在发现Docker很好用后,团队开始集中精力研究Docker。ELK可以做很多事情,可以看到低于100毫秒、300毫秒、500毫秒、1000毫秒,有4xx、5xx的比例,数据报表一点点小波动都可以看到差异。UPYUN曾经做过测试,没使用优化内核算法和使用了新的hybla拥塞算法,从3.18的内核升到4.1的内核,数据会有提升。Kernel要自己把握,3.18到4.1的时候,我们曾经遇到过一个问题:内网做TCP的时候做大包调整很爽。但放到外围CDN的时候,4.0出现了Bug。4.0的内核在因特尔1000的网卡双向组合的时候会无响应,而3.18的内核接入就没问题。它的好处显而易见,但一定要把握度。
  作为运维人员,会有很多烦恼。第一点,运维很多时候都要扮演“接盘侠”和“背锅侠”的角色,因为公司要有一个人出来承担责任。如果运维能够在这个压力下解决问题,获得老板认可,那你就是合格的。
  另一点是频繁申请和更换资源。现在OpenStack和Docker都有这方面需求。Ansible和Mesos也很实用,现在几千台服务器都有Docker。第三是监控不到位,这点可以用ELK和Hadoop来解决。第四是消除单点,这一块可以借助LVS+Haproxy。在硬件方面,双电源、双电力、多运营商、双交换机、双机柜、多机房这些配置,需要根据业务不同的发展阶段做权衡,来进行选择。
  运维的指导思路。首先是与人无关:要将机器负载均衡做得滚瓜烂熟。用脚本、Playbook做机器生成,跟人无关。其二是与己无关:要舍得把东西交出去给下属做,自己不断学习新的东西。第三是与状态无关:运维要做无状态和扩展性,有些程序员很喜欢有状态,这就要考验你、工程师和CTO的能力,推动程序员去做。最后一点是与数量无关:要做部署的恒定,运维话语权的增长,很多时候是在业务突飞猛进时,运维成本仍保持不变,自己在老板心中的威信就会提升。
  数据库高可用和同步对我而言的最大问题就是对数据库是怎么跑的、如何使用、为什么要做高可用和复制同步功能等一般DBA都很容易理解的事情不太清楚?

你可能感兴趣的:(数据库DB)