首页 > 数据库 > MySQL > 互联网数据库管理员需要做些什么?
2014
06-25

互联网数据库管理员需要做些什么?

很早前就想写篇博文介绍一下互联网DBA需要干的一些事情,但苦于没有时间,忙于平台建设,最近,各个模块都初具规模,故有时间静下心来,介绍一下。

众所周知,互联网DBA与传统行业DBA有很大的不同,那就 是管理的机器多,新技术更新快,面对的开发多、网络环境复杂、要求7*24待机;这样就导致互联网DBA的工作在传统DBA工作之上,增加了更多的复杂 性,我们必须考虑如何大批量部署,如何集中化监控、如何解决单点故障而保障7*24,而为了做到这些,不是靠堆人力,我们必须有一个完整的平台作为支撑, 那么数据库平台到底要建成什么样子呢?

 

1、强有力的监控系统(监+控):

监控是我们的眼睛,我们不可能7*24个小时盯着我们的 DB,所以,我们需要监控系统来帮我们盯着,一旦异常,监控不仅仅通知我们,而必须要有控制,例如:MySQL 从库宕机了我们通过监控自动让其下线;从库同步状态失效了,可以自动修复同步等;并且,随着机器的增加、实例daemon的增加,我们会发现我们的手机报 警会急剧增加,为了我们自己晚上能睡一个安稳觉,我们怎么去降低我们的报警,例如:哪些该短信,哪些该邮件;所有机器的磁盘空间报警是否可以整合后在报 呢?这就是我们监控系统必须考虑的,

 

2、自动审核系统:

开发很多,项目很多,但是开发的习惯都不一致,可能会导致我 们审核表结构的时头都看大了,为了保证线上的统一,为了保证不被开发的神奇SQL搞伤,不被N多的项目审核压垮,我们必须有一个自动建表审核系统,我们定 义一些规则,如:不能用预留字段、主键必须为INT,BIGINT等,然后开发填写准备上线的表结构,通过系统自动审核,审核通过的,自动上线,审核不通 过的,给出建议;

 

3、慢日志分析系统:

随着自动审核系统的上线,我们可能会漏掉一些索引使用不太好 的SQL,那么我们就需要慢日志分系统帮助我们,在设计该系统时候,我们需要考虑是实时抓取慢日志,还是每天定期推送慢日志、慢日志抓取后是立即推送给开 发还是自动分析完以后给出建议给开发、慢日志还要考虑一些SQL是否需要过滤,因为他可能是每天的统计,当然这些都是自动的,设计完后,不需要人工介入;

 

4、统计系统:

我们必须清晰的知道线上DB的整体运行情况,访问量的变化、写入量的变化、图是死的,他不会欺骗任何人;我们能通过访问统计知道是否有恶意访问、是否需要优化,是否需要增加节点抗住更大的压力;

 

5、备份系统:

 

不管你信不信,我是信了,冷备份总是我们的救命草,不管我们做的多么好,故障总会有,drop database也会发生,所以,一个完整的备份系统,势在必行,我们的备份是否正常,备份的数据是否能恢复,恢复需要多少时间,都是我们备份系统需要考虑的;

 

6、管理系统:

我们机器少则上百台,多则可能好几千,如何清晰知道每台机器跑了多少daemon,DB Proxy下面有哪些机器,如何能对主库机器、从库机器进行脚本分别分发等;都需要管理系统来帮我们完成;

 

7、中间层:

是把双刃剑,他能给我们带来好的扩展,例如:动态添加从库、 主库失效检测等;但是他带来了DBA管理的复杂性、带来了更多的故障点、带来了更多的bug、如果DB Proxy性能不好的话,那就更糟了,并且为了解决client透明,我们必须考虑很多,例如:连接保持,如:字符集、last_insert_id、 use dbname等;如果我们有人力开发维护,那么我相信Proxy会带给我们欢乐;

 

以上各个系统都是为我们管理DB提供支持,如果没有这些系统 支持,那么数据库管理就谈不上平台,谈不上批量管理,谈不上承载百亿访问量,百T数据量的数据库;当然在涉及这样的系统时候,我们也要考虑新技术的引进, 例如:如果能快速的打造NoSQL 平台等;当然在部署这些模块的时候,我们时时刻刻记得,所有的模块都是会变的,我们需要不停的学习,不停的改进,才会打造宕机时间更低的数据库服务;【三 天不读书、智商输给猪】

后续会慢慢分享出,我们这些模块是如何做的,及其进度如何。

最后编辑:
作者:郑 国华
这个作者貌似有点懒,什么都没有留下。

留下一个回复