【IT168 技术】12月25日消息，2010互联网行业技术研讨峰会今日在上海华东理工大学召开。本次峰会以“互联网行业应用非常好的实践”为主题，定位于互联网架构设计、应用开发、应用运维管理，同时，峰会邀请了来自盛大、阿里巴巴、五分钟等互联网企业的多位嘉宾演讲，他们将同大家一起探讨数据库技术在互联网领域的深入应用。

▲2010互联网行业技术研讨峰会专题报道

　　以下是阿里云MySQL DBA 何云飞主题为“阿里云MYSQL管理架构”的演讲全文：

▲阿里云MySQL DBA 何云飞

　　各位嘉宾大家好!

　　今天我跟大家分享一下我们阿里云的MYSQL管理架构与模式， 在这里我们只分享思路，希望能给大家带来帮助。

　　我们目前有300台左右MySQL数据库服务器,单机容量最大达到1.4T，平均数据量400G左右，应用数量30多个，单一应用最大数据库集群服务器有100多台。 我们工作内容大致是：应用KICKOFF，设计评估，SQLREVIEW&优化，应用上线，产品、测试数据库服务器维护等，用一句话表达：只要跟数据库相关的工作环节，我们DBA都需要跟进负责，为客户提供一条龙服务，但是我们只有2个DBA，刚开始我们非常痛苦，时间总是不够用。

　　我们之前的工作状态跟现在的工作状态用两根曲线表示，上面的就是以前的工作状态，每天睡几个小时，在公司上班是做这个，在家还是做这个事情，几乎没有空闲的时间。但是经过我们统一架构、规范和标准、使用统一管理系统等，虽然工作面临的压力依然存在，但是矛盾点转化了，以及可以有更多快乐生活的时间。

　　首先我们看一下MySQL的架构，当前使用频率较高的HA架构中，归纳起来无非就两种：一主多备，双MASTER;可能在实际的场景中，围绕这两种架构会有所延伸;比如一主多备中，前面的“主”可能有两个，后面的SLAVE只有一个等;而在双MASTER环境中，后面都是双MASTER，但对应用提供服务的可以是VIP，DNS，还有数据访问层(DAL);这个图上有三种架构，一种是是双MASTER+VIP，两边都可以写。最上面有一个VIP，但VIP可以在两边飘动的，都可以作为服务提供者，后面实现HA，可以是HEARTBEAT，或者RHcluster;还有一种是我们讲到的用DNS+双MASTER来实现HA，也有可能是用其他第三方软件来实现，但原理还是相同的。DNS就是基于第三方的软件，不需要VIP的支持。但在应用与数据库层中间加了一个DNS的服务，对我们来说也是增加了一个故障点;这里虽然写出来了，但我们没有使用。第三个方案，必需有一个数据访问层(DAL)支持，DB层仅是一个双MASTER，应用访问DAL即可，它是不需要VIP无支持的，所以优点是DBA管理轻松，在不增加成本的情况下可以实现异地容灾;但缺点是对应用不透明，应用的SQL需要符合DAL的一些规则 。这么多架构管起来很累，如果你的机器规模到了几百台几千台的时候就顾不过来了，我们人又比较少。所以我们做了内部的统一，我们所有架构的架构就是一种，就是“双MASTER+VIP“，2台主机性能是一模一样的。有了这样的统一以后，我们的管理都可以统一标准化。但是这碰到一个问题，你简单管理必须要面临应用改造的问题，我给大家讲一个例子，我们有一个应用，之前的设计是把所有用户的信息都在一个DB里面，前期由于数据量不大，所以只用了2个SLAVE就能支撑住，由于其所有数据都是活跃的，随着用户量的增长，现在已经是用11个SLAVE支持，基本上所有数据都是活跃的,但我们内存是有限，不能把所有的数据都CACHE进来,在一直的扩容过程中，发现机器越来越多，但性能可能却不是线性增长; 所以我们向开发提出需要把数据改成分布式存储。当我把情况跟应用开发说明后，没想到开发第一句话：没问题。 我说改需要多长时间，对方回答：一个星期左右。这时候我就很无语，心里想，我是不是早该提这个事情，其实开发没那么难驱动。一旦是伪分布式以后，如果我把现在的数据分摊到10个DB的话，QBS达到1万到2万完全不是问题。

