本文作者将从更全面的角度分享自己一年多来DBA工作的心得，希望能给大家带来启发和帮助。DBA的日常工作我觉得DBA真的很忙，我们来看看DBA的具体工作：备份与恢复、监控状态、集群搭建与扩容、数据迁移与高可用。以上就是我们DBA的职能。了解了这些功能之后，还需要对架构有更深入的了解。您不知道如何处理这些故障和投诉。所以我们要了解缓存/线程，SQL优化，存储引擎，SQL审计，以及锁和实践；对于更深层次的架构，我们将研究内核原理和源代码定制。DBA的工作太多了，它们就像一个小怪物，等待着我们去解决。MySQL性能优化性能优化让我们的MySQL运行的更快更流畅。在开始MySQL性能优化之前，我想提出MySQL性能优化的三个关键点：为什么？什么？如何？我们为什么要做性能优化？我们的运维反映了我们的数据库。正常情况下需要1秒，后来变成10秒，我们就要开始优化动作了。本来他的访问时间是1秒，如果我们想优化到0.01秒，就需要开启优化。第二个是什么？我们的数据库性能不好的原因在哪里，我们需要找到这个关键点。当我们发现这个问题时，我们需要有针对性地进行优化。在MySQL优化之前，我们需要明确3W个重点。MySQL优化的基本流程MySQL优化的基本流程如下：我们首先需要登录操作系统，通过操作系统命令进行优化。比如通过操作系统的基本命令，我们可以看到我们操作系统的哪些资源占用率比较高。这就是资源的短板。短板就是这个资源的占用率或者利用率特别高，必须要密切关注。比如CPU负载极高，已经超过了我们的核心数，或者使用率极高，达到80%以上，引起了我们的注意。确定了这个短板之后，我们需要确认是哪个进程使用了??我们的资源，使得它的使用率或者说占用率特别高。一般来说，与我们相关的是MySQL层。比如CPU使用率超过70%，我们就需要排查一下这个MySQL是哪里出了问题。更进一步，如果我们在MySQL中执行某个大的MySQL时发现整个服务器或者整个数据库都在，那可能是语句的问题。我们将通过MySQL监控或日志信息进一步排查MySQL问题。找出哪些资源有问题并进行故障排除非常重要。我们登录系统，发现CPU、IO、网络等都正常。在这种情况下我们应该怎么办？对于这种情况，我们可以分三种情况来判断：操作系统的问题。也许当我们登录MySQL时，整个系统都在那里。我们需要通过操作系统查看是哪个资源出了问题。数据库实例问题，数据库实例问题与数据库配置参数有关，也就是说，我们的配置参数中可能存在一些不合理的设置，需要我们进行优化。会话问题，我们登录MySQL的时候，一开始是正常的，后来发现实例变慢了，可能是MySQL语句有问题。我们要看MySQL执行计划是哪一步慢了，拖慢了整个过程。如果我们发现数据库性能有问题，我们可以按照这个流程来定位问题。MySQL优化的几个关键点通过刚才的基本流程，我们可以确定MySQL需要优化的几个关键点如下：应用访问优化，因为有些应用需要访问我们的数据库，有请求发送，数据存储和网络交互等，会导致数据库性能变慢。对于服务器硬件的选择，不知道你们的DBA对服务器有没有自主权。如果有自主权，我觉得应该根据MySQL的特点来选择服务器硬件。比如我们可能要考虑数据和日志不同的存储机制，选择不同的类型来优化。操作系统的优化意味着我们需要在部署配置数据库之前优化操作系统。它可以优化我们的数据库。数据库优化，数据库优化的过程是从全局角度进行优化的过程，而不仅仅是针对数据库本身进行优化的过程。应用访问优化下面我们根据每个关键点来进行一点，比如应用访问的优化。第一步是减少数据访问。因为减少数据访问实际上就是减少磁盘访问。我们知道数据访问磁盘获取数据是很慢的。如果我们是机器盘，因为机器盘是通过机器轮转获取数据的。我们应该把活跃数据和内存数据放在内存中，这样可以提高我们数据库性能1-1000倍，而且它的优化成本很低。第二步是减少更多数据的返回，减少更多数据的返回。最终是减少网络传输。大型系统很多，网络传输是一个很重要的瓶颈。假设我们的数据库服务器和我们的应用服务器之间的距离是20公里，因为光数据库相距20公里，一个光请求是0.2毫秒。如果我们减少数据请求的数量，这个时间会短很多。所以如果我们发现数据库的性能有问题，我们可以通过P命令看看是不是网络有问题或者时间会不会变长。三是减少互动次数。假设每次交互以20公里为基准，一次交互的时间为0.2毫秒，两次交互的时间为0.4毫秒。如果有10000次操作，就是10000次0.4毫秒，这样整个交互时间就短了很多。但它也有其复杂性或不适合扩展的情况。从应用层减少优化。成本也很低。我们公司的DBA在服务器应用的选择上没有太多发言权，移动公司都是集团公司通过集中采购的方式来选择的。在收集的时候，我们不可能指定这些服务器用在哪个数据库，这些数据库用在哪个服务系统，所以我们没有办法让DBA参与服务器的选择。这是我们移动云的一些服务器选型：使用的服务器是HPDL360G9，CPU是2核×e5-2650V4，内存是8×32G，硬盘是6×1.2TSAS，并且网卡为4×10GE+4×1GE+1IPMI。特别是，如果我们的DBA对服务器有自主权，我们可以把数据放在SSD盘上，把日志放在SAS上。这是服务器硬件选择的主要地方。操作系统层面的优化，我们推荐使用Linux操作系统，我们做了一些主流的开源的。像一些商业Linux一样，这些是我们使用的。如果我们要使用这个SWAP值，我们尽量不要使用虚拟内存，而是使用物理内存。因为物理内存的访问速度肯定比访问磁盘要快很多。所以我们把这个值设置为10。可能有同学会说为什么不把这个值设置为0呢，直接访问所有的物理内存就可以了。如果设置为0，可能会发生内存溢出，也就是OOM。这不是我们DBA们希望看到的，所以我们一般把这个值设置为10。关闭NUMA特性：我们公司一般都是在单实例的情况下，所以这个时候要注意NUMA特性。NUMA特性是假设我们在一台服务器上有两个CPU，分布在服务器的左右两侧，同时有四块内存。同侧CPU作为一个NUMA节点，即同侧CPU物理分布访问同侧内存，距离比较近，快点。我们尽量访问同侧CPU的同侧内存，这与我们数据库的特点是相违背的。因为我们的数据库希望一般部署数据库的服务器不会去分配其他的应用系统资源。所以我们希望数据库是独享的数据库资源。在这种情况下，我们应该尝试关闭这个NUMA特性。网卡优化：我们使用多张物理网卡绑定成虚拟网卡，即绑定部分双网卡或者调整网络参数。磁盘调度设置：一般有几种算法，比如NOOP算法、CFQ或者Deadline算法。比如我们数据库使用的NOOP算法有什么问题？将有一种方法可以饿死读取操作。如果有两个写操作，第一个写操作不需要等待第二个写操作结束才开始。如果是读操作，第二个读操作必须在前一个之前完成。如果几毫秒内来了一堆写操作，后面的读操作就会饿死。这不符合我们数据库算法调动的方式。另一种是CFQ算法。CFQ算法不适合我们的数据库服务器。MySQL是单操作服务器。所以我们的算法不适合我们使用。一般数据服务器会使用Deadline算法，此时程序会调用IO请求来解决请求。这个Deadline算法比较适合数据库，因为这个Deadline算法比较适合。最后一个是文件系统的推荐。我们移动云的数据库系统是Xfs或者Ext4或者Noatime或者nobarrier，都会有影响。这是对数据库系统的优化。对于数据库实例的优化，我在标准化的时候列出了几个我们需要标准化配置的参数，这里就不一一揭晓了。这些参数很重要，因为它决定了我们实例的性能。如果一些参数配置不当，我们实例的性能会受到很大的影响。SQL语句的优化这里是编写高效SQL语句的原则。我们的DBA需要知道这个原理，同时也要通知业务方的研发，让他们知道。很多业务端都是业务写的。如果他没有经验，他就会写出一些有问题的句子，所以***就成了我们DBA来严查。所以一开始要把这些想法落实到业务研发上，让他们按照这个流程来写SQL设计。索引的设计在这里指的是覆盖索引。比如这个覆盖索引，我们的查询，查询的字段都在这个索引里面。另外，我们查询后面的字段也是索引，我们的一些排序位置也是覆盖索引。这就是所有这个系列都被索引的情况，所以它们被称为覆盖索引。这里我也列举了一些不能使用索引的情况：比如选择率低的字段不要选择索引。如果索引扫描的记录数超过30%，就会变成全表扫描。还有像左边以通配符%开头的查询条件列，还有两个独立的索引，一个做索引，一个做排序。以上就是MySQL性能优化的步骤。自动化运维实践所谓自动化运维实践，相当于给我们的DBA们提供小工具或者小帮手，帮助我们开启而不是纠缠我们。我们移动云的体积是成百上千个数据库的体积。如果我们面对的是几个或者十几个数据库，有没有这个自动化无所谓，因为你自动化起来会比较麻烦。如果您已经拥有大量资金，则需要在自动化数据库上进行平台化和扩展。以下是我们在自动化运维方面的实践经验。标准化安装部署我们的目录方案、版本和部署过程都有标准的文档可循。比如一次部署打包多个应用，我们需要将标准包打包到一个节点上，一步完成。那么这种标准化的安装部署为后续的自动化安装部署打下了一定的基础。Automateddatabackup数据备份对于我们DBA来说是一项非常重要的工作。为此，我司也在建立合理、有效、规范的自动化备份规范。例如，对于我们的常规备份，我们每周进行一次完整备份。变更前后，有业务变更。在此之前，我们需要做一次完整的备份。万一业务变更有问题，我可以及时回滚。这是一个自动化场景：我们使用innobackup工具+自动备份脚本调用+crontab定时来做。自动化的日常监控监控是DBA的第三只眼，如果建立了实时有效的监控就非常有效。我们的监控使用的是Zabbix监控工具。像确定一些告警阈值，一旦超过这个阈值，我们就可以给我们的DBA发送短信和邮件。这是自动的日常监控。自动化深度检测是对监控无法到达的地方进行补充。比如我们需要扫描或者看一些大表或者看一些没有索引表的情况，它的输出是很复杂的，是一张表或者几张表，所以我们需要深入检查才能Finish。深度检测我司也采用检测脚本开发，通过Ansible统一推送，自动生成检测报告。也就是说，这个检查的结果可以清晰的呈现给DBA查看和检查。自动故障转移自动故障转移发生在单个节点发生故障时。比如变更操作，一些keepalive部署配置，切换脚本，VRRP协议等实现。也是通过写一些脚本，可以周期性的检查我们数据库节点的健康度。比如这个节点上是不是VIP或者进程是不是活着？一旦发生异常，节点将自动切换。节点自动扩容当出现单节点故障时，当我们需要部署新节点时，需要启动节点自动扩容，并编写脚本来完成。自动化安全审计这是异常访问，异常操作可以审计追溯。部署安全审计插件，此安全审计插件+启用安全审计日志+日志自动化或分析提炼。所以是否启用这个插件是根据公司对安全审计的要求和性能要求来平衡两者。因为我们对这次安全事件还是很感兴趣的，所以我们启用了这个安全审计插件。启用该插件后，我们需要配置一个配置文件。以什么方式或有多大？这些参数可以在配置文件中配置。自动密码审计这个自动密码审计也是一个插件，就是我们安装了强密码审查的日志。这个插件的工作原理是设置规则，日志中需要多少位或者多少位，或者对特殊字符的要求。我们在设置密码的时候，一定要满足这种强密码认证的要求。这也是实时检查的。也就是说，当我们为数据库用户设置密码时，如果不符合这个强密码的要求，则不会通过，以防止一些更容易被破解的弱密码。自动化日志分析我们的日志分析非常重要。如果有问题，我们需要这个日志分析。没有问题的时候，我们还需要一个日志分析工具。因为它可以产生潜在的优化建议，所以我们使用了Percona的一个工具Pt-query-digest，我们只需要查看DBA的慢日志，就可以找出内容有什么问题。自动化数据校验是通过自动化校验和修复工具来完成的，我们还设置了crontab任务让它定时执行。自动化数据清理由于数据库每天和每周都会进行备份，因此我们需要一种机制来定期清理备份文件。我们还使用脚本进行定期开发和观看。如果备份文件超过两个月，我们将删除它。如果文件都在两个月以内，请不要担心。两个月后取出。日志自动切分如果数据库运行时间长，慢日志或者错误日志比较大，需要定期检测日志文件，超过一定值就会自动切分，否则会不予处理。以上就是我们在数据库运维方面的沉淀和积累。虽然没有腾讯或者阿里那么大，经验丰富，但是以上是我们摸索出来的一些经验，希望对大家有所启发或者帮助。
