连不上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
2,DBA
a,确定mysql服务和连接数无异常
b,设置合理的wait_timeout值
c,设置在服务器端合理的max_allowed_packet值
d,确认帐号权限无误
3,开发
a,建议使用mysqli替代mysql
b,尽量少用长连接
c,mysqli.ping()可以在连接断开后自动重连,mysql.ping()从mysql5.0.3后就不支持自动重连了
d,子进程之间不要共用一个数据库连接
以gamiss为例,我们来看一下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),我们目前线上的值已经是上限值了.
从上面的配置可以看到这些参数的设置相对来说都很大了,数据库正常情况下程序报连不上数据库应该和数据库本身的参数配置没有关系.我们需要从其它方向来解决这个问题.