记一次服务器和数据库重启

一周前数据库奔溃了，周一我介入了

现象

雾里看花

听说是服务器最近频繁重启，导致数据库有问题，不过我发现数据库自己也会重启，问负责人目前日志是什么样的，定位到哪里，做了什么操作，一问三不知，有没有文档记录过程，也没有，所以打算重新查看日志

环境

先说下这个奇怪的环境配置，用的是windows server 2012，配的mysql8.0 。日志时区是错的，数据库配置文件也不对，总而言之，这是比我还草台班子的人搭建管理的数据库。

windows 系统日志

查看系统日志有两种方法

1. windows左下角/右键/事件查看器，点击到系统事件，可以筛选只要错误、告警和关键的事件。然后一个个查看
   
2. 查看文件，可以通过上面某个日志的路径找到文件路径

定位发现，这台服务器一直在异常关闭重启，特别是5月到6月，三天两头重启，曾经高峰期一天重启了3次，而则都发生在这次事故之前。也就是说问题一直存在，只是影响到了数据库，所以被人发现了。因为他们没看日志，所以以为那次导致数据库的重启是第一次，后面每次操作都重启是重启现象变严重了。
这充分说明了看日志的重要性。但事故发生1个多星期，却没有人去仔细分析日志，这就很诡异了。

https://learn.microsoft.com/en-us/windows-hardware/drivers/de...
回到正题，dump文件里会有一些解决意见，会有错误码，比如0x00000050、0x00000139、0x0000011d、0x00000133。可以解析dump文件，自己看，或者让别人帮忙定位。剩下的是体力活，需要根据报错信息一个个排查

mysql

mysql定位的时候我犯了一个严重的错误，只看了当前的错误，想解决当前错误，实际真正的问题在于错误发生的那一刻，而错误发生的那一两天，mysql疯狂写错误日志，写了15个G，负责人还骚操作的删掉了之前的错误日志和binlog，我不知道用什么语言形容这种骚操作。应该还有很多我不知道的骚操作，这些是有确切证据发现的。

总结

发生问题是可怕的，但这不是最可怕的，最可怕的是发生问题后的骚操作。以及操作完一问三不知，也不去看日志定位问题。

享受定位的过程，让结果随缘，关键是从中学到了什么，下一次应该怎么做。这篇文章没有展开mysql详细报错，主要是其实我无法判断这些报错的真实性，①日志缺失②有的那部分日志对不上服务器重启时间（自己换算时区后）③不确定这些报错是怎么产生的，是不是骚操作产生的④负责人不知道做了什么，一问三不知