Use a managed import to set up replication from external databases Stay organized with collections Save and categorize content based on your preferences.
This page describes how to set up and use a managed import for data whenreplicating from an external server to Cloud SQL.
You must complete all the steps on this page. When finished, you canadminister and monitor the source representation instance the same way as youwould any other Cloud SQL instance.
Before you begin
Before you begin, complete these steps:
Update privileges for the replication user
The replication user on the external server is configured toaccept connections from any host (%). Update this user accountso that it can be used only with the Cloud SQL replica.
Required privileges
There are four types of combinations of migrations and dumps.
- Type 1: Continuous migration and managed dump
- Type 2: Continuous migration and manual dump
- Type 3: One-time migration and managed dump
- Type 4: One-time migration and manual dump
The privileges for each type of migration and dumb combination are listed below.
Type 1
The user account must have the follow privileges:
- REPLICATION SLAVE
- EXECUTE
- SELECT
- SHOW VIEW
- REPLICATION CLIENT
- RELOAD
- TRIGGER
- (For migrating from Amazon RDS and Amazon Aurora only)LOCK TABLES
For MySQL version 8.0 and above, it's recommend to skip theBACKUP ADMIN privilegefor optimal performance.
Type 2
The user account must have the follow privileges:
Note: For more information about these privileges,seePrivileges provided by MySQL.Type 3
The user account must have the follow privileges:
For MySQL version 8.0 and above, it's recommend to skip theBACKUP ADMIN privilegefor optimal performance.
Type 4
No privileges are required.
Note: For more information about these privileges,seePrivileges provided by MySQL.Update privileges
To update privileges, open a terminal on the external server and enter the following commands.
mysql Client
For GTID:
UPDATEmysql.userSETHost='NEW_HOST'WHEREHost='OLD_HOST'ANDUser='USERNAME';GRANTREPLICATIONSLAVE,EXECUTE,SELECT,SHOWVIEW,REPLICATIONCLIENT,RELOADON.TO'USERNAME'@'HOST';FLUSHPRIVILEGES;
For binlog:
UPDATEmysql.userSETHost='NEW_HOST'WHEREHost='OLD_HOST'ANDUser='USERNAME';GRANTREPLICATIONSLAVE,EXECUTE,SELECT,SHOWVIEW,REPLICATIONCLIENT,RELOADON.TO'GCP_USERNAME'@'HOST';FLUSHPRIVILEGES;
example
UPDATEmysql.userSETHost='192.0.2.0'WHEREHost='%'ANDUser='replicationUser';GRANTREPLICATIONSLAVE,EXECUTE,SELECT,SHOWVIEW,REPLICATIONCLIENT,RELOADON*.*TO'username'@'host.com';FLUSHPRIVILEGES;| Property | Description |
|---|---|
| NEW_HOST | Specify theoutgoing IP of theCloud SQL replica. |
| OLD_HOST | The current value assigned toHost that you wantto change. |
| USERNAME | The replication user account on the external server. |
| GCP_USERNAME | The username for the user account. |
| HOST | The hostname for the user account. |
Verify your replication settings
After your setup is complete, ensure that the Cloud SQL replicacan replicate from the external server.
The following external sync settings must be correct.
- Connectivity between the Cloud SQL replica and external server
- Replication user privileges
- Version compatibility
- The Cloud SQL replica is not already replicating
- Binlogs are enabled on the external server
- GTID is enabled if you are trying to do an external sync from anRDS external server and are using a Google Cloud bucket
To verify these settings, open a Cloud Shell terminal and enter the followingcommands:
curl
gcloud auth loginACCESS_TOKEN="$(gcloud auth print-access-token)"curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data '{ "syncMode": "SYNC_MODE", "syncParallelLevel": "SYNC_PARALLEL_LEVEL", "mysqlSyncConfig": { "initialSyncFlags": "SYNC_FLAGS" } }' \ -X POST \ https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettingsexample
gcloudauthloginACCESS_TOKEN="$(gcloud auth print-access-token)"curl--header "Authorization: Bearer ${ACCESS_TOKEN}" \--header 'Content-Type: application/json' \--data '{"syncMode":"online","syncParallelLevel":"optimal"}'\-XPOST\https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettingsexample w/ sync flags
gcloudauthloginACCESS_TOKEN="$(gcloud auth print-access-token)"curl--header "Authorization: Bearer ${ACCESS_TOKEN}" \--header 'Content-Type: application/json' \--data '{"syncMode":"online","syncParallelLevel":"optimal""mysqlSyncConfig":{"initialSyncFlags":[{"name":"max-allowed-packet","value":"1073741824"},{"name":"hex-blob"},{"name":"compress"}]}}'\-XPOST\https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettingsThese calls return a list of typesql#externalSyncSettingErrorList.
If the list is empty, then there are no errors. A response without errors appears like this:
{"kind":"sql#externalSyncSettingErrorList"}
| Property | Description |
|---|---|
| SYNC_MODE | Ensure that you can keep the Cloud SQL replica and the external serverin sync after replication is set up. Sync modes includeEXTERNAL_SYNC_MODE_UNSPECIFIED,ONLINE, andOFFLINE. |
| SYNC_PARALLEL_LEVEL | Verify the setting that controls the speed at which data from tables of a database are transferred. The following values are available:
Note: The default value for this parameter is |
| SYNC_FLAGS | A list of initial sync flags to verify. Only recommended if you plan on using custom sync flags when replicating from the source. For a list of allowed flags, seeInitial sync flags. |
| PROJECT_ID | The ID of your Google Cloud project. |
| REPLICA_INSTANCE_ID | The ID of your Cloud SQL replica. |
Global read lock permission
If you don't have permission to access the global read lock on the externalserver, as might be the case with Amazon RDS and Amazon Aurora, pause writesto your server as described in the following steps:
- Go to theLogs Explorer, and select your Cloud SQL replica from the resource list. You should see a list of the most recent logs for your Cloud SQL replica. Ignore them for now.
- Open a terminal and enter the commands inStart replication on the external server to replicate from the external server.
Return to the Logs Explorer. When you see the log as follows, stop writing to the database on your external server. In most cases, this is required only for a few seconds.
DUMP_IMPORT(START):Startimportingdata,pleasepauseanywritetotheexternalprimarydatabase.When you see the following log entry in Logs Explorer, re-enable writing to the database on your external server.
DUMP_IMPORT(SYNC):Consistentstateonprimaryandreplica.Writestotheexternalprimarymayresume.
Start replication on the external server
After verifying that you can replicate from the external server, start the replication. The speed for performing the replication for the initial import process is up to 500 GB per hour. However, this speed can vary based on the machine tier, data disk size, network throughput, and nature of your database.
Caution: When you initiate an import from a database on a managed service, suchas Amazon RDS or Amazon Aurora, Cloud SQL instructs you to stop writesfor a few seconds so that the data dump is consistent. To avoid downtime for writesto your managed service primary instance, you can select a read replica as yourreplication source instead of the primary instance. During the phase whenstopping writes is required, you can temporarily stop replication to the sourceread replica and then resume replication once the stop writes phase is over.During the initial import process, do not perform anyDDL operations on the external server.Doing so could cause inconsistencies during the import. After the importprocess completes, the replica uses the binary logs on theexternal server to catch up to the current state of theexternal server.
curl
gcloud auth loginACCESS_TOKEN="$(gcloud auth print-access-token)"curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \ --header 'Content-Type: application/json' \ --data '{ "syncMode": "SYNC_MODE", "skipVerification": "SKIP_VERIFICATION", "syncParallelLevel": "SYNC_PARALLEL_LEVEL", "mysqlSyncConfig": { "initialSyncFlags": "SYNC_FLAGS" } }' \ -X POST \ https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSyncexample
gcloudauthloginACCESS_TOKEN="$(gcloud auth print-access-token)"curl--header "Authorization: Bearer ${ACCESS_TOKEN}" \--header 'Content-Type: application/json' \--data '{"syncMode":"online","syncParallelLevel":"optimal"}'\-XPOST\https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSyncexample w/ sync flags
gcloudauthloginACCESS_TOKEN="$(gcloud auth print-access-token)"curl--header "Authorization: Bearer ${ACCESS_TOKEN}" \--header 'Content-Type: application/json' \--data '{"syncMode":"online","syncParallelLevel":"optimal""skipVerification":false,"mysqlSyncConfig":{"initialSyncFlags":[{"name":"max-allowed-packet","value":"1073741824"},{"name":"hex-blob"},{"name":"compress"}]}}'\-XPOST\https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync| Property | Description |
|---|---|
| SYNC_MODE | Verify that you can keep the Cloud SQL replica and the external serverin sync after replication is set up. |
| SKIP_VERIFICATION | Whether to skip the built-in verification step before syncing your data. This parameter is recommended only if you have alreadyverified your replication settings. |
| SYNC_PARALLEL_LEVEL | Provide a setting that controls the speed at which data from tables of a database are transferred. The following values are available:
Note: The default value for this parameter is |
| SYNC_FLAGS | A list of initial sync flags to verify. Only recommended if you plan on using custom sync flags when replicating from the source. For a list of allowed flags, seeInitial sync flags. |
| PROJECT_ID | The ID of your Google Cloud project. |
| REPLICA_INSTANCE_ID | The ID of your Cloud SQL replica. |
Initial sync flags
To migrate with custom database flags, you can use the following allowed flags:
- --add-drop-database
- --add-drop-table
- --add-drop-trigger
- --add-locks
- --allow-keywords
- --all-tablespaces
- --apply-slave-statements
- --column-statistics
- --comments
- --compact
- --compatible
- --complete-insert
- --compress
- --compression-algorithms
- --create-options
- --default-character-set
- --delayed-insert
- --disable-keys
- --dump-date
- --events
- --extended-insert
- --fields-enclosed-by
- --fields-escaped-by
- --fields-optionally-enclosed-by
- --fields-terminated-by
- --flush-logs
- --flush-privileges
- --force
- --get-server-public-key
- --hex-blob
- --ignore-error
- --ignore-read-lock-error
- --ignore-table
- --insert-ignore
- --lines-terminated-by
- --lock-all-tables
- --lock-tables
- --max-allowed-packet
- --net-buffer-length
- --network-timeout
- --no-autocommit
- --no-create-db
- --no-create-info
- --no-data
- --no-defaults
- --no-set-names
- --no-tablespaces
- --opt
- --order-by-primary
- --pipe
- --quote-names
- --quick
- --replace
- --routines
- --secure-auth
- --set-charset
- --shared-memory-base-name
- --show-create-skip-secondary-engine
- --skip-opt
- --ssl-cipher
- --ssl-fips-mode
- --ssl-verify-server-cert
- --tls-ciphersuites
- --tls-version
- --triggers
- --tz-utc
- --verbose
- --xml
- --zstd-compression-level
For allowed values, see theMySQL public docs.
Monitor the migration
Once you start replication from the external server, you need to monitorreplication. To learn more, seeMonitoring replication.You can then complete your migration.
Troubleshoot
Consider the following troubleshooting options:
| Issue | Troubleshooting |
|---|---|
| Read replica didn't start replicating on creation. | There's probably a more specific error in the log files.Inspect the logs in Cloud Logging to find the actual error. |
| Unable to create read replica - invalidFlagValue error. | One of the flags in the request is invalid. It could be a flag you provided explicitly or one that was set to a default value. First, check that the value of the If the |
| Unable to create read replica - unknown error. | There's probably a more specific error in the log files.Inspect the logs in Cloud Logging to find the actual error. If the error is: |
| Disk is full. | The primary instance disk size can become full during replica creation. Edit the primary instance to upgrade it to a larger disk size. |
| The replica instance is using too much memory. | The replica uses temporary memory to cache often-requested read operations, which can lead it to use more memory than the primary instance. Restart the replica instance to reclaim the temporary memory space. |
| Replication stopped. | The maximum storage limit was reached and automatic storage increase isn't enabled. Edit the instance to enable |
| Replication lag is consistently high. | The write load is too high for the replica to handle. Replication lag takes place when the SQL thread on a replica is unable to keep up with the IO thread. Some kinds of queries or workloads can cause temporary or permanent high replication lag for a given schema. Some of the typical causes of replication lag are:
Some possible solutions include:
|
| Replication lag suddenly spikes. | This is caused by long-running transaction(s). When a transaction (single statement or multi-statements) commits on the source instance, the start time of the transaction is recorded in the binary log. When the replica receives this binlog event, it compares that timestamp with the current timestamp to calculate replication lag. Hence, a long-running transaction on the source would result in an immediate large replication lag on the replica. If the amount of row changes in the transaction is large, the replica would also spend a long time to execute it. During the time, replication lag is increasing. Once the replica finishes this transaction, the catch up period would depend on the write workload on the source and the replica's processing speed. To avoid a long transaction, some possible solutions include:
|
| Changing parallel replication flags results in an error. | An incorrect value is set for one of or more of these flags. On the primary instance that's displaying the error message, set the parallel replication flags:
|
| Replica creation fails with timeout. | Long-running uncommitted transactions on the primary instance can cause read replica creation to fail. Recreate the replica after stopping all running queries. |
Additionally, for MySQL, also consider the following options:
| Issue | Troubleshooting |
|---|---|
Lost connection to MySQL server during query when dumping table. | The source may have become unavailable, or the dump contained packets too large. Make sure the external primary is available to connect. You can also modify the values of thenet_read_timeout andnet_write_timeout flags on the source instance to stop the error. For more information on the allowable values for these flags, seeConfigure database flags. To learn more about using |
| The initial data migration was successful, but no data is being replicated. | One possible root cause could be your source database has defined replication flags which result in some or all database changes not being replicated over. Make sure the replication flags such as Run the command |
| The initial data migration was successful but data replication stops working after a while. | Things to try:
|
mysqld check failed: data disk is full. | The data disk of the replica instance is full. Increase the disk size of the replica instance. You can either manually increase the disk size or enable auto storage increase. |
Review your replication logs
When youverify your replication settings, logs areproduced.
You can view these logs by following these steps:
Go to the Logs Viewer in the Google Cloud console.
- Select the Cloud SQL replica from theInstance dropdown.
- Select the
replication-setup.loglog file.
If the Cloud SQL replica is unable to connect to the external server,confirm the following:
- Any firewall on the external server is configured to allow connections from the Cloud SQL replica'soutgoing IP address.
- Your SSL/TLS configuration is correct.
- Your replication user, host, and password are correct.
What's next
- Learn aboutupdating an instance.
- Learn aboutmanaging replicas.
- Learn aboutmonitoring instances.
- Learn aboutpromoting your Cloud SQL replica.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-15 UTC.