Google Cloud MySQL

Last updated on Jul 03, 2025

Prerequisites
Create a Read Replica (Optional)
Set up MySQL Binary Logs for Replication
- 1. Check if BinLog replication is already enabled
- 2. Enable BinLog replication and configure the BinLog retention period
Whitelist Hevo’s IP Addresses
Create a Database User and Grant Privileges
- 1. Create a database user (Optional)
- 2. Grant privileges to the database user
Retrieve the Configuration Details (Optional)
Specify Google Cloud MySQL Connection Settings
Object and Query Mode Settings
Data Replication
Source Considerations
Limitations
Revision History

Google Cloud SQL offers MySQL as a fully-managed web service. You can use Google Cloud SQL to host your MySQL database in Google Cloud Platform, and let Google Cloud handle administrative tasks such a replication, patch management, and database management for it.

You can ingest data from your Google Cloud MySQL database using Hevo Pipelines and replicate it to a Destination of your choice.

Getting Started

Setup

Data Sync

Prerequisites

The Google Cloud MySQL instance is running. To check this, access your Google Cloud MySQL server and look for an Active indication next to the instance name.

The Google Cloud MySQL server version is within the supported range for the selected ingestion mode:

Ingestion Mode	Supported Version
BinLog	5.5 - 8.0
Table or Custom SQL	5.5 - 8.4

Binary Log (BinLog) replication is enabled if ingestion mode is BinLog.
Hevo’s IP addresses are whitelisted.
The SELECT and REPLICATION privileges are granted to the database user.
The username, password, database names, database hostname, and port number of the Source instance are available.
You are assigned the Team Administrator, Team Collaborator, or Pipeline Administrator role in Hevo, to create the Pipeline.

Perform the following steps to configure your Google Cloud MySQL Source:

Create a Read Replica (Optional)

If you are using an existing read-replica or connecting Hevo to your master database, skip to Set up MySQL Binary Logs for Replication section.

To create a read-replica:

Log in to the Google Cloud Console.
Access the Google Cloud SQL Instances page and click your Instance ID.
In the left navigation pane, click Replicas, and then click + CREATE READ REPLICA.
Specify the instance information relevant to your requirements, and then click CREATE REPLICA.

Set up MySQL Binary Logs for Replication

A binary log is a collection of log files that records information about data modifications and data object modifications made on a MySQL server instance. Typically binary logs are used for data replication and data recovery.

Hevo supports data ingestion for replication from servers via binary logs (BinLog). For this, binary logging must be enabled on your Google Cloud MySQL server.

To do this:

1. Check if BinLog replication is already enabled

Access your Google Cloud MySQL instance.
In the left navigation pane, under Databases, select Backups.
Under Settings, check the status of Automated backups.
If the status is Disabled, follow the steps provided below to enable BinLog replication. If the status is Enabled, ensure that the BinLog retention period is set to at least 3 days by following the steps provided below.

2. Enable BinLog replication and configure the BinLog retention period

In the left navigation pane, click Overview, and then click EDIT.
Scroll down to the Data Protection panel and select the Automated daily backups and Enable point-in-time recovery check boxes.
In the Flags panel, click ADD A DATABASE FLAG.
Click the Choose a flag field, and from the drop-down list, search and select the expire_logs_days flag.
Set the Value to at least 3 days, and then click DONE.

Note: If you are using MySQL version 8.0 or higher, search for binlog_expire_logs_seconds and set the Value greater than or equal to 259200 (three days).
Click SAVE.

This confirms that binary logging is now enabled for your Google Cloud MySQL instance.

Read BinLog to understand how database replication works in MySQL.

The replication reference guide on MySQL’s documentation portal provides a complete reference of the options available for replication and binary logging.

Whitelist Hevo’s IP Addresses

You need to whitelist the Hevo IP address for your region to enable Hevo to connect to your Google Cloud MySQL database:

Access the Google Cloud MySQL Instances page and click on the Instance ID that you want to use.
In the left navigation pane, click Connections.
On the Connections page, do the following:
1. Go to the NETWORKING tab.
2. Click the Public IP check box.
3. Click the ADD A NETWORK and specify the following:
  - Name: A name for this connection. For example, all or Hevo IP address.
  - Network: The IP address of the site to grant access to. Specify 0.0.0.0/0 to authorize all sites or 10.2.7.152 to specifically whitelist Hevo’s IP address. Check the Hevo IP address for your region.
