One of the things I find a bit difficult with CloudSQL is surprisingly the first thing you need to do – connect.
Being able to connect securely to your CloudSQL instance is sometimes a bit challenging not just in Go, but in Python as well.
In Go, I’ve found out conflicting suggestions and examples and after much trial and error I found a reasonable solution that works well.
After much searching I found CloudSQL Proxy which takes all of the IP white listing and SSL mess away by using direct OAuth APIs to obtain access to the instance.
While my example works specifically with GORM, which requires a nice database connection string, there are examples of using plain database/sql syntax with CloudSQL Proxy.
I know it looks simple enough, but without importing cloudsql-proxy it wouldn’t have been possible to use the “user@cloudsql(project-id:zone:instance-name)/db” syntax style that is scattered around the net.
Recently I bumped twice into an issue with Google Cloud Network Load Balancer in which it decided a server was unhealthy regardless of if there was a health check or not.
The first time I cloned the machine and started a new one – which obviously fixed the issue.
The second time I’ve decided to try a bit harder.
I’ve bumped into this old bug detailing a race condition in google-address-manager.
google-address-manager is part of the Google Daemon, a set of processes that runs inside an image running in Google Compute Engine.
If google-address-manager is down, Network Load Balancing may not work at all, marking your instance as unhealthy even though it is working well.
If that happens, you might want to restart the service but issuing:
sudo service google-address-manager restart
sudo /etc/init.d/google-address-manager restart
This should make sure Network Load Balancing will work as it should. Also note that without this service, SSH keys will not get provisioned.
While I do not know what the process crashed (I couldn’t find any reasonable log) I suspect it had something to do with low disk space on that drive.