数据库的视角及运维

致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都很容易理解的事情不太清楚?