4. Click DONE.
This adds the IP address to the list of Authorized networks.
(Optional) Click Add A NETWORK to add another IP address.
Click SAVE.

Create a Database User and Grant Privileges

1. Create a database user (Optional)

We recommend creating a database user for connecting to your Google Cloud MySQL Source in Hevo. However, if you already have one, proceed to grant privileges to the database user.

You can add a database user to your Google Cloud MySQL instance in one of the following ways:

- Add a user account from the Google Cloud console

Log in to the Google Cloud console and access the Cloud SQL Instances page.
On the Instances page, click the Instance ID of your MySQL instance.
In the left navigation pane, under Primary instance, select Users, and then click + ADD USER ACCOUNT.
In the Add a user account to instance window, select one of the methods to authenticate your user to access the instance:
- Built-in authentication: This method authenticates database users with a username and password. Specify a name for your database user and the password for it.
  - Host name: The IP address or domain name from which client hosts can connect to your instance with this user account. Default value: Allow any host (%).
  Note: For MySQL 8.4 and above, the built-in authentication is caching_sha2_password, which Hevo does not currently support. Read Limitations for more information.
- Cloud IAM: This method uses an IAM principal that provides access to the required resources in your Google Cloud MySQL instance.
Click ADD.

- Add a user account using a MySQL client

Connect to your Google Cloud MySQL database as a root user with an SQL client tool, such as MySQL Workbench.
Run the following command to create a database user in MySQL versions 5.6 up to 8.0.4
```
CREATE USER '<database_username>'@'%' IDENTIFIED WITH mysql_native_password BY '<password>';
```
Note:
- Replace the placeholder values in the command above with your own. For example, <database_username> with hevouser.
- For versions 8.4 and above, Google Cloud MySQL does not allow adding new users with the mysql_native_password plugin. You can only alter existing users. Read Limitations for more information.

You can specify this username and password while creating your Hevo Pipeline.

2. Grant privileges to the database user

The database user specified in the Hevo Pipeline must have the following global privileges:

SELECT
SUPER or (REPLICATION CLIENT and REPLICATION SLAVE)

Perform the following steps to set up these privileges:

Connect to your Google Cloud MySQL database as a root user with an SQL client tool, such as MySQL Workbench.
Grant SELECT and REPLICATION privileges to the user:
```
GRANT SELECT, REPLICATION CLIENT, REPLICATION SLAVE ON . TO '<database_username>'@'%';
```
Note:
- Replace the placeholder values in the commands above with your own. For example, <database_username> with hevouser.
- The REPLICATION SLAVE privilege is required only if you want to connect to a read replica. When this privilege is granted to the database user, the replica writes any updates received from the primary database into its log, maintaining a record of those changes in the log.

Retrieve the Configuration Details (Optional)

1. Retrieve the hostname and port number

Note: The hostname of a Google Cloud MySQL instance is an IP address.

For example:
Host: 35.220.150.0
Port: 3306

Access the Google Cloud SQL Instances page.
Locate the hostname of the master and the replica instance under Public IP address column.

The Google Cloud MySQL port number is 3306 by default.

You will specify these while creating your Hevo Pipeline.

2. Retrieve the username and password

To retrieve your username and password, or create a new user to connect to Hevo, read Create a User and Grant Privileges.

3. Retrieve the database names

Access the Google Cloud SQL Instances page and click on the Instance ID that you want to use.
In the left navigation pane, click Databases. On this page, you can locate the name of the databases.

Specify Google Cloud MySQL Connection Settings

Perform the following steps to configure Google Cloud MySQL as a Source in Hevo:

Click PIPELINES in the Navigation Bar.
Click + CREATE PIPELINE in the Pipelines List View.
On the Select Source Type page, select Google Cloud MySQL.

On the Configure your Google Cloud MySQL Source page, specify the following:

GCloud MySQL settings

Pipeline Name: A unique name for your Pipeline, not exceeding 255 characters.

Database Host: The MySQL host’s IP address or DNS.

The following table lists a few examples of MySQL hosts:

