Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://cloud.google.com/database-migration/docs/postgresql-to-alloydb/networking-methods below:

Networking methods | Database Migration Service

Stay organized with collections Save and categorize content based on your preferences.

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.

This method works by configuring the source database server to accept connections from the outgoing IP of the Cloud SQL instance.

If you choose this method, then Database Migration Service guides you through the setup process during the migration creation.

• Easy to configure.
• Doesn't require any custom firewall configuration.

• Network traffic occurs over the public Internet.
• Less secure.
• Decreased performance.

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.

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.

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.

Private Service Connect interfaces let your destination database initiate connections to the private IP of your source database without consuming peering quota. Instead, this connectivity method utilizes network attachments you create in your VPC.

• Establishes connections to your source private IP by using a network attachment. This method doesn't consume peering quota in your VPC.
• The easiest source private connectivity method to configure.

• This connectivity method is only available when you migrate to an existing instance.
• Requires setting up a network attachment and adjusting firewall rules.
• You can't modify the network attachment after you establish the connection.

For more information about private services access and Private Service Connect in AlloyDB for PostgreSQL, see Private IP overview in the AlloyDB for PostgreSQL documentation.

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.

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.

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.

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. To use this method, you need to configure your destination AlloyDB cluster to use an outbound public IP address.

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.

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.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-14 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-14 UTC."],[[["Database Migration Service requires establishing connectivity between the source instance and the AlloyDB destination instance for migrations, with several methods available."],["The IP allowlist method is suitable for short-lived migrations, offering ease of configuration but transmitting network traffic over the public internet, which affects security and performance."],["Proxy methods via cloud-hosted VMs, using either Reverse-SSH tunnels or TCP proxies, are recommended for short-lived migrations and offer ease of configuration without custom firewall adjustments."],["VPC peering is a native Google Cloud solution that provides high bandwidth and is ideal for long-running or high-volume migrations, but it is only available if both source and destination are hosted in Google Cloud or are connected to the same VPC."],["For sources in different networks or on-premise instances, using a proxy or migrating over the public internet are viable options, and there are guides to aid with this process."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4