Please note that the contents of this offline web site may be out of date. To access the most recent documentation visit the online version .
Note that links that point to online resources are green in color and will open in a new window.
We would love it if you could give us feedback about this material by filling this form (You have to be online to fill it)



FAQ

About

Data Storage and Replication

Backups and Point-in-Time Recovery

Getting Started

Managing Your Instances

Pricing and Billing

Using Cloud SQL with App Engine

About

What is Google Cloud SQL?
Google Cloud SQL is a web service that provides a highly available, fully-managed, hosted SQL storage solution for your App Engine applications.


What are the benefits of using Google Cloud SQL?
You can access a familiar, highly available SQL database from your App Engine applications, without having to worry about provisioning, management, and integration with other Google services.


Which versions of MySQL are available with Google Cloud SQL? How are updates managed?
Google Cloud SQL offers MySQL 5.5 and 5.6, updated to the current generally available release (see http://www.mysql.com/downloads/ ). Minor version updates are deployed as they are released, with no further action required on your part.

To see the current version of your instance, go to the Google Developers Console , select your instance and view the Properties . Or, you can execute SHOW VARIABLES LIKE "%version%"; from a SQL prompt, and look for the value of the version variable.




Does Google Cloud SQL support all the features of MySQL?

In general, Google Cloud SQL supports many of the most common features of MySQL. The following are lists of all the unsupported features and notable differences that Google Cloud SQL has from MySQL.

Unsupported Features:

Unsupported MySQL statements:
Sending any of the following types of SQL statements will generate an error with the message "Error 1290: The MySQL server is running with the google option so it cannot execute this statement"

  • LOAD DATA INFILE
    • Note: LOAD DATA LOCAL INFILE is supported.
  • SELECT ... INTO OUTFILE
  • SELECT ... INTO DUMPFILE
  • INSTALL PLUGIN ...
  • UNINSTALL PLUGIN
  • CREATE FUNCTION ... SONAME ...

Unsupported MySQL Functions:

  • LOAD_FILE()

Unsupported MySQL Client Programs:

  • mysqlimport without using the --local option. This is due to the LOAD DATA INFILE restriction. If you need to load data remotely, use the Cloud SQL import function .

Notable Differences:

  • If you want to import databases with binary data into your Google Cloud SQL instance, you must use the --hex-blob option with mysqldump .

    Although this is not a required flag when you are using a local MySQL server instance and the MySQL command line, it is required if you want to import any databases with binary data into your Google Cloud SQL instance. For more information, see Importing Data .

Are there any size or QPS limits?
Yes, the following limits apply to Google Cloud SQL:

Google App Engine Limits

Google App Engine applications are also subject to additional Google App Engine quotas and limits. Requests from Google App Engine applications to Google Cloud SQL are subject to the following time limits:

  • All database requests must finish within the HTTP request timer , around 60 seconds .
  • Offline requests like cron tasks have a time limit of 10 minutes.
  • Backend requests to Google Cloud SQL have a time limit of 10 minutes.
  • Each App Engine instance cannot have more than 12 concurrent connections to a Cloud SQL instance.

App Engine-specific quotas and access limits are discussed on the Quotas page.

How can I be notified when there are any changes to Google Cloud SQL?
You can sign up for the sql-announcements forum where we post announcements and news about Google Cloud SQL.


How can I cancel my Google Cloud SQL account?
To remove all data from your Google Cloud SQL account and disable the service:
  1. Delete all your data. You can remove your databases using the drop database command. For more information, see the MySQL documentation .
  2. Deactivate Google Cloud SQL for a project by visiting the Google Developers Console , selecting the project, and then selecting APIs & auth . Find the Google Cloud SQL API service and click the On button next to Google Cloud SQL. The button changes from On to Off .
How do I report a bug, request a feature, or ask a question?
You can report bugs and request a feature on our project page . You can ask a question in Stack Overflow . For other support options, see the Google Cloud SQL Support page.
Why is my instance suspended?
This is probably because billing is not enabled, or there is an issue with your account.


What are the known issues?
See the known issues list on our project page.

Data Storage and Replication

Where is my data stored?
Data for a Google Cloud SQL instance is stored in zones in the United States, European Union, or Asia depending on the location that you select when creating the instance. Note that creating an instance in Asia does not guarantee that your data at rest is kept only in that specific location. If no location selection is made your data will be stored at rest in the United States.



What is a zone?
A zone is an independent entity in a specific geographical location where you can run your resources. For example, a zone named us-central1-a indicates a location in the central United States. Data in Google Cloud SQL is replicated, and the service is distributed, across multiple zones, so to be tolerant of the failure of any single zone. For more information see Zone Resources in the Google Compute Engine documentation.



What are the limits on storage?
The size of all instances is limited to 250GB by default. Note that you only pay for the storage that you use, so you don’t need to reserve this storage in advance. The limits on storage are determined by the time it takes to restore an instance from backup in case of a problem, and we cannot guarantee to restore instances larger than 250GB within 24 hours (smaller instances restore a lot faster). If you require more storage, up to 500GB, then it is possible to increase limits for individual instances for customers with a silver Google Cloud support package .



How is my data replicated?
When creating a Google Cloud SQL instance, you can choose to enable synchronous or asynchronous replication for your data. In either case, your data is replicated in multiple zones within the US, EU, or Asia regions. This is equivalent to taking a backup of any updates to your data as they happen. This means that in the very unlikely event of a complete failure of a zone, your data will be preserved. In synchronous replication, your updates are copied to multiple zones before returning to the client. This is great for reliability and availability in the event of major incidents, but makes writes slower. The asynchronous replication option increases write throughput by acknowledging your write once it is cached locally, but before copying the data to other locations. Asynchronous replication results in faster writes to the database because you don't have to wait for replication to finish; however, you might lose your latest updates in the unlikely event of a data center failure within a few seconds of updating the database. Choosing synchronous or asynchronous replication makes no difference to how much you are billed because replication is not charged.



How does Google Cloud SQL failover work?
All Cloud SQL data is replicated in multiple zones. In the unlikely event of a zone outage, instances fail over to another, available, zone automatically. Failover is designed to be transparent to your applications, so that after failover, an instance has the same instance name, IP address, and firewall rules. During the failover there will typically be a few seconds downtime as the instance starts up in a new zone. However, in some cases, the InnoDB crash-recovery process may take longer, delaying the time before the instance is up.

In a failover event, existing connections to instances are broken. You can test how your application responds to a failover by restarting your instance . For recommendations on managing connections that can help in failover events, see the FAQ entry How should I manage connections? .

Is my data encrypted?
Yes. Cloud SQL customer data is encrypted when on Google’s internal networks and when stored in database tables and temporary files (with encryption of backups coming soon).

External connections can be encrypted using SSL. Of course you can also encrypt your data yourself before writing it to Cloud SQL, though this would require you to manage your own keys.





How is encryption managed?
Your data is encrypted using the 128-bit Advanced Encryption Standard (AES-128), or better, with symmetric keys: that is, the same key is used to encrypt the data when it is stored, and to decrypt it when it is used. These data keys are themselves encrypted using a master key, stored in a secure keystore, and changed regularly.



Is my data encrypted when it’s on Google’s internal network?
Yes.

Backups and Point-in-Time Recovery

How do I recover an instance?
To restore to a backup you can use the Google Developers Console or the Cloud SQL command-line tool. For more details, see Restoring from Backups .

To restore to a point-in-time, you can use the Cloud SQL command-line tool. For more information, see Performing a Point-in-Time Recovery .





How much do backups cost?
Storage of 7 days of backups are included in the cost of your instance. Binary log space counts toward the storage used in an instance. Restoring from an instance backup restores to the instance. Recovering an instance to a point-in-time creates a new instance, which will be charged at the standard instance rate. For more information about instance storage pricing and instance rates, see Pricing .



How do I enable point-in-time recovery?
Point-in-time recovery is not enabled by default. You must enable automated backups and binary logging for an instance to use point-in-time recovery. For more information, see Backup and Recovery .



How does point-in-time recovery impact performance?
Point-in-time recovery requires that you enable binary logging. This means that every update to your database is written to an independent log, which involves a small reduction in write performance. Reads are unaffected. The impact on performance is greater for instances that use synchronous replication, so we recommend that binary logging is used together with asynchronous replication.

Getting Started

What is the best tool to use for managing my instance?
There are a variety of tools available for Google Cloud SQL. For executing simple statements, you can use the MySQL Command-Line Tool . For executing more complicated tasks or to use a richer database development environment, you can try Toad for MySQL or MySQL Workbench . For more information, see Admin and Reporting Tools .


What storage engine should I use?

InnoDB is the default storage engine in MySQL 5.5 and 5.6, and is also the recommended storage engine for Google Cloud SQL because it has significantly better performance and durability. If you do not need any features that require MyISAM, such as full text search in MySQL 5.5, you should use InnoDB.

Warning: Using the MyISAM storage engine could result in data loss in some situations, such as unclean shutdowns. For more information, Corrupted MyISAM Tables .

If you would like to use features of MyISAM, try to use it for just those tables that require it. You can convert an existing table to MyISAM using the following SQL command, replacing tablename with the name of the table to convert: 

ALTER TABLE tablename ENGINE = MyISAM;

If you have a mysqldump file where all your tables are in MyISAM format, you can convert them to InnoDB format by piping the file through a sed script: 

mysqldump --databases database_name [-u username -p password] --hex-blob --default-character-set=utf8 |
sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > database_file.sql

Warning: You should not do this if your mysqldump file contains the mysql schema. Those files must remain in MyISAM.

I've just created a new, empty, instance but the dashboard shows I have already used some disk space. Why?
The InnoDB storage engine creates initial log and data files when your instance is created.


Why is my database instance sometimes slow to respond?
In order to minimize the amount you are charged for instances on per use billing plans, by default your instance becomes passive if it is not accessed for 15 minutes. The next time it is accessed there will be a short delay while it is activated. You can change this behavior by configuring the activation policy of the instance. For an example, see Editing an Instance Using the Cloud SDK .

Managing Your Instances

Can I make my database larger or smaller by changing between tiers?
Yes. You can change the tier of your database at any point. Note that this will force your instance to restart, which will take a few seconds.


Do I need to use the Google Developers Console to manage Google Cloud SQL?
No. All management tasks that can be done via the console can also be done programmatically via the Cloud SQL API .


How large a database can I use with Google Cloud SQL?
Currently, your database instance can be no larger than 500GB.


How can I reclaim the space from a dropped table?
When you drop a table from a database and then check the Google Developers Console, you will see that the space freed by dropping the tables is not reflected in the reported Storage Used of the instance. For performance reasons, we run with innodb_file_per_table=OFF and InnoDB never shrinks its default tablespace. Therefore, to reclaim space, recreate a new instance from the smaller database.


What kind of maintenance shutdowns should I expect with my instance?
We periodically restart Cloud SQL instances to perform upgrades, migrate between zones, and perform other infrastructure work. Since your data is replicated in multiple locations, the interruption to your instances is very short, typically a few seconds. Instances configured to follow an App Engine application may also be restarted in a new location in order to minimize the latency from that application as it moves. This may involve a short period of increased latency, and typically a few seconds of unavailability.

We recommend that you design your applications to deal with situations when your instance is not accessible for short periods of time, such as in a maintenance shutdown. You can test the behavior of your application to a maintenance shutdown by restarting your instance , which has the same effect.

Note that the amount of time mysqld has to shutdown is capped to 1 minute . If the shutdown does not complete in that time, the mysqld process is forcefully terminated. This will incur a longer startup time because the InnoDB storage engine does a crash-recovery before the server is ready to start serving queries.







Can I import or export a specific database?
Yes, you can import or export a specific database. For more information, see Importing and Exporting Data .


Do I need a Google Cloud Storage account to import or export my instances?
Yes, you need to sign up for a Google Cloud Storage account or have access to a Google Cloud Storage account to import or export your instances. For more information, see Importing and Exporting Data .


If I delete my instance, can I reuse the instance name?
Yes, but not right away. The instance name is reserved for up to two months before it can be reused.


A 'gserviceaccount' is shown in the team members in the console. What is it?
This account was created automatically and is used by Google to manage your Cloud SQL instance, but has no effect on your project. (For example, it does not matter if you alter the permissions on this account.)


What is the cloudsqladmin database user?
Every Google Cloud SQL instance includes a database user called cloudsqladmin . You may notice this user if you do a SHOW GRANTS FOR cloudsqladmin@localhost . On some instances this will also show up in the mysql.user table. This user account is used by automated processes that need to access the data in your instance (for example, backing up your instance or performing an import or export).


How can I use GRANT ALL ?
Google Cloud SQL does not support SUPER privileges, which means that GRANT ALL PRIVILEGES statements will not work. As an alternative, you can use GRANT ALL ON `%`.* .


How can I access transaction logs for my instances?
If you enable binary logging for your instance (see Enabling binary logging for a Cloud SQL instance ) and configure an IP address for you instance (see Configuring access control for IP connections ), then you can use the standard MySQL mysqlbinlog utility to examine the transaction logs for the instance.

Pricing and Billing

How can I try out Google Cloud SQL?
The D0 tier and per use billing means that you can try out the service for just $0.025/h, and you only pay this while the instance is being used.


Which pricing plan should I use? Per use or package?
This depends on how your database will be used, but as a rule of thumb it is more economical to opt for the package plan if your instance is used for more than 450 hours each month.
See Pricing for details of the pricing plans.



Can I change between plans?
You can change the billing plan for your instance up to 3 times per month. The plan in effect at the end of the day (US Pacific Time) will be the one used to calculate the charge for your instance. You can change your plan as many times as you like in a single day, and it counts as one of your three monthly changes.

You can change the billing plan for an instance by editing its settings. Do this by going to the Google Developers Console , selecting the project that contains the instance, and then selecting Google Cloud SQL. From the list of instances, select one and edit its settings, which includes billing settings.





How many instances can I create in a project?
You can create up to 30 instances per project. Deleted instances do not count toward the 30 instance limit. You can request that the instance limit be raised for a project.


What size database instance do I need? How much RAM?
If you already know approximately how much data you will have then the fixed package sizes are a good guide to a suitable instance size. You can increase the performance of your database in general by choosing a larger instance with more RAM and CPU. This will increase the performance of many queries that involve large amounts of computation, such as those involving joins, ORDER BYs, or GROUPing, though the performance of updates affecting single rows will not be much affected.


How is use of my instance calculated?
If your instance is billed per use, then you will be charged for just the time that your database is up, rounded up to the nearest hour. By default, your instance is spun up whenever you access it (whether from a SQL prompt, an external application, or from an App Engine application), and remains up for 15 minutes after the completion of the last access. After this time, the instance is shut down. You will not be charged for the time your database is not up.

Note that an instance stays up as long as there are clients connected to it. This includes idle connections. You can list the connections to an instance using the MySQL client and executing the SHOW PROCESSLIST command. You can then use the KILL command to kill connections. You can also you restart the instance to kill all the connections.

By default, package instances stay up for 12 hours after the last access.

You can change the activation behavior of an instance by modifying its activation policy. For an example, see Editing an Instance Using the Cloud SDK .









How is storage calculated?
Storage is calculated on the basis of the amount of file space used by your MySQL instance. Storage is charged per GB in hour units (whether the database is up or not) measured as the largest number of bytes during that period, rounded up to the nearest GB. Storage for backups created using the scheduled backup service is not charged.


How can I see how much I will be charged?
The Billing tab of the Google Developers Console shows you how much charge your instances have gathered since the last bill was issued.


I have not been using my instance recently, so why have I been charged for it even though I am on the "per use" plan?
Check to see if you have enabled scheduled backups for the instance. Google Cloud SQL takes a backup of an instance only if the instance's data has changed since the last scheduled backup. Whenever a scheduled backup occurs, the instance is activated for the duration of the backup, incurring "per use" fees.



Why have I have been billed for more time than my database instance has been used?
The "per use" plan bills for the time that your database instance is used. Each use is rounded up to the nearest hour. So if you use your instance for five minutes once an hour for ten hours, you will be billed for ten hours of use.


What happens when my instance reaches the allowed size?
If your instance reaches the maximum storage amount allowed by the plan you have chosen, future writes to the database are disallowed until you delete data to reduce the size.


How do I cancel billing?
You can cancel billing by clicking the Cancel billing button in the Google Developers Console Billing pane for a project. If you disable billing, you also disable the Google Cloud SQL service. Make sure you really want to disable the Google Cloud SQL service before you disable billing.
After you disable billing, you will receive one last bill for charges that occurred between the beginning of the billing cycle and when you cancelled.
Caution: When you disable billing, it is disabled for all services in that project. You can not disable billing for individual services or APIs. For more information, see the Disabling Billing section in the Google Developers Console help guide.

Using Google Cloud SQL with App Engine

Can my App Engine in the US access my Google Cloud SQL instance in the EU (and vice versa)?
No. App Engine applications in the US can only access Google Cloud SQL instances in the US. Similarly, App Engine applications in the EU can only access Google Cloud SQL instances in the EU.


Should I use Google Cloud SQL or the App Engine Datastore?
This depends on the requirements of the application. Datastore provides NoSQL key-value storage that is highly scalable, but does not support the complex queries offered by a SQL database. Cloud SQL supports complex queries and ACID transactions, but this means the database acts as a 'fixed pipe' and performance is less scalable. Many applications use both types of storage.


Should I use Google Cloud SQL with my Master-Slave App Engine application?
We recommend that you use Google Cloud SQL with High Replication (HRD) App Engine applications. While you can use Google Cloud SQL with applications that do not use high replication, doing so might impact performance.



Do I need to install a local version of MySQL to use the App Engine Development Server?
No. You can configure App Engine to use either Cloud SQL or a locally installed version MySQL when running on the development server. Note, however, that using a locally-installed version of MySQL helps reduce usage of your App Engine datastore quota during testing.


Can I use languages other than Java or Python?
Only Java and Python are supported for Google Cloud SQL.


Can I use Django with Google Cloud SQL?
Yes, Google Cloud SQL is compatible with Django! See the Django Support documentation for details.


Which placeholders can I use in my Python query string?
Python users can only use the %s format code in parameter substitution. Therefore, the following statement is invalid: cursor.execute('INSERT INTO entries (guestAge) VALUES ( %d )', (age)) .


How should I manage connections?

How to best manage your database connections depends on your use case. For example, if the time to create a new database connection is greater than checking and reusing an existing connection, then we recommend you use connection pooling. Conversely, if the time to create a new connection is about the same as testing if an existing connection is alive and reusing it, then we recommend that you create a new connection to service each HTTP request, and reuse it for the duration of the request. In particular, the latter case may apply when you connect from Google App Engine to Google Cloud SQL.

In cloud-hosted environments, you should manage your database connections differently than managing them in a conventional, on-premises server environment. We recommend that you design your applications to handle occasional connection failures by implementing an error handling strategy like exponential backoff . For an example, see Exponential backoff in the Google Cloud Storage documentation.

What does a SQLException with message of "Invalid connection ID" mean?
It means that the connection is no longer open on the server and should be discarded by the client.  You do not need to call 'close' on these connections; they are already closed.


Can I access my Google Cloud SQL instance programmatically outside of App Engine?
Yes. You can access Google Cloud SQL instances programmatically from external applications using JDBC, including writing Apps Script scripts to access your Google Cloud SQL databases. See Connecting from External Applications .

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License , and code samples are licensed under the Apache 2.0 License . For details, see our Site Policies .

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.