MySQL 常见错误

连不上mysql时一般有以下四种报错

  1. Can't connect to MySQL server
  2. Lost connection to MySQL server
  3. Sorry, due to line fault, temporarily unable to browse, we are dealing with.
  4. MySQL server has gone away

一:Can't connect to MySQL server 可能的原因:

  1. mysql服务端没有启起来
  2. 网络不通(iptables,selinux,网络不稳定)

对应的解决方案:
1. dba 先确定 mysql 服务是否正常
2. mysql服务正常的情况下找运维确认网络问题

二: Lost connection to MySQL server 有四种情况可能会导致这样的报错:

  1. 网络问题
  2. 查询的结果集太大,比如一个查询要返回几百万个结果
  3. 客户端发起数据库连接的时候由于 connect_timeout 设置时间太短而报错,如果是由于这个原因引起的报错可以通过 SHOW GLOBAL STATUS LIKE 'Aborted_connects' 查看这个值是否有增加
  4. 查询有 blob 类型,超过了 max_allowed_packet 参数的限制

这四种情况对应的解决方案:
1. 运维监控网络是否有问题
2. 将 net_read_timeout 值调大
3. 将 connect_timeout 值调大
4. 将 max_allowed_packet 值调大

三: Sorry, due to line fault, temporarily unable to browse, we are dealing with. 这个错误不是 mysql 原生的错误,在网上也没有找到有类似的资料.目前发现有三种情况会有这种报错:

  1. 网络有问题
  2. 数据库连接数过多
  3. 连数据库的帐号密码有误

四: MySQL server has gone away 有以下 12 种情况可能会导致这样的报错:

  1. 默认的 wait_timeout 值为8个小时,如果空闲连接超过这个值会被 kill
  2. dba 手动 kill
  3. 客户端的帐号没有权限连接 mysql server
  4. 客户端TCP/IP连接超时,如使用mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...)或者mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...)函数
  5. 当客户端禁用了自动重连接( automatic reconnection)
  6. 查询语句不正确
  7. 查询语句太长,超过了 max_allowed_packet 的限制
  8. 一条 insert 或者 replace 语句更新的行数过多
  9. 域名解析失败
  10. 防火墙屏蔽了 3306 端口
  11. 一个线程 fork 了多个子进程,当多个子进程共用一个连接时会导致报错
  12. mysql 服务端挂了

报 MySQL server has gone away 的错误原因比较多,我们可以从三个方面来应对这个问题:

  1. 运维

a,确认防火墙规则
b,dns服务器无异常
d,合理配置php.ini中连接mysql的参数
connect_timeout,默认为60s
mysqli.reconnect,默认为off

  1. DBA

a,确定mysql服务和连接数无异常
b,设置合理的wait_timeout值
c,设置在服务器端合理的max_allowed_packet值
d,确认帐号权限无误

  1. 开发

a,建议使用 pdo 替代 mysql
b,尽量少用长连接
c,mysqli.ping()可以在连接断开后自动重连, mysql.ping() 从 mysql5.0.3 后就不支持自动重连了
d,子进程之间不要共用一个数据库连接

查看一下 max_allowed_packet 和超时有关的参数:

show variables like 'max_allowed_packet';

| Variable_name | Value |
| max_allowed_packet | 1073741824 |

show variables like '%timeout%';

| Variable_name | Value |
| connect_timeout | 60 |
| delayed_insert_timeout | 300 |
| have_statement_timeout | YES |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 120 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 86400 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 120 |
| net_write_timeout | 120 |
| rpl_stop_slave_timeout | 31536000 |
| slave_net_timeout | 3600 |
| thread_pool_idle_timeout | 60 |
| wait_timeout | 86400 |

来看一下这几个与连不上数据库相关的超时参数:
connect_timeout:在获取链接时,等待握手的超时时间,一般默认即可(10s),为了避免因为网络不佳导致连接拥塞可以适当增大这个值.线上配置为60s
wait_timeout/interactive_timeout:连接状态持续为sleep的超时时间,默认为28800(8小时),现上调整到了24小时
net_read_timeout:服务器端等待客户端发送数据的超时时间,默认60s,线上为120s
net_write_timeout:服务器端写数据到客户端的超时时间,默认60s,线上为120s
再看一下max_allowed_packet参数:max_allowed_packet的默认值是1M(1048576),最大值是1G(1073741824),我们目前线上的值已经是上限值了.
从上面的配置可以看到这些参数的设置相对来说都很大了,数据库正常情况下程序报连不上数据库应该和数据库本身的参数配置没有关系.我们需要从其它方向来解决这个问题.

打赏作者

您将是第一位评论人!

提醒
avatar