操作系统:CentOS 6.2
成都网站建设哪家好,找成都创新互联!专注于网页设计、网站建设公司、微信开发、小程序开发、集团成都企业网站定制等服务项目。核心团队均拥有互联网行业多年经验,服务众多知名企业客户;涵盖的客户类型包括:水电改造等众多领域,积累了大量丰富的经验,同时也获得了客户的一致称誉!
现象:MySQL无法启动
查找问题发现:存放mysql数据分区100%
[root@jinniu-test3 mysql]# df -h
文件系统 容量 已用 可用 已用%% 挂载点
/dev/sda2 49G 49G 20K 100% /
tmpfs 933M 0 933M 0% /dev/shm
/dev/sda1 194M 31M 153M 17% /boot
/dev/sda5 219G 701M 207G 1% /opt
检查/etc/my.cnf,数据文件默认存放于/var/lib/mysql下
确认此文件夹确实过大
解决方案:转移存放目录,修改my.cnf或者软连接回来
[root@-_- ~]# cp -Rp /var/lib/mysql /opt/ --带权限拷贝整个目录
修改/etc/my.cnf配置datadir=/opt/mysql指向新位置
重启mysql发现无法启动
[root@-_- ~]# service mysqld start
MySQL Daemon failed to start.
正在启动 mysqld: [失败]
检查/var/log/mysqld.log文件最后
[root@-_- ~]# tail -20 /var/log/mysqld.log
...
130301 11:52:05 [Warning] Can't create test file /opt/mysql/-_-.lower-test
130301 11:52:05 [Warning] Can't create test file /opt/mysql/-_-.lower-test
...
网络搜索问题得知是这台机器启用SElinux 安全策略引起的
使用命令可以解决
[root@-_- ~]# chcon -R -t mysqld_db_t /opt/mysql
实在不行,禁用SElinux
执行:setenforce 0
在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中,有一个环节是人为制造磁盘满的场景,看看MGR是否还能正常响应请求。
在实测过程中,最后发现磁盘满的那个节点,持续时间足够久后,会因为内存消耗过大而最终被OS给OOM Kill。
这个问题我已报告BUG(#104979),下面是该过程的详细记录。
首先,直接利用dd复制空文件填满磁盘。
disk full报告过程及何时被oom killed
来看下MySQL 8.0.26遇到disk full时日志都输出哪些内容:
从disk full时刻开始,大约过了2.5小时,mysqld进程内存消耗持续上升,最终引发oom kill
在这期间某个时刻抓到的待认证事务堆积,在被oom kill前实际不止这么多:
关注mysqld进程内存消耗变化
下面是mysqld进程内存消耗变化情况
OS层oom-killer相关日志:
GreatSQL 8.0.25测试过程
作为对比,我用GreatSQL 8.0.25也做了同样的测试。
从日志详情中可以看到,当磁盘空间满了之后,GreatSQL会将那个节点主动退出集群,对整个集群的影响非常小。
此外,从集群退出后,也不会再接收认证事务了,所以也没发生内存持续暴涨最终被oom killed的情况,实际观察过程中发现内存反倒还下降了
这样对比来看,GreatSQL的可靠性还真是可以的,官方的MySQL MGR的可靠性还有待进一步加强呀。
Enjoy GreatSQL :)
可以通过查看mysql进程来实现。 进入mysql命令行客户端,选择数据库后,执行show processlist命令: 多刷新几次,可以看到最后执行的SQL语句,以此判断什么查询在占用资源。
售后响应及时
7×24小时客服热线数据备份
更安全、更高效、更稳定价格公道精准
项目经理精准报价不弄虚作假合作无风险
重合同讲信誉,无效全额退款