Building the Coming Soon

关于

HFLS aka the Akademia 12′, then NUST 16′, HKU 18′, now a Blue.

MySQL

MySQL 8.0.15向8.0.16升级启动失败问题解决

04/28/2019

今天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/’一句。

阅读更多

MySQL时间跳跃无法停止问题解决

10/19/2017

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过程代码

10/20/2015

添加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开发外,一般情况下使用的由软件包管理器(YUMAPT-GET)提供的MySQL预编译版均没有开启编译模式,这条命令对广大开发者和系统管理员来说基本上是没法用的……

阅读更多

WordPress管理员权限“提请审批”无法发布文章问题解决方法

09/07/2015

之前Kaijia一个WordPress站点安装了一个神一般的插件(具体造成错误的代码怎是没空找就不点名了……)后突然之间所有的帐号均无法发布文章了,并且自动保存等功能也不可用。即使Kaijia使用管理员帐号登录发布文章仍然显示“提请审批”,并且无法显示状态、公开度信息,点击“提请审批”之后会弹出错误提示页面不存在。其他的功能,例如下载等,也无法添加。

正常情况编辑文章右栏(左侧)和Kaijia遇到的异常情况(右侧)比较

正常情况编辑文章右栏(左侧)和Kaijia遇到的异常情况(右侧)比较

Kaijia很快排除了权限系统出错的可能性,因为Kaijia登录的是管理员帐号,管理员权限与权限系统平行,始终获得所有权限,使用诸如User Role Editor等插件调整权限系统均不会管理员权限造成影响。

阅读更多

MySQL命令行操作限定单个数据库方法

09/06/2015

写这篇文章的原因出自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给服务器快照了一下,直接恢复了。

阅读更多

Ubuntu系统使用备份恢复已损坏MySQL数据库

11/18/2014

数据库损害的情况经常发生,尤其是OpenVZ VPS,当物理服务器非正常关机,而是断电或者直接崩溃时,MySQL数据库损坏几乎是不可避免的,尤其是数据库量比较大的时候。Kaijia已经遇到过数次数据库损坏的情况,一般情况下MySQL的调试日志里面会直接给出修复提示,比如在my.cnf中增加:

关闭异步I/O操作等,此类操作一般能恢复数据库的正常使用。但这次Kaijia遇到了一次由于物理服务器宕机造成的MySQL数据库损坏,并且错误信息也没有给出任何修复提示,此时应该按照MySQL文档中给出的步骤恢复InnoDB,这个过程相对比较复杂,并且考虑到损害的数据库并不大,也不常用,并且每小时都有备份,于是Kaijia决定直接通过还原备份恢复已损坏MySQL数据库文件。

阅读更多

Ubuntu 14.04系统VestaCP面板MySQL无法正常运行问题解决

11/14/2014

VestaCP是一款新兴的虚拟主机面板,它以LAMP为核心(也支持Python程序),使用Nginx做前端,同时还支持FTP、邮件和DNS服务器功能,整体功能非常简洁强大,更重要的是,它的界面设计符合潮流。

Kaijia最近也开始学习使用VestaCP并将一台运行Virtualmin的服务器搬到了VestaCP平台下,在这一过程中Kaijia遇到了很多问题。由于VestaCP一开始设计只考虑了RedHat/CentOS,Debian/Ubuntu的支持相对比较欠缺,尤其是Ubuntu 14.04相较其他几个版本变化很大(PHP 5.5和Apache 2.4了,而VestaCP支持的其他发行版基本都在PHP 5.3和Apache 2.2,另外还有upstart/systemd等问题),相应单一发行版的Bug也特别多。在今后的文章中Kaijia将会不定期分享在Ubuntu 14.04系统下使用VestaCP面板遇到的问题和解决经验。

比如这次遇到的问题经过分析也应该是Ubuntu 14.04系统特有的。Kaijia一开始完成VestaCP安装后系统可以正常运行并没有发现任何错误,但是重启服务器之后却出现了MySQL无法使用的问题,无法通过VestaCP面板创建数据库,同时站点也无法连接到数据库。查看MySQL的错误日志可以看到提示InnoDB文件已被锁定:

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

阅读更多

使用Zabbix监控MySQL服务器方法

01/27/2014

从Zabbix 2.2开始,Zabbix官方已经支持了MySQL监控,但是MySQL监控默认是不可用的,需要经过额外的设置才可以使用。Kaijia将Zabbix换到了新的服务器时候性能绰绰有余,于是决定充分发挥剩余的内存和SSD性能,把MySQL、Apache、PHP-FPM等的监控也开起来。

Google了一下后找到了一篇《How to Monitor MySQL using the new Zabbix Template App MySQL》,大部分内容都可用,可惜这位老兄最后的步骤写错了。。。于是参照此篇文章Kaijia整理了一下使用Zabbix监控MySQL服务器的方法。

阅读更多

... 载入更多文章 ...

- 已经载入全部文章 -