　　有了这次推动以后，我们的所有架构都改成了我提倡的那种架构，前面是VIP后面是两个双MASTER。

　　但之前我们用的HA几乎全部是HeartBeat，HB使用的问题是，当MySQL HNAG的时候，是不会切换的，就等人为干涉。另外HeartBeat是资源管理的概念，它的资源只能在一边跑，必须把另外一边的资源DOWN下来以后，才可以起来。当MySQL数据脏数据特别多的时候，资源DOWN下来的时间可能就需要10到20分钟，花10-20来发生切换 ，这是很不值得的。这样的切换如果发生在白天，你还可以人工介入一下，如果是半夜就痛苦了，故障时间急剧增加;HeartBeat使用过程中我还经常碰到时不时把你的MySQL重启一下，这个很痛苦的。另外是脑列，脑列后资源争夺，当两台MASTER断掉以后，这时候B可能是在工作，忽然网络恢复了，这时候A会发现他的积分比较高，就又抢回来，又一次发生了资源争夺，这个对应用也是不允许的。

　　这个就是现在我们用的架构，我们团队自己写了一个AURORA软件，它也是这种架构，前面是VIP，后面是两个MASTER，但它是作为第三方，好像是另外一个裁判，每5秒钟去检测MASTER的状态或者是SLAVE的状态。而且它可以做一个延伸，可以把一台机器，做一对一的复制。可能有人会讲这样数据量比较少，不是很浪费 ? 我们可以用这种多主一备的形式。这样的话我数据量比如说我硬盘的容量有1.6T，前面的数据量50G的话，10个主机只要一台备机就可以了，因为硬件同时坏掉的几率还是比较少的。如果你认为坏掉的几率比较大的话，可以少一点，前面的5台后面的1台。就是所谓的N+1 模式;

　　我们现在都是这种架构，除非是数据量比较大，数据无法让SLAVE承受，所以只能是一对一的。这个AURORA主要的特点就是作为第三方面应用对MySQL可用性检查，专治OSHANG，MySQL无响应。支持多实例HA，N+1扩展。对MySQL免维护，脑列后不会产生资源争夺，脑列只是两个MASTER之间产生脑列，比如网卡坏掉了不提供服务了，但他的备库是可以探测掉的，其实应用也是一样的，也可以探测到我备机是可以用的。还有对应用完全透明的。

　　前面是一个架构的统一以及HA的使用。在这里分享一个案例。我们有一个规定所有MySQL主库白天是绝对不容许维护的，因为我们出现过一个问题，供应商拔错了同一个RAID组的硬盘，大家知道发生了什么事情?文件系统坏掉了，直接导致主库CRASH; 自从这个事情以后我们规定：主库白天不允许维护，备库也是6点以后才可以。 这种情况下，如果主库硬盘坏了怎么办? 之前，我们每天晚上11点以后要做一次切换，大家知道HEARTBEAT都是需要人工介入操作的：切换，关MYSQL，起HEARTBEAT，再起MYSQL;现在我们用了AURORA不需要这样了，晚上只要写一个定时脚本就可以了;自动切换后，主库变成了备库，第二天SA去备机上换硬盘，风险系数降低很多;即使拔错也没关系;

　　这个我们自己有一个统一安装部署程序，它可以支持：统一标准部署，个性化参数自动调整，支持多个实例，自动检查AGENT是否已经安装MYSQL避免数据覆盖等;这个就带过一下。这个是我们剪的一个图，安装完成时候显示的结果，基本上只要制订IP，就是作为一个TXT文件导进去，告诉他1点安装，安装结束就可以看到是这个结果。如果有错误恢报出来给你。由于是并发安装的，基本可以做到安装N台~=安装1台;