Variant	Host
Amazon RDS MySQL	mysql-rds-1.xxxxx.rds.amazonaws.com
Azure MySQL	mysql.database.windows.net
Generic MySQL	10.123.10.001 or mysql-replica.westeros.inc
Google Cloud MySQL	35.220.150.0

Note: For URL-based hostnames, exclude the http:// or https:// part. For example, if the hostname URL is http://mysql-replica.westeros.inc, enter mysql-replica.westeros.inc.

Database Port: The port on which your Google Cloud MySQL server listens for connections. Default value: 3306.
Database User: The authenticated user who has the permissions to read tables in your database.
Database Password: The password for the database user.
Select an Ingestion Mode: The desired mode by which you want to ingest data from the Source. You can expand this section by clicking SEE MORE to view the list of ingestion modes to choose from. Default value: BinLog. The available ingestion modes are BinLog, Table, and Custom SQL.

Depending on the ingestion mode you select, you must configure the objects to be replicated. Refer to section, Object and Query Mode Settings for the steps to do this.

Note: For Custom SQL ingestion mode, all Events loaded to the Destination are billable.
Database Name: The database you want to load data from if the Pipeline mode is Table or Custom SQL.
Connection Settings
- Connect through SSH: Enable this option to connect to Hevo using an SSH tunnel, instead of directly connecting your MySQL database host to Hevo. This provides an additional level of security to your database by not exposing your MySQL setup to the public. Read Connecting Through SSH.
  
  If this option is disabled, you must whitelist Hevo’s IP addresses. Refer to the content for your MySQL variant for steps to do this.
- Use SSL: Enable it to use SSL encrypted connection. To enable this, specify the following:
  - CA File: The file containing the SSL server certificate authority (CA).
    - Load all CA Certificates: If selected, Hevo loads all CA certificates (up to 50) from the uploaded CA file, else it loads only the first certificate.
    Note: Select this check box if you have more than one certificate in your CA file.
  - Client Certificate: The client public key certificate file.
  - Client Key: The client private key file.
Advanced Settings
- Load All Databases: This option applies to log-based Pipelines. If enabled, Hevo loads the data from all databases on the selected host and fetches the schema for all the tables within these databases. If disabled, specify a comma-separated list of database names from which you want to load data. Hevo fetches the schema of tables only from the specified databases.
  
  Note:
  - Hevo cannot access or read any tables that are not part of databases active in the Pipeline.
  - Hevo requires read access to the specified databases.
  - If access is restricted to certain databases, Hevo fetches the schema only of tables within those databases. For example, if Load All Databases option is enabled, but Hevo has permission to access only one database, it cannot fetch schemas from the others. This may lead to issues when the data required for queries or Transformations resides outside the accessible database. To avoid such cases, ensure that Hevo has permission to access all active databases.
- Load Historical Data: Applicable for Pipelines with BinLog mode. If this option is enabled, the entire table data is fetched during the first run of the Pipeline. If disabled, Hevo loads only the data that was written in your database after the time of creation of the Pipeline.
- Merge Tables: Applicable for Pipelines with BinLog mode. If this option is enabled, Hevo merges tables with the same name from different databases while loading the data to the warehouse. Hevo loads the Database Name field with each record. If disabled, the database name is prefixed to each table name. Read How does the Merge Tables feature work?.
- Include New Tables in the Pipeline: Applicable for all ingestion modes except Custom SQL.
  
  If enabled, Hevo automatically ingests data from tables created in the Source after the Pipeline has been built. These may include completely new tables or previously deleted tables that have been re-created in the Source.
  
  If disabled, new and re-created tables are not ingested automatically. They are added in SKIPPED state in the objects list, on the Pipeline Overview page. You can update their status to INCLUDED to ingest data. You can include these objects post-Pipeline creation to ingest data.
  
  You can change this setting later.

Click TEST CONNECTION. This button is enabled once you specify all the mandatory fields. Hevo’s underlying connectivity checker validates the connection settings you provide.
Click TEST & CONTINUE to proceed for setting up the Destination. This button is enabled once you specify all the mandatory fields.

Object and Query Mode Settings

Once you have specified the Source connection settings in Step 6 above, do one of the following:

For Pipelines with Table or BinLog mode:
1. On the Select Objects page, select the objects you want to replicate and click CONTINUE.
  
  Note: Each object represents a table in your database.
