This is weird. I have 2 centos boxes, prod (192.168.0.1) and vm (192.168.0.30). Mysql database sits on prod. App sits on vm. From vm, if I type
mysql -u user -p -h 192.168.0.1 -D mydb
it connects lovely, so port is open and listening on prod but in app, i do
$db=new mysqli('192.168.0.1','user','mypass','mydb');
and I get
Warning: mysqli::mysqli() [function.mysqli-mysqli]: (HY000/2003): Can't connect to
MySQL server on '192.168.0.1' (13) in /var/www/vhosts/myapp/httpdocs/dstest.php
on line 123
Both boxes have exactly same versions php, mysql, mysql.so, mysqli.so
Any advice?
P.S. This also happens if I try $db=new mysqli('127.0.0.1',... BUT NOT if I try $db=new mysqli('localhost',...
in case it helps, here is my.cnf on prod:
[mysqld]
set-variable=local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
max_connections = 500
max_user_connections = 150
key_buffer = 2048M
query_cache_limit=4M
query_cache_size=64M
table_cache=2048
tmp_table_size=64M
max_heap_table_size = 256M
# users buffers
sort_buffer_size=2M
read_buffer_size=2M
read_rnd_buffer_size=1M
max_allowed_packet=16M
thread_cache=16
thread_concurrency=8
thread_cache_size=128
innodb_buffer_pool_size = 128M
myisam_sort_buffer_size = 128M
wait_timeout = 240
interactive_timeout = 240
max_allowed_packet=32M
[mysql.server]
user=mysql
basedir=/var/lib
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Check here. It looks very similar to your issue.
Edit: added blog content for posterity:
SQLSTATE[HY000] [2003] Can’t connect to MySQL server on ‘xxx.xxx.xxx.xxx’ (13)
One of the things I wish I had found in Google faster when trying to figure out why PHP script refuses to connect to remote MySQL server issuing an error SQLSTATE[HY000][2003]Can't connect to MySQL server on 'xxx.xxxx.xxx.xxx' (13)
I am able to connect from local shell, so first thought was if something wrong with recent Zend Framework upgrade, but after a while I figured out that answer is very simple – SELinux was blocking remote connections from PHP scripts executed by Apache web server. The error code (13) at the end of error message means “permission denied”, so that’s the indication to see if you have similar issue or not.
Anyway, login as root and do
setsebool -P httpd_can_network_connect=1
to make it work.Of course, think twice because you make web server a bit less secure, so don’t do that unless you are sure you need it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With