Networking methods

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

Overview

To create a migration in Database Migration Service, connectivity must be established between the source instance and the AlloyDB destination instance. There are various methods supported. Choose the one that works best for the specific workload.

Networking method	Description	Advantages	Disadvantages
Proxy via cloud-hosted VM - Reverse-SSH tunnel	Establishes connectivity from the destination to the source through a secure reverse SSH tunnel. Requires a bastion host VM in the Google Cloud Platform project as well as a machine (for example, a laptop on the network) that has connectivity to the source. Database Migration Service collects the required information at migration creation time, and auto-generates the script for setting it all up.	Easy to configure. Doesn't require any custom firewall configuration. Recommended for short-lived migration scenarios (POC or small database migrations).	The bastion VM is owned and managed by you, and may incur additional costs.
Proxy via cloud-hosted VM - TCP	Establishes connectivity from the destination to the source using a TCP proxy through a cloud hosted VM. Database Migration Service collects the required information at migration creation time, and auto-generates the script for setting it all up. Relevant on AlloyDB migrations where the source is on the old network architecture.	Easy to configure. Doesn't require any custom firewall configuration.	The bastion VM is owned and managed by you, and may incur additional costs.
VPC peering	This method works by configuring the VPCs to communicate with one another.	Native Google Cloud solution. Easy to configure. High bandwidth. Recommended for long-running or high-volume migrations.	Applicable if both the source and destination databases are hosted in Google Cloud, or if the source is connected to the destination VPC using a VPN (cloud-hosted or on-premises) or Cloud Interconnect.

Connectivity limitations

The PostgreSQL to AlloyDB connectivity has the following limitations:

• AlloyDB supports private connectivity using private services access. Assigning a public IP address to a cluster is not supported.
• You can't change the VPC with which the AlloyDB cluster is peered after the cluster is created.
• Because AlloyDB uses private services access which internally uses VPC peering, transitive peering isn't supported. Your AlloyDB cluster can only reach internal IP addresses in the same VPC with which it is peered. In order to reach other VPCs, you must use an intermediary proxy. For more details, see the following section.

Common connectivity scenarios and solutions

Migrate from a Cloud SQL instance in the old producer network architecture

Figure 1. A private connection facilitated by the TCP proxy VM (click to enlarge)

To migrate from a Cloud SQL for PostgreSQL instance in the old producer network architecture, you must establish connectivity using an intermediary proxy. This is because it isn't possible to have direct connectivity between the source Cloud SQL instance and the AlloyDB destination. You can set up your own proxy solution, although we recommend setting up the TCP proxy VM with the auto-generated script provided by Database Migration Service. See TCP proxy connectivity method.

Migrate from a source in the same Google Cloud project but in a different VPC

Because the VPC in which the AlloyDB cluster resides can't be changed after the cluster is created, you have the following options:

• The recommended option is to change the VPC of the source instance to match the VPC of the destination instance. For example, if you want to migrate a Cloud SQL instance to AlloyDB, update the Cloud SQL VPC to match the AlloyDB VPC.

  Caution: Configuring a private IP address for an existing Cloud SQL instance causes the instance to restart, resulting in downtime.

• If it's not possible to change the VPC of the source instance to match the VPC of the destination instance, then use an intermediary virtual machine (VM) as a proxy. You can set up your own proxy solution, although we recommend using the TCP proxy connectivity method. After Database Migration Service generates your script in the Google Cloud console, add another network interface to the command for creating a TCP proxy instance, and configure it to match the VPC of the source instance. This way, the proxy has connectivity to both the source and destination VPCs.

  To add another network interface, append --network-interface network=SOURCE_NETWORK_NAME to the gcloud compute instances create-with-container command that appears in the script.

  Note: For custom mode VPC networks, you have to explicitly specify the subnet. The argument you need to append is --network-interface network=SOURCE_NETWORK_NAME,subnet=SOURCE_SUBNET_NAME.

  An example command to create the proxy:

    gcloud compute instances create-with-container … \
    --network-interface subnet=DESTINATION-SUBNET-NAME \
    --network-interface network=SOURCE-NETWORK-NAME
  

  Replace the following:

  • DESTINATION-SUBNET-NAME: The name of the destination subnet.
  • SOURCE-NETWORK-NAME: The name of the source network.

For more information, see Create VM instances with multiple network interfaces.

Migrate over the public internet

Figure 2. A database connection over the public internet facilitated by the TCP proxy VM (click to enlarge)

This method is recommended when migrating from an on-premise instance or from other cloud providers, where there's no existing VPN or Interconnect connection to Google Cloud. Because an AlloyDB cluster has no public IP address, you must set up a proxy-based solution. We recommend using the TCP proxy connectivity method. The proxy is created with a network interface that resides in the AlloyDB VPC, and has a public IP address.

To use this method, you need to allowlist the public IP address of the proxy, so that the proxy can connect to the source database.

Migrate from a source in a different Google Cloud project

To migrate from a source in a different Google Cloud project, you must either migrate over the internet, or, for internal Google Cloud connectivity, use a shared VPC. Select one of the following options:

• Use a shared VPC without a proxy. If you want your AlloyDB cluster to reside in a shared VPC, then simply select the VPC where your source resides when creating the cluster. This way, source and destination have direct connectivity.

• Use a shared VPC with a proxy. If you don't want your AlloyDB cluster to reside in a shared VPC, then you must use an intermediary proxy. You can set up your own proxy solution, but we recommend using the TCP proxy connectivity method. Follow these guidelines to create a TCP proxy with an additional network interface on a shared VPC.

Migrate without allowing the destination to reach the network of the source

This method is recommended when migrating from an on-premise network, where there's a concern of opening the network's firewall to incoming Google Cloud traffic. For this scenario, you can set up a reverse proxy using a Compute Engine instance as an intermediary proxy. We recommend using the reverse SSH connectivity method.

Send feedback