2. On the Configure Objects page, specify the query mode you want to use for each selected object.
For Pipelines with Custom SQL mode:
1. On the Provide Query Settings page, enter the custom SQL query to fetch data from the Source.
2. In the Query Mode drop-down, select the query mode, and click CONTINUE.

Data Replication

For Teams Created	Ingestion Mode	Default Ingestion Frequency	Minimum Ingestion Frequency	Maximum Ingestion Frequency	Custom Frequency Range (in Hrs)
Before Release 2.21	Table	15 Mins	15 Mins	24 Hrs	1-24
	Log-based	5 Mins	5 Mins	1 Hr	NA
After Release 2.21	Table	6 Hrs	30 Mins	24 Hrs	1-24
	Log-based	30 Mins	30 Mins	12 Hrs	1-24

Note: The custom frequency must be set in hours as an integer value. For example, 1, 2, or 3 but not 1.5 or 1.75.

Historical Data: In the first run of the Pipeline, Hevo ingests all available data for the selected objects from your Source database.
Incremental Data: Once the historical load is complete, data is ingested as per the ingestion frequency.

Additional Information

Read the detailed Hevo documentation for the following related topics:

Source Considerations

MySQL does not generate log entries for cascading deletes. So, Hevo cannot capture these deletes for log-based Pipelines.
In log-based Pipelines, when a new column with default values is added to the Source table, the database does not generate log entries for it, as it is not treated as a row-level data change. As a result, Hevo cannot replicate this column to the Destination. To ensure that the Source schema and data are reflected accurately in the Destination, you must restart the historical load for that object.
If your Pipeline uses BinLog ingestion mode, MySQL replicates timestamp fields such as created_at and updated_at in Coordinated Universal Time (UTC). As BinLogs do not include time zone metadata, Hevo and the Destination interpret these values in UTC. Due to this, you may observe a time difference if the Source database uses a different timezone. For example, if the Source timezone is US Eastern Time (UTC-4) and the timestamp for created_at in MySQL is 2024-05-01 10:00:00, it appears as 2024-05-01 14:00:00 in BigQuery. This behavior applies only to incremental loads via BinLogs. Any data replicated using historical load retains the original timestamp values from the Source.

As a workaround, you can adjust the UTC timestamps to your local timezone using Python code-based Transformations by adding or subtracting the appropriate offset in the timestamp fields. For example, to convert UTC to UTC+7, add a 7-hour offset to the relevant fields before loading the data into the Destination.

Limitations

For Cloud SQL MySQL versions 8.4 and above, database users are authenticated using the caching_sha2_password plugin by default. However, Hevo does not currently support this plugin, and you may see the Public Key Retrieval is not allowed error. In that case, you can change the authentication plugin to mysql_native_password for the user.

To do this, connect to your MySQL server as a root user and run the following command:
```
ALTER USER '<database_username>'@'%' IDENTIFIED WITH mysql_native_password BY '<password>';
```
Note: Replace the placeholder values in the command above with your own. For example, <database_username> with hevouser.
Currently, Hevo does not support transaction-based replication using Global Transaction Identifiers (GTIDs).
Hevo only fetches tables from the MySQL database. It does not fetch other entities such as functions, stored procedures, views, and triggers.

To fetch views, you can create individual Pipelines in Custom SQL mode. However, some limitations may arise based on the type of data synchronization, the query mode, or the number of Events. Contact Hevo Support for more details.
During the historical load, Hevo reads table definitions directly from the MySQL database schema, whereas for incremental updates, Hevo reads from the BinLog. As a result, certain fields, such as nested JSON, are parsed differently during historical and incremental loads. In the Destination tables, nested JSON fields are parsed as a struct or JSON during historical loads, but as a string during incremental loads. This leads to a data type mismatch between the Source and Destination data, causing Events to be sidelined.

