关于数据库自动化运维平台的设计及开发实现思路 今个讲解下，个人对于数据库运维自动化平台的理解，话说这个项目和我以前做的lvs集群平台一样，都是分成两个主要的角色，一个是对于普通用户的申请及权限内的执行，还有一个是对于dba的审核及相关的日常dba数据库操作。
DBA其实也是很苦逼的，再高端的dba也是由苦逼开始的。如果你是苦逼的dba，那更要往下看了。
因为工位紧张的缘故，我现在和一排的dba做在一起，见到了他们的高端，也见到了他们的苦逼。
经常会有人烦他们，让他们进行DDL DML的相关操作.大家也都知道规范的数据库维护是不允许开发人员直接搞的，尤其是DDL相关的，这个需要发邮件，请dba来操作的。 这个时候就需要有一个系统来解决这些让人蛋碎的事情。运维自动化平台就是为了解放蛋碎事件的。
这些东西，咱们完全可以自动化流程起来的。
1. 权限的申请
2. 会发给对应的领导，让他来确认
3. dba会审核这次的申请
这个时候，权限的申请已经结束了。用户这时候，可以去DDL和DML操作。
这时候，你就有这个库的权限了，可以提交DDL和DML的语句。看下面的流程图，估计你已经看到大概了。
原文：http://rfyiamcool.blog.51cto.com/1030776/1428425
该系统的流程设计，是由前人人网dba大牛（谭志军）来搞的，至于功能的实现是我搞。这项目做到现在快一个月了。 这首席dba确实很强，公司的zabbix每天都有几G数据量增长，你可以想想现在数据该有多大！ 但在他眼里，那都不是事！ 人甚是有意思，只是有些时候，不解女孩子的风情 ~
开发的日子里，深深的感觉到，任何人都有产品经理的潜质，曾经和他说，以前有个人总是给我提需求，让我"灭"了！ 没想到，他也只是浅浅的一笑，然后继续提需求，感觉他好高大上。
他的微博是：http://weibo.com/tzhijun ，记得给他加粉。
我们的dashbord，这里分享的是初期的实例，后期我们还是会做大量的前后端的高进。
下面的截图和功能介绍只是该平台中的部分内容，有些话题不太方便聊，见谅。
原文：http://rfyiamcool.blog.51cto.com/1030776/1428425
这是用户执行DML SQL语句的页面，这里触发后端的时候，会把不是DML的语句，都会过滤出来。
原文：http://rfyiamcool.blog.51cto.com/1030776/1428425
下面是DDL的情况：
这个时候，管理员收到了相关的进度邮件，登录平台处理未完成的任务，在权限管理平台，可以给为DBA开启动态口令卡，密码是60秒更新一次的。 当然也可以撤销这种烦人的认证。
这里主要是查询数据，自动会分页，数据的导出txt和json文件。
这个数据库运维系统，不仅涵盖了上面所说的 数据库流程体系最基本的功能，而且还实现了对于dba本身的维护的功能模块。
首先是慢查询，我会同步crontab的状态，会定期抓到慢查询的结果，扔到我的http存储接口上。
原文：http://rfyiamcool.blog.51cto.com/1030776/1428425
再说下报警方面，这边有自己的一套报警方式，以yaml格式做成配置文件，然后python会根据yaml里面的配置，做他该做的事情。当然这些事情交给zabbix也挺好。
现在公司的zabbix开发人员正在逐步开发api接口。 没有开发之前，还是我们自己控制好点。
原文：http://rfyiamcool.blog.51cto.com/1030776/1428425
下面的就不截图了。。。。 怕首席打！
对于数据库的备份，采用saltstack的jid来异步的执行任务，会记录备份文件的大小，开始时间，结束时间，及备份的状态，另外在modules里封装了一个rsync的模块进行文件上传。 平台每天主动出一个备份情况的报表，除了上面的备份情况，当他监控到今天没有搜到10.10.10.10这mysql的备份，会在报表中标红。 如何针对备份进行报警，客户端每次备份的时候，会反查下到现在为止，上次有没有备份成功，没有的话，也会触发报警。 如果周期是长线的那种，每次客户?div style="border-bottom:1px solid #aaa;margin-bottom:25px">烂泥：【解决】VPN连接后，不能ping通内网服务器 阅读原文» 本文首发于烂泥行天下。 上个周把VPN服务器搭建完毕，打算本周连接进去开始部署相关的工作。 但是今天在成功连接进入VPN后，却发现客户端无法ping通VPN内部的其他服务器。从而导致，工作无法继续。 经过排查发现，客户端可以ping通VPN服务器内网网卡的IP地址。而内网的机器是可以ping通的，甚至VPN服务器本身内网网卡的IP地址也是和内网的其他机器正常通信的。 VPN服务器内网的IP地址是10.10.1.20，客户端获取到的IP地址是10.10.1.8，如下图: 刚开始还以为是由于服务器上没有做静态路由导致，于是查找很多有linux路由绑定的资料。可是发现，没有用处也使用不到。 查看VPN的日志，就只发现了一条有关GRE的错误，如下图： 根据这条错误信息，查找相关的资料。然后进行配置，测试还是不行。最后再想是不是VPN软件版本安装错误，查看如下： 看了看软件版本也是正确。 再次查看是不是软件配置出错，如下图： 发现也没有错误。 这可愁死人了，通过tcpdump抓包也没有发现可用的信息。 最后在一个小站点，提醒说很有可能是iptables转发出问题了。 果断查看文件/etc目录下的sysctl.conf文件，然后重新载入，使其生效。但是在执行时却出现如下的来连接错误。如下图： error: "net.bridge.bridge-nf-call-ip6tables" is an unknown key error: "net.bridge.bridge-nf-call-iptables" is an unknown key error: "net.bridge.bridge-nf-call-arptables" is an unknown key 根据错误提示信息，查找资料。反馈出现这样的错误提示信息，一般是由于没有加载bridge模块导致。只要手工加载即可，如下图： modprobe bridge lsmodgrep bridge 重启PPTP服务，再次ping。 通过上图，我们可以看到目前已经可以正常ping。至此，该问题结束了。 PS：其实这个错误，我们在安装配置VPN时，就可以避免的。出现这个问题，还是因为当初配置VPN时大意所致。 本文出自 "烂泥行天下" 博客，请务必保留此出处http://ilanni.blog.51cto.com/526870/1428339 
没有评论:
发表评论