This page describes a configuration that replicates data from a source database server to MySQL replicas. This configuration is sometimes referred to as an *external server* configuration. The source database server can be any MySQL server, including servers running on other Google Cloud services (such as Cloud SQL or Compute Engine) or on other cloud providers (such as Amazon RDS), if they meet the requirements. For step-by-step instructions for setting up this configuration, see [Replicating from an external server](https://docs.cloud.google.com/sql/docs/mysql/replication/configure-replication-from-external.md.txt). ## Use cases for external server configuration External server configuration helps you achieve the following goals: 1. Migrate your data from your self-managed MySQL server to Google Cloud with a minimum of downtime. 2. Retain colocation and control of your server while off-loading the administration of the replicas to Cloud SQL. This use case is sometimes called a *hybrid cloud*. Replication between your self-managed server and the Cloud SQL replica continues indefinitely. ## External replication configuration External replication configuration includes the following instances: - The MySQL server that you manage, also called the *source database server*. - The Cloud SQL replica. There can be multiple replicas for a single source database server. - The *source representation instance*. The source representation instance is a Cloud SQL instance that represents the source database server to the Cloud SQL replica. It is visible in the Google Cloud console and appears the same as a regular Cloud SQL instance, but it contains no data, requires no configuration or maintenance, and does not affect billing. The following diagram shows these instances: ![Diagram of the three instances making up an external replication configuration](https://docs.cloud.google.com/static/sql/images/external-master-2nd-gen.svg) ## SSL/TLS configuration Replicating from an external server requires that all changes to the data be sent between the source database server and the Cloud SQL replicas. If the connection is made over a public network (by using IP allowlists), Google recommend using SSL/TLS encryption for the connection between the source and destination databases. Cloud SQL offers the following options for SSL/TLS configuration: - None: the Cloud SQL destination instance connects to the source database without encryption. - [Server-only authentication](https://docs.cloud.google.com/sql/docs/mysql/replication/external-server.md.txt#server-only-authentication) - [Server-client authentication](https://docs.cloud.google.com/sql/docs/mysql/replication/external-server.md.txt#server-client-authentication)
> [!NOTE] > **Note:** For information about creating certificates and keys for your external server, see [Secure TCP/IP Connections with SSL](https://www.postgresql.org/docs/current/static/ssl-tcp.html). ### Server-only authentication When the replica connects to the primary instance, the replica authenticates the primary instance. This helps make sure the replica connects to the correct host and helps prevent on-path attacks. The primary instance doesn't authenticate the replica. To use server-only authentication, at replica creation time, provide the x509 PEM-encoded certificate of the certificate authority (CA) that signed the external server's certificate. The CA must contain only a single certificate, and it must be self signed. In other words, the Certificate Authority that signed the server's certificate must be a root CA. ### Server-client authentication When the replica connects to the primary instance, the replica authenticates the primary instance, which authenticates the replica. Server-client authentication provides the strongest security. However, if you don't want to provide the client certificate and private key when you create the replica, you can still use server-only authentication. To use server-client authentication, provide the following items when you create the replica: - The x509 PEM-encoded certificate of the CA that signed the source database server's certificate (`caCertificate`). - The x509 PEM-encoded certificate that will be used by the replica to authenticate against the source database server (`clientCertificate`). - The unencrypted [PKCS#1](https://tools.ietf.org/html/rfc3447) or [PKCS#8](https://tools.ietf.org/html/rfc5208) PEM-encoded private key associated with the `clientCertificate` (`clientKey`). ### External server SSL expiration notification If the external server's server CA certificate is expiring, then [rotate the SSL certificates](https://docs.cloud.google.com/sql/docs/mysql/manage-ssl-instance.md.txt), including the server CA certificate on the on-premises instance. For more information, see [Manage SSL/TLS certificates](https://docs.cloud.google.com/sql/docs/mysql/manage-ssl-instance.md.txt). ## Multiple replicas from the same database server You can create multiple replicas from the same source database server. You might want to provide more bandwidth or create replicas in different regions. If you're creating multiple replicas in the same region, they can all use the same source representation instance or different ones. If you use the Google Cloud console to create multiple replicas, they will have different source representation instances. If you're creating multiple replicas in different regions, they must have different source representation instances. You cannot create more than one replica in the same operation. As soon as you finish creating the replica configuration for the first replica, you can start [creating the replica configuration](https://docs.cloud.google.com/sql/docs/mysql/replication/configure-replication-from-external.md.txt#setup-replica-instance) for the other replicas. You don't need to wait until the first replica is completely functional before starting to create other replicas. ## Cascading replicas for an external server [Cascading read replicas](https://docs.cloud.google.com/sql/docs/mysql/replication.md.txt#cascading-replicas) let you create a read replica under another read replica in the same or different region. You can add up to four levels of cascading replicas, including the primary instance. When you promote the replica at the top of a cascading replica hierarchy, it becomes the primary instance and its cascading replicas continue to replicate. With external servers, you can create read replicas under an external server replica after migrating your data, but before promoting the external server replica to primary. This lets you test read replica topologies before the external server replica is promoted.