How to prevent automatic updates being applied to the Cloud SQL instance. I see Type as Update and Status as Done for many entries. Its a MySQL 5.7 instance. How should I prevent Updates on my Cloud SQL instance?
https://cloud.google.com/sql/faq#maintenancerestart
Cloud SQL is a fully-managed database service, so it's not possible to prevent automatic updates. As you can see in the FAQ, minor updates are deployed as they are released. If you have a second-generation instance, you might want to consider a preferred maintenance window that will be less disruptive for your application.
Unfortunately, this is probably not possible. Cloud SQL is a hosted service, and comes with built-in infrastructure support. AFAIK the only way to have absolute control over your DB software is to run it on a GCE instance, rather than on a Cloud SQL instance.
Related
I have problem with Cloud SQL billing.
My Cloud SQL has used all 720 Hours running machine (db-g1-small : changed from db-n1-standard-1 recently)
I've found accordding to Cloud SQL Documentation that
For Second Generation instances, the activation policy is used only to start or stop the instance.
So without ON_DEMAND policy of the First Generation, how can I reduce these costs on my Cloud SQL instance?
PS. Look like my cloud server not automatically down because it stay 4 sleep connections
Indeed for second generation instances of Cloud SQL, the only activation policies available are ALWAYS and NEVER, so it's not possible anymore to leave that kind of instance handling entirely on Cloud SQL's hands.
However you can create a workaround for this by executing a cron job that turns the instances on/off on a fixed schedule. Eg: you can run a cron job that runs on friday night to shutdown the instance and on monday morning to shut it back on.
You can use the following command to do so:
gcloud sql instances patch [INSTANCE_NAME] --activation-policy [ACTIVATION_POLICY_VALUE]
Moreover, you can create a feature request on Google Cloud's Public Issue Tracker System to re-include that functionality on Cloud SQL in the future, but there are no guaratees that this will happen.
Lets say I have a VM instance and I then make a connection to the Cloud SQL instances IP using a MySQL client. According to the comparison table in Connection Options for External Applications, connecting with no SSL is apparently not secure (and non-encrypted).
But to what extent is it insecure? If there is a man-in-the-middle attack, query and query results could be seen. I would like to determine how big of a risk that is.
Specifically I would like to know the risks of connecting from:
A VM in the exact same zone to a Cloud SQL instance
A VM in the same region, but a difference zone to a Cloud SQL instance
A VM in another region to a Cloud SQL instance, but still from GCP
I assume that for any of these kinds of attacks to be carried out, the actual google infrastructure would have to have been compromised as it wouldn't be possible for a VM to listen to traffic outside a network that it's attached to.
The actual infrastructure wouldn't have to be compromised actually, all that it'd take is for an instance in the same network to be compromised for the details of your connection to Cloud SQL to potentially be compromised. Seeing as maintaining the instances up-to-date is a responsibility of the users, that means that the security of an insecure connection to Cloud SQL also depends on the security of your instances.
Why exactly are you doing insecure connections? I ask because it's incredibly easy to setup a safe connection from an instance to Cloud SQL by using Cloud SQL Proxy! Not to toot my own horn here, but take a look at
this answer I gave a while ago about why you should be using the Proxy.
Regardless, and keeping in mind that Cloud SQL is nothing more than a managed instance exclusively accessible via its public IP, the traffic should stay within GCP in all three of those scenarios, meaning the only thing that is likely to be compromised are the instances in the same sub-network as that of the instance that's connecting to Cloud SQL.
Per this, Cloud SQL requires the external IP address of the client in order to allow connections to it. The other suggested way is the sql proxy with a big disclaimer that the method may change over time.
Question: If I am auto scaling compute engine VMs running webservers, do I need to assign them all external IPs and then go set those in the Cloud SQL instance? Or am I missing something huge? Noob question perhaps, thanks for reading through.
The recommended way is to use the Cloud SQL proxy (but if you really don't want to use it you would need to add static IPs to your GCE VMs and whitelist them on the Cloud SQL instance).
Also, you can setup a single VM instance with cloud_sql_proxy and listen to your subnet interface (for example) to make possible to connect any new VM instance to the one with a proxy.
I have deployed my web server which requires a MySQL database for storage. I've created a Second Generation MySQL instance with one failover replica but I am not sure how I can connect to those.
I am not sure how to configure these instances and what I have to consider here e.g. region/zone. Flexible Environment appears to be unavailable in Europe unfortunately - at the moment at least - so I guess I'll have to place the SQL instances in the US too.
Will those instances have to be in the same local network or can they communicate over regions? Will I even be able to control this or will all this be decided by Google Cloud?
Could anybody who has done this before give me a few details about what to do here?
For best performance, you should place your App Engine instances in the same region.
For information on how to connect from your application to the Cloud SQL MySQL instance see the following documentation: https://cloud.google.com/sql/docs/dev-access#gaev2-csqlv2
The short summary is that you have to modify your app.yaml file to list the Cloud SQL instances you will be connecting to. Once that's done, a local socket will appear inside the App Engine VM that will allow you to connect to your Cloud SQL instance.
I have a bluemix app that is currently setup with the ClearDB MySQL 3rd party bluemix service through PHP. The service works well, however I noticed that there is a limit of 5mb of space for the free version (you can upgrade from there). I recently looked into Bluemix's own SQL Database service and it offers up to 100mb of space free per instance running on Bluemix. What are the advantages of the ClearDB service? To me it seems that Bluemix's own service would be a lot more cost effective. What are the considerations?
Thank you,
--
They are based on different RDBMS: ClearDB is based on MySQL while SQL Database is powered by IBM DB2, so that should be the first thing to consider when choosing between them. For example if you are deploying an existing application that works on MySQL you may want to use the same DBMS.
If the underlying technology is not important (or you don't have any constraint on it) please note that, as you can see in the Bluemix Catalog, ClearDB is a Third Party while SQL Database is an IBM service. This means that the latter is developed by IBM and you can get a quicker support when experiencing issues with your database.