我的MYSQL是5.0版本的，运行总是会报错，请问如何解决？

1、可能是/opt/mysql-master/data/数据目录mysql用户没有权限(修改数据目录的权限)解决方法 ：给予权限，执行 "chown -R mysql.mysql /opt/mysql-master/data" 然后重新启动mysqld2、可能进程里已经存在mysql进程解决方法：用命令“ps -ef|grep mysqld”查看是否有mysqld进程，如果有使用“kill -9 进程号”杀死，然后重新启动mysqld！3、可能是第二次在机器上安装mysql，有残余数据影响了服务的启动。解决方法：去mysql的二进制日志目录看看，如果存在mysql-binlog.index，就赶快把它删除掉吧4、mysql在启动时没有指定配置文件时会使用/etc/my.cnf配置文件，请打开这个文件查看在[mysqld]下有没有指定数据目录(datadir)。解决方法：请在[mysqld]下设置这一行：datadir = /opt/mysql-master/data5、skip-federated字段问题解决方法：检查一下/etc/my.cnf文件中有没有没被注释掉的skip-federated字段，如果有就立即注释掉吧。6、错误日志目录不存在解决方法：使用“chown” “chmod”命令赋予mysql所有者及权限7、selinux惹的祸，如果是centos系统，默认会开启selinux解决方法：先临时改为警告模式:[root@www php]# setenforce 0然后打开/etc/sysconfig/selinux，把SELINUX=enforcing改为SELINUX=disabled8、可以试着把mysql.cnf默认文件开启，排查是不是配置文件的错误。常见配置错误有：查看配置文件/etc/my.cnf里有没有innodb_buffer_pool_size这个参数innodb_buffer_pool_size：主要作用是缓存innodb表的索引，数据，插入数据时的缓冲；默认值：128M；专用mysql服务器设置此值的大小： 系统内存的70%-80%最佳。如果你的系统内存不大，查看这个参数，把它的值设置小一点吧温馨提示：记得开启mysql错误日志，方便自己排错。vim /etc/my.cnf 各位可以根据自己的my.cnf文件编辑[mysql_safe]log-error = /data/mysql-master/logs/error.log

建议步骤如下：

进入mysql，’执行 show  processlist； ‘，检查哪条SQL所执行的时间过长。

将SQL进行优化。

如第二步还无法解决请检查该SQL涉及的表是否有主键，主键是否有索引。

mysql在配置文件中将tmp_table_size适当增长并重启mysqld。

参考资料：http://www.jb51.net/article/30495.htm

在对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 :)

---