　　另外一个是监控，当前由我们公司自主开发的鹰眼监控系统承载所有监控任务;我主要是给大家分享一下我们监控的内容。我们分两快，一个是状态监控，一个是性能监控，性能监控主要是做容量分析的，我们这个监控通知也分多种形式，可以是邮件通知你，短信通知你，还有电话通知你,大家可以看一下监控点，相互补充一下。我们大概关注这些点，跟大家平时维护习惯也没有差异，大家借鉴一下就很好了。NPT，其实蛮重要的，因为特别是当我们的SLAVE复制应用的时候，差异很大的话，会导致数据库数据内容不一致;还有线程数量，这个是检查硬件，我们检查硬件硬盘有没有坏，电池有没有失效。我不知道大家有没有观察这些性能，故障点。当电池失效的时候，写策略就会被改成WRITE_THROUTH，这样磁盘写性能会至少下降20%。 所有日志有错误的话就会发短信给我，我们都有做详细的情况，右边的容量有CPU、idle、user等等。

　　后面是备份管理，刚刚我也说了，最早的时候很土的办法就是mysqldump，结果由于我们的数据量很大，超过500G的DB备份和恢复都需要很长时间，所有的数据一般都需要在第二天下班的时候才备份完，很痛苦。我们团队也自己写了一个备份系统，大概是这样的模式。前面是BACKUP LIST infonmation DB。中间那个是Bak master进行调度的，所有备份集文件就存在这个Bak master里面。Bak master每分钟去数据库取属于自己的调度信息，并发地向AGENT发送消息进行本地备份。这里需要考虑这两个问题： 1 不能在主库上备份，有主备判断 ， 2)本地需要有空间存储备份，如果空间不够，考虑删除BINLOG日志; 当然BINLOG日志不能全部删完;需要备份是有保留策略的，BINLOG一样需要;

　　完成以后Bak master会继续看SLAVE有没有备份完。因为我们每天都有备份结果，完成的时间。第一天的备份完成的时间，比如说凌晨三点钟，那Bak master开始之后只会在三点钟以后检查。这样可以减少他的调用次数。

　　另外一个Bak master有一个并发控制，当所有的备份集文件收集回来的时候，一方面考虑网络的流量，我们不能把网络直接撑满，不然会影响其他的应用;所以我们网络团队要求你网络使用最多不能超过多少兆，所以这里有一个并发的控制。当你同时又多少个备份在进行收集的时候其他的进程只能等待。 收集完备份以后整个备份事务就完成了。

　　另外还有对备份系统进行管理，我的Bak master容量是不是够了，有多少套备份失败了，多少套备份成功的。备份迁移是很简单的事情，只要把OWNER指向改一改就可以了。第二天Bak master自动会去搜索。这个系统解决了我们的大问题。另外我们的备份文件生成后，可能通过主备两个库上的BINLOG日志进行恢复;备份是有效的，而且是可靠的。

　　另外一个就是我们经常干的事情，因为前面我们讲到，我们现在单个Bak master有超过一百台的，也就是说当你之前应用，要加一个表操作的时候，或者是数据的时候，我觉得是很痛苦的事情，就是一个一个敲过来，登到这边做一遍，那边做一遍，有时候还会漏掉。我们就做了一些事情，就是批量发布的平台，就是选择应用，这个应用下面挂了这么多，对哪些操作，就放进去，点一下执行就做完了。但是这个批量操作大家都知道应该是有一个风险的，所以发布有风险，操作需谨慎。而且我们真正操作的时候是非常谨慎的，虽然有这个平台给我们提供，但我做的时候还是谨慎。我先试一个NODE成功以后才会再批量做。虽然是这样子但也节省了我们大量的时间。

　　有了这些辅助管理工具以后，我们日常工作显得轻松了很多;也给了我们自己更我的学习时间;