Re: [google-cloud-sql-discuss] Trying to Connect to database in PHP using PDO and Cloud SQL Proxy

To your question, yes I'm replacing the ips and ports

1. So to confirm, using fuse with PDO is not advised right? When I set it up with fuse, I see a "README" file in my /cloudsql directory with error (no such file or directory) but when I set it up with "-instances" I see <your-project-id>:<the-region>:<your-instance-name> file in /cloudsql directory with a successful connection
   
2. Let's say I want access to multiple instances how will I achieve that?
   
3. When you say "Note that you don't specify the hostname when connecting to a Cloud SQL instance (using the proxy or not using the proxy), it is inferred by the database itself when a new connection comes in." what do you mean? Just a reminder that I'm running the proxy on a on premise server to connect to my instance in google cloud sql.
   
4. How stable is the proxy  sql. Does it hang sometimes? Can I expect to run this on production?
   
5. When I create name_of_user@'cloudsqlproxy~% in mysql, I don't need to assign any privileges to the database I need right?
   
6. When I create name_of_user@'cloudsqlproxy~% is that the username with no password I use to connect to my db in my php code?
   

Just a suggestion. I think the common name of the ssl certificate on the cloud sql instance should be a name with no colon; set of alphanumeric ASCII characters (a-z, A-Z, 0-9). Let me tell you why. When I tried to first access the db with PHP/PDO and ssl certificates, it failed peer validation which makes sense because you guys use CN and IP that does not match. If the CN was without colon maybe I can map the ip and the CN in my hosts file so that when peer validation is done, it can check my hosts file before it touches the DNS and pass. This would have been a quick fix instead of people moving to AWS RDS or waiting for PHP to implement CLIENT_SSL_DONT_VERIFY_SERVER_CERT. (https://bugs.php.net/bug.php?id=71003) 

Thanks your for help

On Monday, March 14, 2016 at 7:37:04 PM UTC-4, Kevin Malachowski wrote:

Just a quick question: are you actually swapping in your project id, the region of your instance, and the instances name? I can't tell if you're copy-pasting and manually redacting your project/region/instance (I agree, you shouldn't be posting this info on this public forum) or if you're literally trying to connect to  "<your-project-id>:<the-region>:<your-instance-name>".

Answers to your questions inline:

On Mon, Mar 14, 2016 at 4:05 PM, <wob...@yblew.com> wrote:

Kevin, I think it worked. Will do more testing and update you

2016/03/14 18:56:37 Got a connection for "<your-project-id>:<the-region>:<your-instance-name>"

2016/03/14 18:56:37 from "<your-project-id>:<the-region>:<your-instance-name>" via IP:3307: read tcp IP->IP:3307: use of closed network connection

But two things: 

1. What is really the purpose of CREATE USER name_of_user@'cloudsqlproxy~%';  in your documentation. I'm still a bit confused about it? I should be able to login using regular mysql username and password from php right Or I need to have that?

If you are using the proxy, you should create a user with a hostname 'cloudsqlproxy~%'; this user will only be available for connections that come in through the proxy. It is not strictly required but it is definitely suggested because it is safe to create this user without a password regardless of the firewall configuration of your instance.

Note that you don't specify the hostname when connecting to a Cloud SQL instance (using the proxy or not using the proxy), it is inferred by the database itself when a new connection comes in.

 

2.  How do I silent the print out from proxy and how can I keep the command running even after server reboot?

The proxy prints out its logs on standard error. You can redirect this output to a file named 'proxy.log' by doing something like this:

./cloud_sql_proxy    YOUR_OTHER_ARGUMENTS_HERE    2>proxy.log   &

(the '&' causes the process to run in the background)

On unix-like systems, you can cause the output to be ignored by redirecting it to the file located at '/dev/null'. I suggest writing the output to a file or somehow hooking into your system's logging infrastructure, though. It will be easier to debug problems you may encounter in the future when you have access to the logs that the proxy writes.

As for keeping the proxy up after a reboot, you can configure your system to run the proxy when the server starts up. Every system is different, so I can't give specific advice unless you give more info about your specific server. For example, can you find other services that run on startup that you can model after? I find that searching the internet for your operating system along with something along the lines of "run program on startup" yields good results.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/6330a422-365f-4069-b2ff-f764e2b09371%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.