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.
Related
I have a function deployed in GCF which is executed in node js. And it works with Cloud SQL instance of MySQL.
And I receive this warning from time to time.
CloudSQL warning: your action is needed to update your function and avoid potential disruptions. Please see https://cloud.google.com/functions/docs/sql#troubleshooting for additional details: ensure that the account has access to "-mysql-dev7" (and make sure there's no typo in that name). Error during createEphemeral for -mysql-dev7: googleapi: Error 403: Cloud SQL Admin API has not been used in project 319049 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?project=319049* then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry., accessNotConfigured
And after this warning function continues to execute. What does it mean? Why function is not halted. If it is not important what does it mean and what if I don't enable this admin API?
BTW function only does selects and updates, it doesn't change table structure so theoretically why would it need Admin API?
I understand the confusion that warning messages may bring, especially if they have no noticeable effects on your function’s workflow.
To the best of my knowledge, the warning identifies that through not enabling this API, there will be potential for further issues when in need of performing certain tasks which require the Cloud SQL Admin API. Potential uses for the Cloud SQL Admin API can be found under public documentation. If you would ever need to list the Cloud SQL instances in a project, get the database of a particular instance, create a new Cloud SQL instance, or perform any other operation listed, please enable the API.
To avoid seeing these warnings all together, I would recommend enabling the API.
EDIT:
Cloud Functions utilizes a mechanism to connect to Cloud SQL instances via the Cloud SQL proxy, the Cloud SQL proxy in turn utilizes the Cloud SQL Admin API.
Therefore when connecting to a Cloud SQL instance without the Cloud SQL Admin API enabled, the error message is thrown.
Cloud Functions is still able to connect to the Cloud SQL instance as it utilizes a legacy connection mechanism when it is unable to do so via the Cloud SQL proxy.
This is why the function does not halt and can still perform the operations on the instance as expected.
Enabling Cloud SQL Admin API will solve the warning:
I'm creating a managed instance group with autoscaling in GCE. When a lot of work is queued up new instances will be created which start doing work.
Let's say each chunk of work takes 10 minutes, could it happen that GCE decides to shut down an instance that still has work in progress?
Autoscaler will immediately terminate instance if the health check condition meets.
However, you can use a shutdown script to control the termination. A shutdown script will run, on a best-effort basis, in the brief period between when the termination request is made and when the instance is actually terminated. During this period, Compute Engine will attempt to run your shutdown script to perform any tasks you provide in the script. You can read more about the autoscaler decision in this document. You can read about using shutdown script and its limitation at this link.
Also if these instances are offering backend service then it is good to enable connection draining. You can enable connection draining on backend services to ensure minimal interruption to your users when an instance is deleted automatically by an autoscaler or manually removed from an instance group. You can find more at this link about enabling connection draining.
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.
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 perl job that runs for 5 mins at the top of every hour. What is the most cost effective way of running this job on the Google Cloud infrastructure? Running a compute engine VM seems too heavy-weight for this since I'd get charged for the other 55 mins of no use. I don't understand the "Managed VMs" well enough, but it seems like this might be an option, but I'm not sure if pricing is rounded to the hour. Does anyone have any ideas what the best option is so that I only get charged for 120 mins of usage (24 times run * 5 minutes). The script also uses some image processing binaries, so converting to Python won't do the trick.
Managed VMs are linked to Google App Engine. If you have an App in GAE, managed VMs are used to configure the hosting environment for you App using VMs that run on Google Compute Engine and these applications are subject to Java and Python run time. This link can give you an idea on pricing on GAE, however Perl is not a supported language in GAE.
On GCE, you can start up an instance, do the task and then delete the instance without deleting the persistence disk, this will allow you to recreate the instance using this disk, however you will still be charged for the provisioned disk space and you will need to create a script that will spin up the instance and delete it. You can also create a snapshot of your disk and recreate your instance based on the snapshot, this will be little bit less expensive that keeping the disk.
Also, you should look at the type of persistence disks (PD) on GCE, at this link, take a look at the examples provided, since based on your operation, regular PD or SSD PD can make a big difference on price.
You can use the pricing calculator to estimate your charges
When you deploy to App Engine using a managed VM, an compute engine instance (managed by google) is created for you. All request to App Engine will be forwarded to the created compute engine instance.
To run your script in App Engine as a Managed VM, you will have to dockerize your project, as the managed VM runs a docker container.
I don't see a reason to use App Engine managed VM (just for running a script), as the cost will be same as using a compute engine instance.
Probably the most cost effective way is to create a script that:
Launches a compute engine instance
Install perl
Copies your script to the instance
Runs you script in the created instance
To schedule the execution, you can put at home/office a cron job that executes the above script.