Zstack采坑记录（记一次数据库异常）

   提起今天的异常，有不少的吐槽的地方，不提历史遗留的坑，单纯的从技术方面回顾一下今天踩得坑，异常描述，内部自动化系统对接了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，

解决和排查步骤

一、按照以往的套路先重启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台机器上面的zstack 重启后发现启动不了，查看数据库的链接发现数据库没有链接，再次回到当时重启失败的那台，检查详细的报错，发现有存储空间不足的异常，df执行了一把  还剩80%的空间，又想起今天某傻叉开发干的rm日志磁盘空间不释放的问题， 执行了一把lsof |grep delete ，结果看的我奔溃。。。。

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