今天Kaijia日常（已经算是月常了）从Oracle的官方源更新MySQL之后发现MySQL无法正常启动了，查看了一下/var/log/mysql.log也异常单一。

2019-04-28T02:59:39.881846Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.16) starting as process 384
2019-04-28T02:59:50.800045Z 4 [System] [MY-013381] [Server] Server upgrade from ‘80015’ to ‘80016’ started.
2019-04-28T02:59:52.461014Z 4 [ERROR] [MY-013384] [Server] Could not create server upgrade info file at ‘/var/lib/mysql/’.
2019-04-28T02:59:52.468088Z 0 [ERROR] [MY-013380] [Server] Failed to upgrade server.
2019-04-28T02:59:52.468307Z 0 [ERROR] [MY-010119] [Server] Aborting
2019-04-28T02:59:54.080113Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.16) MySQL Community Server – GPL.

早前Oracle家出错都能打印出一长串错误日志，这次仅仅留下有Could not create server upgrade info file at ‘/var/lib/mysql/’一句。

阅读更多

Kaijia昨天安装新VestaCP服务器后遇到了罕见MySQL无法退出重启的问题。通常情况下执行 service mysql stop 时MySQL会立即停止，在储存语料、数据的MySQL实例上最多也就需要半分钟将缓存写回硬盘后停止，然而Kaijia这台全新安装的MySQL服务器在发送退出命令后始终没有任何响应，直到十分钟后才会由systemctl超时杀死进程。

围观了一下MySQL日志，提示了未能停止的原因是在等待page_cleaner完成清理缓冲池：

2017-10-18T12:36:44.721465Z 0 [Note] InnoDB: Buffer pool(s) dump completed at 171018 20:36:44
2017-10-18T12:37:45.372406Z 0 [Note] InnoDB: Waiting for page_cleaner to finish flushing of buffer pool

阅读更多

添加MySQL过程时间长了，难免会有需要查看过程代码的情况。比如Kaijia有一个过程自动清理数据库中大于指定时间的分区，这次Kaijia把这个指定的时间忘了，于是想通过查看过程的代码找回这个设定的时间。

根据MySQL文档，可以使用“SHOW PROCEDURE CODE”语法查看过程和自定义函数的代码，但Kaijia在执行此语法时却遇到了以下错误：

mysql> SHOW PROCEDURE CODE Kaijia的过程;
ERROR 1289 (HY000): The ‘SHOW PROCEDURE|FUNCTION CODE’ feature is disabled; you need MySQL built with ‘–with-debug’ to have it working

阅读此语法的文档Kaijia找到了相关提示：此扩展仅在编译时开启了调试模式的服务器中可用（This statement is a MySQL extension that is available only for servers that have been built with debugging support.）。而考虑到除了MySQL开发外，一般情况下使用的由软件包管理器（YUM和APT-GET）提供的MySQL预编译版均没有开启编译模式，这条命令对广大开发者和系统管理员来说基本上是没法用的……

阅读更多

写这篇文章的原因出自Kaijia一次被Stack Overflow坑的经历，回头看来虽然Stack Exchange的Peer Review机制很好，但是错误照样还是很多的，以及Kaijia提交了Edit被Peer Review拒绝了……

之前某个插件神不知鬼不觉地删除了所有WordPress数据表的主键和自增，导致系统出现异常，如果手动恢复的话要处理近30余张主键规则不同的表非常麻烦，于是Kaijia决定采用数据恢复的方式，即先将现有数据导出并删除表，再导入数据库备份重建表结构，再将现有数据导入。这样一来数据是现有的数据，表结构是损坏前的正确结构完成修复。

按照这个步骤下去，第二步是导入备份，但是Kaijia的数据库备份是全数据库整盘备份，单个SQL文件里面包含了所有数据库的数据，而本次恢复涉及单个数据库，不能影响其他数据库。之前没有类似经验无从下手，于是Kaijia搜索了下找到了此篇Stack Overflow问题《Can I restore a single table from a full mysql mysqldump file?》，高票回答是使用sed命令（完全正确），但是显然没有后面的正面回答（后来证实是坑）方便。后面回答的要旨非常简单：

在mysql命令最后加上指定的数据库名便可以了！这不科学！但鉴于此答案有还有人点赞，还有人评论“This is what most people need.”于是Kaijia就尝试了……结果果真其他的数据库都被还原了，当然幸亏操作前Kaijia给服务器快照了一下，直接恢复了。

阅读更多