云平台数据库主机意外宕机问题

一：问题:生产环境DB主机主节点在19号中午突然宕机，导致公司某业务中断。

二：问题解决：

    生产以第一时间恢复业务为准则，所以来不及细查原因

    1.用horizon和cli两种方式启动云主机均失败,主机状态为ERROR，此状态只可执行删除操作

    2.卸载云主机云盘失败，云主机在此刻是无法卸载云盘的，所以删掉原来的云主机，云盘重新回到available状态

    3.cli下加载admin环境变量nova reset-state --active backend-mysql-01，状态重置后制作快照，执行（此时是无法rebuild的，只能以从快照新建主机，指定固定ip）

nova boot prod-zabbix02-mysql01 --flavor  c1.medium --image 7388c74b-bf8f-4b64-911e-40f838840602  --security_group zabbix-sec-group  --nic net-id=bcb3cef7-da93-450c-9f2f-83279d24e9a4,v4-fixed-ip=172.30.0.21

    4.重新挂载云盘

    5.db组启服务ok

三：天空飞来一封邮件（下列内容来自数据库总监邮件，邮件发送时，故障已经解决）:

    近期生产环境DB服务器连续多次出现突发宕机，从服务器/var/log/message中没有任何相关信息，从监控来看，故障时段数据库负载很低，希望云计算部能从虚拟机层面分析一下原因。

9月19日 20:30左右 Zabbix系统   数据库突然宕机 172.30.0.21  prod-zabbix02-mysql01  

9月19日 12:00左右 后台管理项目 数据库突然宕机 172.40.0.34  backend-mysql-01   MySQL节点01  

9月3日 21:20左右  后台管理项目 数据库突然宕机 172.40.0.36 backend-mysql-03  MySQL节点03   

    另外，以前虚拟机的故障后一般能很快重新启动，但这几次虚拟机都无法启动，导致故障恢复时间较长。

四：被迫分析原因（刚开始其实我是拒绝的，我良辰谁都不服，直到副总也发来贺电）

针对昨天prod环境backend-mysql-01意外宕机原因分析如下

backend-mysql-01运行与compute03节点，compute03节点报错日志        

出现该问题的原因是由于VM分配的内存过大（甚至超过的物理主机的内存大小），backend-mysql-01使用m2.xlarge,内存为32G

而compute03物理内存剩余为10G，所以一旦数据库负载过高导致内存使用量大则会产生宕机现象，重启由于compute03物理内存不足，是无法重启成功的

补充一点：

云主机在新建时内存的分配都是超分的，比例为ram_allocation_ratio=1.5（这是默认配置）

这样，如果物理节点剩余内存为10G，那么在该物理节点上可以新建15G内存的云主机。

这在资源充足的情况下是一种优化策略（每个主机实际都无法用到100%内存，内存超配后，意味着我们可以新建更多的云主机）,但是针对db这种对内存需求极高的应用来说，该配置就成了一种导致云主机宕机且无法重新启动的导火索（内存溢出）。

五：三种解决方案

解决方案一：

新增compute节点（内存配置高），单独划分主机集合供db部门使用，超分设置ram_allocation_ratio=1.0

解决方案二：

升级计算节点内存

解决方案三：

1.统计生产环境资源，筛选资源充足主机

2.新增主机集合，将现有的资源充足的主机纳入该集合内，以后新建主机使用该主机集合去创建

三种方案对比（本着db应用与其他应用分开，db应用运行与单独的物理节点的原则）：

方案一：最优，无须停节点，数据库应用对性能的独特要求决定了：它应该与其他应用处于不同的物理节点。所以需要单独分配高性能物理机

方案二：较优，需要停节点升级内存，但是也是一种解决问题的方法

方案三：最烂，可以解决短期内的问题，仍然没有将db应用于其他应用分离

本文出自 “一个好人” 博客，请务必保留此出处http://egon09.blog.51cto.com/9161406/1854592

云平台数据库主机意外宕机问题

标签：