提起今天的异常,有很多的吐槽的地方,不提历史遗留的坑,单纯的从技术方面回顾一下今天踩得坑,异常描述,内部自动化系统对接了zstack,创建虚拟机失败,负责调度系统的同学查了很久都没搞定,只贴了一些异常日志。初步怀疑是zstack的锅,登录控制节点排查

{'createdDate': 'Jul 8, 2019 4:03:02 PM', 'state': 'Done', 'uuid': '71031d41519945339c0c8078c52e961f', 'result': {'org.zstack.header.vm.APICreateVmInstanceEvent': 
{'success': False, 'error': {'description': 'An internal error happened in system', 'details': 'org.hibernate.exception.SQLGrammarException: could not execute statement; 
nested exception is javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not execute statement', 'code': 'SYS.1000'}}}, 'finishedDate': 'Jul 8, 2019 4:03:02 PM'}", 
'success': False, 'data': {}}]

三台管理节点,其中两台机器部署了数据库节点,为主从架构,是我们将zstack默认的MariaDB数据库做了轻微的改造,将数据迁移到了MySQL,

解决和排查步骤

1、按照以往的套路先重启zstack的管理节点,重启数据库所在的那台机器时zstack节点时发现有python相关的报错,当时先忽略去处理了其他2台

org.hibernate.exception.SQLGrammarException: could not execute statement;
 nested exception is javax.persistence.PersistenceException: org.hibernate.exception.SQLGrammarException: could not execute statement

2、重启了其他2台机器上面的zstack 重启后发现启动不了,查看数据库的连接发现数据库没有连接,再次回到当时重启失败的那台,检查详细的报错,发现有存储空间不足的异常,df执行了一把  还剩80%的空间,又想起今天某傻叉开发干的rm日志磁盘空间不释放的问题, 执行了一把lsof |grep delete ,结果看的我奔溃。。。。

Zstack采坑记录(记一次数据库异常)_第1张图片

    若干MySQL相关的临时文件被删除了,终于知道啦问题出哪里了,这是MySQL异常了,先重启一把MySQL吧  。重启完  再重启Zstack 发现服务重启成功,创建虚拟机测试。