平台化管理MySQL数据库：拉手网DBMP平台介绍

jack

　　一、为什么要有DBMP平台


　　公司业务不断增长，需要管理的MySQL数据库也在不断增长，DBA手里的活越来越多，从安装MySQL数据库再到线上数据修复、数据迁移、SQL审核等一些日常琐碎的事情就占用的大量时间。


　　再说说我们现有的数据库故障切换转移是如何处理的，我们MySQL现有的数据库集群都是主从方式的，一个主下面挂很多从库，有的从库下面还有从库。


　　我们举个故障例子:


　　比如主库服务器宕机了，有一部分是在负载均衡器上的，主库宕机后可以把访问主库的VIP全部切到另一个备主上面，那从库呢?从库就需要等DBA上线一台一台重新change到备主上面，故障转移时间过长。


　　再加上人员数量有限，DBA做一些服务器、DB、架构等性能优化方面的工作已经没有精力去做了，这些问题相信很多正在发展的公司也都会遇到，所以我们急需将日常工作自动化、平台化以减轻DBA工作量，线上故障自动转移，对故障线下处理以减少线上故障处理时间。


　　针对以上这些问题，我们运维成立由我(常纯)主导，由数据库组的韩永生(高级DBA)做平台需求及开发，就这样DBMP平台诞生了。


　　根据之前平台设计思想间接的为公司节省了成本、减少了故障恢复时间，另一方面我们也有时间向更高级技术方向发展。


　　二、DBMP平台架构


　　DBMP平台开发语言:后台管理用Python语言编写，前台管理页面用PHP语言编写。


　




　　平台架构


　　DBMP平台由服务端Server、DNS服务器及MySQL集群组成。


　　Server端是由两台服务器用keepalived做高可用灾备由VIP来连接管理各主从集群数据库如下：






　　在Server端主备服务器上都部署MySQL(双主集群)、页面及管理脚本用来监控、管理集群的MHA、MySQL


　　Client端每台服务器上装有agent对MySQL集群服务器进行管理。


　　Agent的作用：环境初始化、MySQL安装、MHA安装、MySQL及MHA的状态检查


　　Client端MySQL集群为一主多从模式，故障转移由MHA+Server+DNS共同完成，发生主备切换主从之间的数据一致性由MHA来保证。


　　故障切换过程： MHA发现MySQLMaster端不可用后通知server端并完成各从库的数据同步指向新的Master数据库服务器，Server端收到MHA发来的消息后先将原Master做下线处理再将BakcupMaster修改为Master并修改DNS信息。


　　对于主库的故障是由MHA去发现并发起故障转移，那对于从库的故障是由Server端上的监控脚本来完成。


　　应用访问数据库通过不同的域名实现读写分离，多个从库是以一个域名对应多个主机，如果从库数量不多且读压力较大时,可以直接把一部分从库的读转移到主库上，用DNS的CNAME记录实现(或A记录)。


　　多个从库之间的负载用DNS轮询实现，方法在DNS上加入A记录实现。数据库上线下线通过修改DNS记录。


　　三、DBMP平台页面展示及功能介绍


　　这部分内容对DBMP平台一些核心功能做以下介绍：


　　1. 主机管理：






　　主要功能是对新上线系统服务器进行环境初始化，如：添加主机时安装agent，获取主机名。agent进行启动停止、agent状态展示及删除主机的操作。


　　2. 实例组：






　　该页面可以添加实例组，每个实例组是一个MySQL集群，在这个页面可以看到是否对实例组进行健康检查，MHA的开启状态等信息


　　实例组管理页面：






　　这个页面主要是对该实例组进行自动化安装MySQL、自动初始化、修改配置文件、MHA管理、用户管理等功能。


　　实例列表页:


　　展示实例组 组状态、启动、停止、上线数据库及编辑单个实例配置文件。


　　该页面中有优先级列，在平台上有两种故障切换方式，1、是MHA工具进行切换，这个网上很多就不多讲了。2、我们自己开发的一套监控脚本checkdbmp.py，在没有MHA的情况下主库发生宕机时平台会自动使用这个脚本进行主备切换，并且所有从库指向新的主库


　　a)配置文件：


　　可以对该实例组的MySQL配置文件或MHA配置文件进行编辑修改，这里是修改当前实例组的模板，对每个实例如果有特殊需求的，在实例编辑中可以修改。


　　b)MHA管理:


　　是对该实例组下的实例服务器添加安装MHA，启动、停止及状态展示，如下图：






　　c)用户管理:


　　对该实例组的MySQL用户进行添加、修改、删除操作的，需要说明的是主库上面的用户是有读写权限的，而从库上的用户是只读权限。通过平台每次数据库的重启都会将用户重建一次，以防止有人不通过DBMP平台乱建用户。


　　在这里特别说明一下优先级的功能，优先级是指在主库故障时的切换顺序，在没有启用MHA的情况下数据库的故障切换是由python脚本完成的，数字越大优先级越高，优先级为0的是不参与切换的。在MHA启动的情况下故障切换的优先级是由MHA决定的，同样优先级为0的是不参与切换的。


　　3. 备份：






