Forum menu
Having a play with Google's Cloud SQL and everything's cool in that I can connect to the database via a terminal from my PC and query it, but I've uploaded a little php script to my web site (that basically just connects to the database and displays the tables) cannot connect.
I have set the Cloud SQL settings to allow connections from both my IP addy and the addy of my web site.
Any thoughts?
Port blocked by your website host?
If you have more than one IP address bound to the NIC in your web server, it might not be making the outbound connection on the same IP address as your website.
My web server is a big provider over in the US - if I ping my web site I get a reply from 38.113.1.158 ..... this will be the IP that it will be connecting to the mysql server won't it?
Tried a different php script and the error is: Connection refused
this will be the IP that it will be connecting to the mysql server won't it?
Not necessarily.
Probably worth checking with them to see how they handle outgoing connections.
Can you allow connections from everywhere temporarily as a testing step? That'll tell you whether it's IP address related or something else.
It's unlikely that'll be the IP address that you're accessing from, the IP that you get from an nslookup on your website IP will probably be the IP of a load balancer depending on you're 'cloud' service.
Do you have access to the webserver itself through RDP? easiest way would be to go to whatismyip.com and use that.
Hmmmm - turns out that my wonderful web hosts do not allow connections to remote databases ๐
That's piddled on that idea then ๐
That's a pretty lame restriction from a webhost.
Sure it wasn't the user permissions you were connecting to the DB with ?
https://cloud.google.com/sql/docs/create-user
"When you add user accounts, you can control how restrictive per-host permissions are with the host_name. For example, if you specify host_name as a wildcard '%', it means any host can use the user account to connect to the instance. "
That's always the issue with remote MySQL connections I have i.e. the default is for localhost connections only.
well I can connect fine from home (via command line) using an account I've created but not via the web site using the same credentials.
(and I've used @% to allow connections from anywhere using that account)
Do you get an error code/text ?
connection refused
I'm guessing you can't on a hosted platform, but do you have the ability to change the listener port used by the database? If you could stick it on a non-standard port then that might get around the webhost restriction.
Presumably they block external databases so that you have to pay to use theirs?
I'm checking again with my web hosts that they don't allow connections to remote databases.
Do you have any more information other than that error, for example what's generating it?
I'm no MySQL expert but it's saying that the connection is "refused" rather than simply failing, which suggests to me that it's being actively rejected. Ie, it's actually getting to the database and the database is saying no. I'd have thought that a restriction at the webhost level would give an error closer to "unable to connect" or some such. But I'm guessing at best, just thinking out loud really.
[quote=Cougar said]
I'm no MySQL expert but it's saying that the connection is "refused" rather than simply failing, which suggests to me that it's being actively rejected. Ie, it's actually getting to the database and the database is saying no. I'd have thought that a restriction at the webhost level would give an error closer to "unable to connect" or some such. But I'm guessing at best, just thinking out loud really.
This.
You can verify this by trying to telnet to the remote MySQL IP/port from the command line of your hosted service (assuming you can get to a command line). If the telnet connects OK then your MySQL client should be able to. If the telnet also gives a connection refused error then something is intervening at a comms level.
No they def won't allow connection to remote databases - poo.
Hah ...... after 20 years with the same web hosts it took 10 mins to swap to a new one and problem solved ๐