More about Google cloud database
- Google Cloud Big Data: Build a Big Data Architecture on GCP
- Google Cloud Database: The Right Service for Your Workloads
- Google Cloud MySQL: The Complete Guide
- Understanding Google Cloud High Availability
- 8 Types of Google Cloud Analytics: How to Choose?
- Google Cloud BigQuery: How to Use Google Cloud BigQuery
- Oracle on Google Cloud: Two Deployment Options
- Google Cloud SQL Pricing and Limits: A Cheat Sheet
- SQL Server on Google Cloud: Two Deployment Options
- Google Cloud SQL: MySQL, Postgres and MS SQL on Google Cloud
How Can You Run MySQL on Google Cloud?
You can deploy MySQL as part of a Google Cloud project in several ways. You can use the Google Cloud SQL managed service for MySQL, a MySQL image from the Google Cloud Marketplace, or manually install MySQL on Compute Engine.
- Google Cloud SQL—a managed Google Cloud database service that handles administrative tasks such as replication, patch management, and database management.
- Google Cloud Marketplace image—lets you install MySQL on Compute Engine instance in a few clicks.
- Manually installing MySQL on Compute Engine—If you want complete control and the ability to fully customize your MySQL instance, you can create a MySQL database by starting up a Compute Engine instance and installing MySQL on it.
In this post, we’ll review the managed MySQL deployment options, and explain their pros and cons compared to the self managed option - running MySQL in a Google Cloud virtual machine.
If you need to customize your MySQL server for an enterprise environment, jump forward to read about the self managed option.
In this article, you will learn:
- Understanding Google Cloud SQL for MySQL
- Fully Managed vs. Self Managed Deployment of MySQL on Google Cloud
- NetApp Cloud Volumes ONTAP: The Best of Both Worlds
Understanding Google Cloud SQL for MySQL
Below we’ll cover key aspects of the Google Cloud SQL for MySQL managed service, including pricing, backup, and replication capabilities.
For a broader look at the Google Cloud SQL service, including MySQL, Postgres and SQL Server capabilities, read our guide to Google Cloud SQL.
Below is a brief review of MySQL managed service pricing on Google Cloud. For more details and up-to-date prices, check the official pricing page.
MySQL instances are charged each time the instance is launched, and are billed by the second (rounded to the nearest second). Usage charges depend on the machine type and the region in which the instance is located.
In the US-Central region, instance price per hour ranges from $0.0105 for the smallest db-f1-micro instance with no high availability, to $8.4504 for the largest db-n1-highmem-96 instance with 96 vCPUs and 624 MB of RAM. There are additional charges for high availability, and you can get significant discounts by committing to 1 year of usage in advance.
The storage and network pricing for a MySQL instance depends on the instance location.
Type of Storage
Price Per GB/Month for HDD
Price Per GB/Month for SSD
Price Per GB/Month for Backups
Highly Available (HA) Storage
Network and data transfer pricing
There is no charge for serverless export and ingress traffic to Google Cloud SQL. For network egress, pricing is as follows:
- Egress within the same Google Cloud region or to other Google products in the same continent—free
- Egress to Google Compute Engine, Cloud SQL replicas in other regions, or other Google products in another continent—$0.12/GB
- Internet egress—$0.19/GB (can be significantly reduced to $0.05/GB by using Google Cloud Interconnect)
Backups can help restore lost data to a Cloud SQL MySQL database. You can also restore an entire instance from a backup. There are two types of managed backups:
- On-Demand Backups—can be performed at any time. This is useful if you are performing dangerous operations on the database or if you need an immediate backup and cannot wait for the backup window. On-demand backups are retained until they are deleted, or the instance is deleted.
- Automated Backups—uses a 4-hour backup window. Backup starts at some point during the window. It is recommended to schedule backups to a time when database activity is minimal. Automated backups only run if the instance has been running in the past three days. The past 7 backups are kept automatically, and previous backups are discarded.
MySQL Replication Options
Replication can be used to scale up read traffic on the MySQL database, using read replicas, or to migrate the database. Google Cloud SQL offers three replication options for MySQL:
- Read Replicas - each MySQL database can have up to 10 read replicas. A read replica is an exact copy of the master instance; data changes to the master instance are updated on read replicas in near real time. Read replicas are read-only—they can offload queries, read requests, and analytics applications from the master instance.
- Cross-Region Read Replicas - cross-region replication allows you to create a Read Replica in a different region than the primary instance. This can improve read performance by making copies available physically near to the application. It also makes the database resilient to disasters affecting the local region. Data can be migrated between regions with minimal downtime.
- External Read Replicas—an external read replica is an external MySQL instance replicated from the Cloud SQL master instance. For example, MySQL instances running on Compute Engine are considered external instances.
Fully Managed vs. Self Managed Deployment of MySQL on Google Cloud
In the previous section we described the fully managed option for deploying MySQL to Google Cloud, via Google Cloud SQL. The fully managed option is tailored to the PaaS cloud service model and is primarily suitable for cloud-native applications, or applications rebuilt for the cloud.
There is an additional way to deploy MySQL on Google Cloud which is more suitable in larger deployments with enterprise-grade requirements. You can manage MySQL directly by running a Google Compute Engine instance and deploying a MySQL image on it. This self-managed IaaS model gives you full control of your MySQL database on GCP, allowing you to fine-tune server and database configurations as you see fit, just like in a local deployment.
We’ll discuss how migration works for each of these scenarios, and then list pros and cons of each of the deployment options: managed vs. self managed.
Each deployment option has different migration features.
Fully managed—migrating to Google Cloud SQL
- Import/export migration - involves extracting data from your database using mysqldump, and then importing it to the hosted MySQL instance. This method requires downtime to ensure consistency.
- External replica promotion and migration - creates a replica of the on-premises database and synchronizes existing data with that copy. This can happen without downtime for production databases. Google Cloud SQL provides an automated migration workflow for this method, which can support migration from local databases or from other cloud providers.
Self managed—migrating to Compute Engine instance
Google provides two tools that can help you move MySQL from an on-premises data center to a Google compute instance:
- Migrate for Compute Engine—performs fully automated migration of workloads from on-premises bare metal machines or VMs to Google Cloud.
- Transfer Appliance—a Google-provided hardware appliance that can help you transfer large data volumes from your data center to Google Cloud, for MySQL databases with very large data volumes.
Related content: Google Cloud Migration Tools: Copying 1GB or 500TB? Learn How
Pros and Cons of Fully Managed Deployment—MySQL on Google Cloud SQL
Pros of managed option - MySQL with Google Cloud SQL
If the team managing the database are not MySQL experts, or the requirements are basic, Google Cloud SQL is a great choice. Cloud SQL is a turnkey solution for deploying and running MySQL, simplifying day-to-day operations and database administration tasks like upgrades, configuration, and backups.
Cons of managed option—MySQL with Google Cloud SQL
- Limit on number of instances—by default, Google Cloud SQL allows up to 40 database instances per project. It is possible to request an increase on this limit from GCP support.
- Storage limits—supported database size is up to 30.7TB.
- Connection limits—you can maintain up to 250, 1000, or 4000 concurrent connections to the database, depending on instance size.
- No access to the server—you cannot directly access the database server and change operating system, storage settings, or database configuration.
- Difficult to migrate—you can decide in which GCP region the database will run in, but it can be challenging to move to another GCP region, and you cannot easily migrate data to another cloud provider.
- Version limitations—only MySQL 8.0, 5.7, and 5.6 are currently supported. You cannot use other MySQL versions until Google makes them available.
Pros and Cons of Self-Managed Option—MySQL on Google Compute Engine
Google Compute Engine is an infrastructure as a service (IaaS) platform providing excellent performance and reliability. Google compute instances let you build custom infrastructure that is flexible and highly reliable.
When running your database on Compute Engine, you need to consider how data will be stored. A common choice is Google Persistent Disk, supported by storage management solutions such as NetApp Cloud Volumes ONTAP.
Pros of self-managed option—MySQL on Compute Engine instance
This option is ideal for organizations looking for complete control and flexibility of enterprise database workloads. The advantages are:
- No limit on number of instances - you can run as many database instances as needed, by starting more Compute Engine instances.
- No storage limits - you are only limited by the attached storage service; it is possible to use third party services for large databases.
- No connection limits - there are no hard limits on the number of connections, but of course you will need to ensure your instance size and database configuration can support the required number of concurrent connections.
- No version limitations - you can run any version of MySQL on Compute Engine.
- Maximum flexibility - ability to customize everything from database settings to the environment.
- Hybrid data - easier to integrate your database with resources and workloads running on-premises or on other clouds.
- Advanced database features - lets you tune database configuration to improve performance, leverage RAID for large-scale storage, and gain better control over data replication.
- Cost savings - in this model you only pay for cloud resources you directly use, with no additional charges for premium management services.
Cons of self-managed option—MySQL on Compute Engine instance
- Setup—Setting up MySQL and operating it day to day can be time consuming.
- Expertise—the MySQL deployment must be managed by staff with extensive expertise in MySQL and Google Cloud infrastructure.
- Maintenance—your team is responsible for backup, monitoring and logging, replication, availability, and everything else needed for an enterprise database deployment.
However, for large or mission critical databases, these cons can be considered as pros, because an experienced database administration team will want a high level of control over their deployment and can still benefit from the capabilities of the cloud.
NetApp Cloud Volumes ONTAP: The Best of Both Worlds
For complex use cases and enterprise customers that require full control over their database Cloud SQL is not a viable option. The Compute Engine option provides much more flexibility and control, as well as lower cost, but is more challenging.
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP supports up to a capacity of 368TB, and supports various use cases such as file services, databases, DevOps, or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
NetApp Cloud Volumes ONTAP can help customers meet the performance, availability, and agility requirements of MySQL in a self-managed environment.
Cloud Volumes ONTAP allows you to leverage self-managed MySQL in Google Cloud with enterprise capabilities, achieving the following benefits:
- Run any version of MySQL
- No limitations on instances configuration, scalability, or storage volume
- No vendor lock-in
- No SLA limitations
- Pay only for actual resources used
- Full control over database configuration
- Full control over disaster recovery and data protection
In addition, NetApp Cloud Volumes ONTAP acts as a management layer on top of the Google Cloud deployment, achieving the following benefits:
- Enabling the usage of any MySQL version and any database engine.
- Intelligent caching capabilities to reduce latency whenever and wherever the data needs to be accessed.
- Data protection via instant, quiescent NetApp Snapshot™ copies which can enable point-in-time consistent backups and disaster recovery.
- Cost cutting storage efficiencies that can cut down storage footprint and cost by as much as 70%.
- Fast, seamless migration to Google Cloud from any repository with NetApp Cloud Sync or from NetApp appliances with SnapMirror®.
- Added IaC capabilities and management ease via the NetApp Cloud Manager console or API calls.
- FlexClone® data cloning technology makes it possible to clone entire database volumes instantly and without cost penalties.