分类： Mysql/postgreSQL
2015-02-05 13:55:54
我们目前有300台左右MySQL数据库服务器,单机容量最大达到1.4T，平均数据量400G左右，应用数量30多个，单一应用最大数据库集群服务器有100多台。
我们工作内容大致是：应用KICK OFF(kickoff phase 项目立项阶段)，设计评估，SQLREVIEW&优化，应用上线，产品、测试数据库服务器维护等，
用一句话表达：只要跟数据库相关的工作环节，我们DBA都需要跟进负责，为客户提供一条龙服务，但是我们只有2个DBA，刚开始我们非常痛苦，时间总是不够用。
我们之前的工作状态跟现在的工作状态用两根曲线表示，上面的就是以前的工作状态，每天睡几个小时，在公司上班是做这个，在家还是做这个事情，
几乎没有空闲的时间。但是经过我们统一架构、规范和标准、使用统一管理系统等，虽然工作面临的压力依然存在，但是矛盾点转化了，以及可以有更多快乐生活的时间。
首先我们看一下MySQL的架构，当前使用频率较高的HA架构中，归纳起来无非就两种：(1)一主多备，(2)双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的话，QPS达到1万到2万完全不是问题 (ONESQL都可以达到10万 QPS 一般数据库也可以达到几万QPS)。
有了这次推动以后，我们的所有架构都改成了我提倡的那种架构，前面是VIP后面是两个双MASTER。
但之前我们用的HA几乎全部是HeartBeat，HB使用的问题是，当MySQL hang的时候，是不会切换的，就等于人为干涉。另外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（和write_back（使用高速缓存） 阿里巴巴用的write_back），这样磁盘写性能会至少下降20%。write policy写入策略 .
所有日志有错误的话就会发短信给我，我们都有做详细的情况，右边的容量有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成功以后才会再批量做。虽然是这样子但也节省了我们大量的时间。
有了这些辅助管理工具以后，我们日常工作显得轻松了很多;也给了我们自己更多的学习时间。
总结：
DBA做的工作：应用KICK OFF(kickoff phase 项目立项阶段)，设计评估，SQL review&优化，应用上线，产品、测试数据库服务器维护
三种HA架构：VIP，DNS，还有数据访问层(DAL);
高可用：N+1 模式
规定：规定所有MySQL主库白天是绝对不容许维护的，主库白天不允许维护，备库也是6点以后才可以
主备切换：晚上只要写一个定时脚本就可以了;自动切换后，主库变成了备库，第二天SA去备机上换硬盘，风险系数降低很多;即使拔错也没关系;
部署：统一安装部署程序
监控：一个是状态监控，一个是性能监控
还原：通过主或备两个库上的BINLOG日志进行恢复;证明备份是有效的，而且是可靠的。
Write Policy写入策略：Write Back
