To use Database Migration Service to migrate data from the source database to the destination database, you must establish connectivity between the databases.
Source connectivity
Database Migration Service supports the IP allowlist, forward SSH tunnel, and VPC peering network connectivity methods.
Use the information in the following table to help you decide which method works best for you for your specific workload.
| Networking method | Description | Pros | Cons |
|---|---|---|---|
| IP allowlist | Works by configuring the source database server to allow incoming connections from Database Migration Service's public IP addresses. |
|
|
| Forward SSH tunnel |
Establish an encrypted connection over public networks between Database Migration Service and the source, through a forward-SSH tunnel. Learn more about SSH tunnels. |
|
|
| VPC peering | Works by creating a private connectivity configuration. Database Migration Service uses this configuration to communicate with the data source over a private network. This communication happens through a Virtual Private Cloud (VPC) peering connection. |
|
|
Destination connectivity
Use Private Service Connect to establish private connectivity to your AlloyDB for PostgreSQL destination database.
Configure connectivity using IP allowlists
For Database Migration Service to transfer data from a source database to a destination, Database Migration Service first needs to connect to this database.
One way to configure this connectivity is through IP allowlists. Public IP connectivity is most appropriate when the source database is external to Google Cloud and has an externally accessible IPv4 address and TCP port.
If your source database is external to Google Cloud, then add Database Migration Service's public IP addresses as an inbound firewall rule on the source network. In generic terms (your specific network settings may differ), do the following:
Open your source database machine's network firewall rules.
Create an inbound rule.
Set the IP address of the source database to Database Migration Service's IP addresses.
Set the protocol to
TCP.Set the port associated with the
TCPprotocol to1521.Save the firewall rule, and then exit.
Use an SSH tunnel
Step 1: Choose a host on which to terminate the tunnel
The first step to set up SSH tunnel access for your database is to choose the host that will be used to terminate the tunnel. The tunnel can be terminated on either the database host itself, or on a separate host (the tunnel server).
Use the database server
Terminating the tunnel on the database has the advantage of simplicity. There's one fewer host involved, so there are no additional machines and their associated costs. The disadvantage is that your database server may be on a protected network that doesn't have direct access from the internet.
Use a tunnel server
Terminating the tunnel on a separate server has the advantage of keeping your database server inaccessible from the internet. If the tunnel server is compromised, then it's one step removed from the database server. We recommend that you remove all non-essential software and users from the tunnel server and closely monitor it with tools, such as an intrusion detection system (IDS).
The tunnel server can be any Unix/Linux host that:
- Can be accessed from the internet via SSH.
- Can access the database.
Step 2: Create an IP allowlist
The second step to set up SSH tunnel access for your database, is to allow network traffic to reach the tunnel server or database host via SSH, which is generally on TCP port 22.
Allow network traffic from each of the IP addresses for the region where Database Migration Service resources are created.
Step 3: Use the SSH tunnel
Provide the tunnel details in the connection profile configuration. For more information, see Creating a connection profile.
To authenticate the SSH tunnel session, Database Migration Service requires either the password for the tunnel account, or a unique private key. To use a unique private key, you can use OpenSSL command-line tools to generate a key pair, consisting of a private key and a public key.
The private key is stored securely by Database Migration Service as part of its connection profile configuration. You must add the public key manually to the bastion host's ~/.ssh/authorized_hosts file.
Set up private connectivity to the source database
Private connectivity is a connection between your VPC network and Database Migration Service's private network, enabling Database Migration Service to communicate with internal resources by using internal IP addresses. Using private connectivity establishes a dedicated connection on the Database Migration Service network, meaning no other customers can share it.
If your source database is external to Google Cloud, then private connectivity enables Database Migration Service to communicate with your database over VPN or Interconnect.
After a private connectivity configuration is created, a single configuration can service all migrations in a project within a single region.
At a high-level, establishing private connectivity requires:
- An existing Virtual Private Cloud (VPC)
- An available IP range with a minimum CIDR block of /29
If your project is using a shared VPC, then you'll also need to enable the Database Migration Service and Google Compute Engine APIs, as well as grant permissions to Database Migration Service's service account on the host project.
Learn more about how to create a private connectivity configuration for your source database.
Set up private connectivity to the destination database
Database Migration Service uses Private Service Connect to connect privately to your destination AlloyDB for PostgreSQL instance. You can expose the database TCP port to incoming secure connections, while maintaining control over who can access the database by setting up a service attachment in your project.
Learn more about how to create a private connectivity configuration for your destination database.