我有一个MySQL服务器（V5.6）在Ubuntu服务器10 x64上运行。 它总是运行在一个中等stream量，但每当它崩溃并重新启动，而不提出任何日志消息，重新启动后，它开始崩溃恢复，通常需要大约10分钟＆mysql error.log文件重置，它看起来像下面：
2017-07-27 10:07:37 23427 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead. 2017-07-27 10:07:37 23427 [Note] Plugin 'FEDERATED' is disabled. 2017-07-27 10:07:37 23427 [Note] InnoDB: Using atomics to ref count buffer pool pages 2017-07-27 10:07:37 23427 [Note] InnoDB: The InnoDB memory heap is disabled 2017-07-27 10:07:37 23427 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2017-07-27 10:07:37 23427 [Note] InnoDB: Memory barrier is not used 2017-07-27 10:07:37 23427 [Note] InnoDB: Compressed tables use zlib 1.2.8 2017-07-27 10:07:37 23427 [Note] InnoDB: Using Linux native AIO 2017-07-27 10:07:37 23427 [Note] InnoDB: Not using CPU crc32 instructions 2017-07-27 10:07:37 23427 [Note] InnoDB: Initializing buffer pool, size = 5.0G 2017-07-27 10:07:38 23427 [Note] InnoDB: Completed initialization of buffer pool 2017-07-27 10:07:38 23427 [Note] InnoDB: Highest supported file format is Barracuda. 2017-07-27 10:07:38 23427 [Note] InnoDB: Log scan progressed past the checkpoint lsn 194934547118 2017-07-27 10:07:38 23427 [Note] InnoDB: Database was not shutdown normally! 2017-07-27 10:07:38 23427 [Note] InnoDB: Starting crash recovery. 2017-07-27 10:07:38 23427 [Note] InnoDB: Reading tablespace information from the .ibd files...
有什么我可以做，以保存日志显示崩溃的来源，所以我可以解决这个问题。
MySQL服务器有时可能成为Linux内存不足（OOM） 杀手级进程的牺牲品。 您可以在/var/log/syslog或dmesg命令的输出中find此类活动的痕迹。
如果系统内存不足，杀死MySQL，可以调整MySQL服务器进程的设置以避免这种情况。 例如，使用MySQLTuner-perl脚本。 其输出中的性能指标显示MySQL服务器进程的最大可能内存使用情况，以已安装的RAM的百分比表示。
回答你的问题，有什么我可以做的，以保存日志显示崩溃的来源，所以我将能够解决这个问题。
是的，在[mysqld]部分的.cnf文件中，添加一行 – expire_logs_days = 7＃，默认情况下为0 mm / dd / ccyy xx您将有7天的时间用于研究， 浏览你的目录，你发现error.log看到他们。