文章目录
今天打开我博客突然再次出现了 database error 的信息……显然 MySQL 服务再次崩坏了。上次崩坏已经尝试过跳大系统栈的方法，这次的崩坏仿佛是另一种错误（吐血……）。
调整系统栈大小
之前服务器的崩坏也是 MySQL 服务停止运行，打开 /var/log/mysqld.log，发现下面一行错误信息：
InnoDB: Error: pthread_create returned 11
去 Google 了一番，看到大部分人都说大概是系统栈大小的问题。（这里有个坑，网上很多人说的执行 ulimit -s unlimited 命令是没有用的！因为 ulimit 这个命令只在当前 shell 会话有效，也就是说当你关闭 SSH 连接的终端，它就会改回去……（不信可以试试））
最后的解决办法是：修改 /etc/security/limits.conf 这个文件。在里面（根据文件内的指导）加上：
* soft stack 28000
* hard stack 32768
这样就能成功、永久调整系统栈大小了～
调整 InnoDB 引擎的缓冲区大小
今天的船新崩坏发生在 2:30 左右（当时我可能还在外面浪……），回来一看博客上不了了。马上去看 MySQL 日志（/var/log/mysqld.log），但是并没有看到明显的 Error 信息，只看到一行行 Note 信息，然后就莫名其妙停住了……
仔细看发现这样一行信息：
2018-07-22 14:35:27 11124 [Note] InnoDB: The log sequence numbers 146002231 and 146002231 in ibdata files do not match the log sequence number 246597872 in the ib_logfiles!
2018-07-22 14:35:27 11124 [Note] InnoDB: Database was not shutdown normally!
2018-07-22 14:35:27 11124 [Note] InnoDB: Starting crash recovery.
2018-07-22 14:35:27 11124 [Note] InnoDB: Reading tablespace information from the .ibd files...
也就是说 MySQL 服务没有正常关闭……上网 Google 了一下，据说是 MySQL 因为占用内存过大（谁让一群小伙伴的网站都放在我服务器上），被系统杀掉了……然后它就频繁自己重启。查看了 kernel 日志（/var/log/messages-20180722）后发现最后有两行：
Jul 19 09:11:40 host kernel: Out of memory: Kill process 25818 (mysqld) score 249 or sacrifice child
Jul 19 09:11:40 host kernel: Killed process 25818 (mysqld) total-vm:912520kB, anon-rss:106360kB, file-rss:1876kB, shmem-rss:0kB
Jul 19 09:11:40 host kernel: oom_reaper: reaped process 25818 (mysqld), now anon-rss:4kB, file-rss:20kB, shmem-rss:0kB
果然是被系统杀掉了……
我采用的解决办法是调整 InnoDB 引擎的缓冲区大小，因为在 appnode 的 MySQL 服务管理中并没有提供调整这个的选项，关于 MySQL 的其他参数都调很小了。首先 vi /etc/my.cnf，根据指导加上：
innodb_buffer_pool_size = 64M
接下来应该 OK 了……（害怕）