　　备份功能我们就只展示前几条测试功能吧。备份功能主要是依靠服务器上的crontab来完成的，我们的时间设置也是按照crontab的格式来做的。在备份功能中可以完成本地备份、异地备份。


　　对于MyISAM表的数据库来说是直接用的copy完成的。对于InnoDB数据库我们用PerconaXtrabackup来做的，用mysqldump功能也可以。这三种备份方式都可以在这个页面中完成，使用了第三方工具的备份功能的常用参数在添加备份时是可选的。


　　4. 慢查询:






　　慢查询功能的运行同样和备份、计划任务的时间格式是一样的都是Linux系统中crontab来完成的。MySQL的慢查询提取功能是通过percona-toolkit将提取的慢查询保存到Server端的慢查询数据库中，然后根据不同实例组中指定的收件人邮箱定期发送邮件给DBA及相关开发人员。在最新版的DBMP中慢查询这一块是在实例组中可直接配置添加，可在实例组中直接添加、查看该实例组下的慢查询。


　　5. 计划任务：


　　计划任务功能主要是对一些需要定期执行的脚本从这个平台进行添加，这样做的目的是能够让人更直观查看到现在线上有哪些计划任务在跑着，所有的计划任务操作都是在脚本文件中写好上传的。


　　在服务端也专门开了一个接口来接收计划任务在执行过程中发出的日志，当然对于日志格式是有要求的，哪些日志是正常的，哪些日志需要报警通知相关人员的，这些都有相应的规范。


　　四、DBMP平台优化方向


　　Zabbix监控工具和DBMP平台一体化，通过该平台可以自动添加修改查看Zabbix相关数据，及时了解MySQL数据库性能及资源使用情况。


　　基于DNS的特殊性，使用DNS做负载还有很多缺点的如：DNS缓存、负载分配不均等问题，在我们新版的平台上我们加入LVS做负载均衡，这样管理负载均衡更加可靠、方便。


　　应用日常需求像sql执行，现在都是邮件发到DBA这边然后DBA去执行，有很多常态化的需求是可以让应用开发直接操作执行的，可以在这个平台中加入页面可以让开发直接执行一些sql语句。


　　SQL审核功能，现在已经有像去哪儿网开源的Inception工具，后期也想用到这个平台上可以为DBA带来很多方便。


　　五、技术交流方式：


　　Q1：DNS轮循，平均分配，没有其它分发策略吧?


　　在我们第一版中没有采用其它分发策略，在接下来的版本中我们会用LVS做负载，以解决DNS本身所产生的一些问题，如NS缓存分配不均等问题，


　　Q2：DNS是内部还是外部，会不会出现解析超时的问题?


　　DNS是内部的，不同IDC中都有一个DNS服务器，目前没有出现解析超时的问题。


　　Q3：Zabbix监控MySQL是做的二次开发吗?有哪些需要注意的技术问题?


　　Zabbix监控MySQL没有做二次开发，在DBMP平台需要调用Zabbix中的数据时用了Zabbix的接口，需要做开发。只是自己添加了些监控模板。


　　Q4：Zabbix监控模板定制你们一般都是怎么分类的，有哪些细节需要注意?


　　我这边是按MySQL参数分的类，细节上倒没有，只是在监控项的归类上划分好就可以了。


　　Q5：MySQL的内存配置是否已经最优，是否会自动调整?


　　MySQL内存配置我们这边是参照Zabbix上的性能图去慢慢调整的，很多数据库实例不是最优的。不会自动调整，需要DBA手动通过DBMP平台处理。


　　Q6：一台物理机会启多个MySQL进程吗?


　　因为这个平台还是第一版，目前已经迁到DBMP平台上的实例组还是一台服务器上只启了一个实例的。但是我们新的DBMP平台上只要硬件资源可以是支持多实例的。


　　Q7：如何确保主从节点数据的一致性，binlog记录是row格式的吗?


　　主从数据的一致性需要通过percona-toolkit中的工具去检测，工具检测只出结果，但不不影响数据。出结果后由DBA去手动处理数据差异Binlog记录络式是row模式的。


　　Q8：MySQL有没有做分布式和读写分离，通过程序做吗?数据量大概什么级别?Keepalived如何防止脑裂?


　　我们这边在数据库前端是有Redis的，将一些热数据会存到Redis上。


　　读写分离在这个平台上是采用了一个写域名一个读域名两个域名地址程序实现的读写分离。


　　我们这边最大的实例有400G+的数据量。


　　Keepalived的问题，我们这边用到切VIP是用的硬件的负载均衡器切的，没有用Keepalived。Keepalived如何防止脑裂，这个问题应该就是在切换时不成功两边同时写的问题，我这边是通过两种方式的脚本去解决的：


　　在Keepalived上在切换时触发的脚本中运行脚本去修改VIP。


　　在Server端做一检查脚本去检查如果发现有异常就远程到异常服务器上检查，再去修改VIP。


　　运维能否有一个自己的节日?


　　可否每年都有那么一天，


　　让业界记得默默耕耘的运维人?


　　实不相瞒，这就是我们联合各大运维组织来推行“运维日”的初衷。


　　已有1500余名运维人员联合署名支持本倡议。您希望哪一天是“运维日”?


　　如果您选择或建议的“运维日”成为最终结果，您的大名将镌刻在“运维日”官网上。