转载

孔德亮：大规模集群运维经验（二）

本文基于360私有云-HULK云平台技术积累，在过去几年中我们从百十台服务器，几个机房，发展到数万台服务器，几十个机房。今天以最基本、最通用的LNMP架构阐述前端WEB服务和后端数据库服务，这“一前一后”在异地多活、集群管理等方面的实践经验，前端WEB服务经验请翻阅前一篇 http://os.51cto.com/art/201506/479450.htm 。

今天着重介绍一下后端数据库MySQL的相关运维经验，在前不久WOT移动开发者大会上我也提到，故障总会发生，只是时间问题，单一的故障很难造成毁灭性的打击，多种问题组合起来才会让我们束手无策，做好监控、事故预案、应急演练才能减少故障的发生率。

后端数据库服务高可用

为了解决单机故障、单机房故障，我们的DBA经过不断的积累更迭，确立了适合360的数据库架构：

孔德亮：大规模集群运维经验（二）

下面我们剖析一下，这个架构是如何解决我们现实的问题。

1、机器故障：

机器故障就跟天要下雨一样，我们无法控制，但我们必须做的就是当机器故障后我们能很快的进行故障转移，如下为机器故障的几种场景：

1）从库故障：这种情况特别好处理，atlas会探测从库是否异常，如果异常，会进行标记下线，这样，从库故障就不影响正常业务了。在从库下线这里有一个技术点，当从库延时，我们怎么办呢？这就是图中监控所做的事情了，当监控发现从库延时超过10s，它会给atlas发送SET OFFLINE $backend_id 指令，强制从库下线，这样确保业务不读取到延时太大的从库了。

2）主库故障：该情况应该属于比较复杂情况，业内也有很多技术方案，而这里，我们选用的是mysql5.6 Gtid+mysqlfailover+Atlas，mysqlfailover是一个监控daemon，它实时监控着mysql集群，尤其是mysql主库的存活状态，在探测中，一旦发现主库异常，它会利用mysql5.6 gtid快速搭建主从关系的便利性，快速进行其中的一个从库到主库升级，升级过程中包括几个技术点：

⑴选择ping值最少，延时不超过60s的从库作为主库;
⑵新主库串行的依次从其它从库上同步数据;
⑶当同步完毕后，新主库的数据将是最新的，然后mysqlfailover会把其他从库与新主库建立同步关系,确保整个集群不存在数据不一致以及数据丢失的情况。

至此，mysql主从结构调整完毕，mysqlfailover会通过REMOVE BACKEND 老主库以及ADD MASTER新主库，更换Atlas配置，到此，主库故障自动化完成，保证业务正常运行；

3）Atlas故障：该情况比较简单，如果出现一台atlas故障，lvs 会自动下线失效的atlas，保证业务正常运行；

2、某机房故障：

1）网络故障：

设计再牛逼，我们也坚信只需要一铲子，就能引发较大面积的网络故障，对于这样的情况，我们该怎么办呢？我把它分为如下几类：

⑴机房出口网络故障：

B机房故障：如果B机房出口网络故障，由于数据库是纯内网环境，所以，数据库、atlas运行状态一切正常，故数据库不需要做任何调整，只需要通过前端切换预案，摘除B机房的前端业务流量即可，把流量压入A机房，保证业务正常运行；

A机房故障：同上，只需要前端调整流量入口即可；

⑵机房内部网络故障

B机房故障：如果B机房内部网络出现异常，这个时候，我们通过WEB集群预案摘除B机房的业务流量即可，把流量压入A机房，保证业务正常运行；

A机房故障：除了通过WEB集群预案摘除A机房流量，把流量全部压入B机房外，我们还需要做一些其他操作，从上面图中能看出，这个时候其实比较杯具，因为我们唯一的一个主库与failover都出现异常了，已经没有办法做到自动切换了，所以，我们需要通过Hulk的故障转移模块，办自动化的进行主库切换到B机房，确保业务的正常运行;

⑶机房之间光纤异常：

如果光纤中断，B机房的从库出现延时，这种情况，为了让处理流程更简单，我们依然采用WEB集群切断B机房流量，把流量放入放入A机房，确保业务的正常运行;

2）内部长时间故障，如：机房断电、地震、地灾等，这种情况，我们可以按照机房网络出口故障场景处理。

再好的架构也不可能万无一失，完善的备份体系是我们的救命稻草，接下来介绍一下我们的自动化备份恢复系统

正文到此结束