To ensure JSON fields are parsed correctly during the historical load, you can apply transformations to every table containing nested JSON fields. Contact Hevo Support for more details.
Hevo Pipelines may fail to process transactions in the BinLog if the size of the transaction exceeds 4GB. This problem is due to a MySQL bug that affects the library used by Hevo to stream Events, resulting in ingestion failures. In such cases, Hevo attempts to restart the ingestion process from the beginning of the transaction, skipping already processed Events. If the problem of transaction processing persists and the BinLog remains stuck, contact Hevo Support for assistance.
Hevo does not load data from a column into the Destination table if its size exceeds 16 MB, and skips the Event if it exceeds 40 MB. If the Event contains a column larger than 16 MB, Hevo attempts to load the Event after dropping that column’s data. However, if the Event size still exceeds 40 MB, then the Event is also dropped. As a result, you may see discrepancies between your Source and Destination data. To avoid such a scenario, ensure that each Event contains less than 40 MB of data.

Revision History

Refer to the following table for the list of key updates made to this page:

Date	Release	Description of Change
Jul-07-2025	NA	- Updated section, Source Considerations to add information about columns with default values not being replicated. - Updated the Limitations section to inform about the max record and column size in an Event.
Jun-30-2025	NA	Updated section, Source Considerations to add a point about UTC replication of timestamp fields in BinLog mode.
Jun-23-2025	NA	- Renamed sections Option 1. Configuring the user account using Google Cloud console to Add a user account from the Google Cloud console and Option 2. Configuring the user account using MySQL client to Add a user account using a MySQL client - Updated the Create a database user section to add the commands for creating a user with the `mysql_native_password` authentication. - Created the subsection Grant privileges to the database user. - Added a limitation about Hevo not supporting the `caching_sha2_password` authentication plugin.
May-19-2025	NA	Updated section, Limitations to add note about GTID based replication.
Mar-13-2025	NA	Updated section, Prerequisites to mention the supported MySQL versions for each ingestion mode.
Jan-20-2025	NA	Added a note for Load All Databases in the Pipeline Advanced Settings in the Specify Google Cloud MySQL Connection Settings section.
Jan-07-2025	NA	Updated the Limitations section to add information on Event size.
Dec-18-2024	NA	Updated the section, Limitations to add information about Hevo handling transaction failures in the BinLog due to a MySQL bug affecting transactions exceeding 4GB.
Nov-18-2024	NA	Renamed sub-section Enable BinLog replication to Enable BinLog replication and configure the Binlog retention period and added steps for configuring the BinLog retention period.
Jul-31-2024	NA	Updated section, Limitations to add information about Hevo reading table definitions differently during historical and incremental loads.
Apr-29-2024	NA	Updated section, Specify Google Cloud MySQL Connection Settings to include more detailed steps.
Mar-18-2024	2.21.2	Updated section, Specify Google Cloud MySQL Connection Settings to add information about the Load all CA certificates option.
Mar-05-2024	2.21	Added the Data Replication section.
Nov-03-2023	NA	Renamed section, Object Settings to Object and Query Mode Settings.
Oct-27-2023	NA	Updated subsection, Configuring the user account using MySQL client with the latest steps.
Sep-04-2023	NA	Updated the page contents to reflect the latest Google Cloud MySQL user interface (UI).
Jun-26-2023	NA	Added section, Source Considerations.
Apr-21-2023	NA	Updated section, Specify Google Cloud MySQL Connection Settings to add a note to inform users that all loaded Events are billable for Custom SQL mode-based Pipelines.
Mar-09-2023	2.09	Updated section, Specify Google Cloud MySQL Connection Settings to mention about SEE MORE in the Select an Ingestion Mode section.
Dec-19-2022	2.04	Updated section, Specify Google Cloud MySQL Connection Settings to add information that you must specify all fields to create a Pipeline.
Dec-07-2022	2.03	Updated section, Specify Google Cloud MySQL Connection Settings to mention about including skipped objects post-Pipeline creation.
Dec-07-2022	2.03	Updated section, Specify Google Cloud MySQL Connection Settings to mention about the connectivity checker.
Nov-03-2022	NA	Updated section, Create a Read Replica with new screenshots to reflect the latest UI.
Oct-13-2022	1.99	Updated section, Specify Google Cloud MySQL Connection Settings to reflect the latest UI changes.
Apr-21-2022	1.86	Updated section, Specify Google Cloud MySQL Connection Settings.
Aug-09-2021	NA	Added a note in section, Option 2 Configuring the user account using MySQL client.
Jul-26-2021	1.68	Added a note for the Database Host field.
Jul-12-2021	NA	Added section, Specify Google Cloud MySQL Connection Settings.