Damit Sie eine Migration in Database Migration Service erstellen können, muss eine Verbindung zwischen der Quellinstanz und der AlloyDB-Zielinstanz hergestellt werden. Es werden verschiedene Methoden unterstützt. Wählen Sie die Option aus, die für die jeweilige Arbeitslast am besten geeignet ist.
Netzwerkverfahren
Beschreibung
Vorteile
Nachteile
IP-Zulassungsliste
Bei dieser Methode wird der Quelldatenbankserver so konfiguriert, dass er Verbindungen von der ausgehenden IP-Adresse der Cloud SQL-Instanz akzeptiert.
Wenn Sie diese Methode auswählen, werden Sie von Database Migration Service während der Migrationseinrichtung durch den Einrichtungsprozess geführt.
Einfach zu konfigurieren.
Es ist keine benutzerdefinierte Firewallkonfiguration erforderlich.
Der Netzwerk-Traffic wird über das öffentliche Internet übertragen.
Weniger sicher.
Die Leistung hat nachgelassen.
Weiterleitung über in der Cloud gehostete VM – umgekehrter SSH-Tunnel
Stellt die Verbindung vom Ziel zur Quelle über einen sicheren umgekehrten SSH-Tunnel her.
Erfordert eine Bastion Host-VM im Google Cloud -Plattformprojekt sowie einen Computer (z. B. einen Laptop im Netzwerk), der eine Verbindung zur Quelle hat.
Database Migration Service erfasst die erforderlichen Informationen beim Erstellen der Migration und generiert automatisch das Skript für die Einrichtung.
Einfach zu konfigurieren.
Es ist keine benutzerdefinierte Firewallkonfiguration erforderlich.
Empfohlen für kurzlebige Migrationsszenarien (POC oder kleine Datenbankmigrationen).
Die Bastion-VM gehört Ihnen und wird von Ihnen verwaltet. Es können zusätzliche Kosten anfallen.
Weiterleitung über in der Cloud gehostete VM – TCP
Stellt eine Verbindung vom Ziel zur Quelle über einen TCP-Proxy über eine in der Cloud gehostete VM her.
Database Migration Service erfasst die erforderlichen Informationen beim Erstellen der Migration und generiert automatisch das Skript für die Einrichtung.
Relevant für AlloyDB-Migrationen, bei denen sich die Quelle in der alten Netzwerkarchitektur befindet.
Einfach zu konfigurieren.
Es ist keine benutzerdefinierte Firewallkonfiguration erforderlich.
Die Bastion-VM gehört Ihnen und wird von Ihnen verwaltet. Es können zusätzliche Kosten anfallen.
VPC-Peering
Bei dieser Methode werden die VPCs für die Kommunikation miteinander konfiguriert.
Native Google Cloud Lösung.
Einfach zu konfigurieren.
Hohe Bandbreite.
Empfohlen für Migrationen mit langer Laufzeit oder hohem Volumen.
Gilt, wenn sowohl die Quell- als auch die Zieldatenbank in Google Cloudgehostet werden oder wenn die Quelle über ein VPN (in der Cloud gehostet oder lokal) oder Cloud Interconnect mit dem Ziel-VPC verbunden ist.
Private Service Connect-Schnittstellen
Private Service Connect-Schnittstellen ermöglichen es Ihrer AlloyDB for PostgreSQL-Zielinstanz, Verbindungen zur privaten IP-Adresse Ihrer Quelldatenbank herzustellen, ohne dass das Peering-Kontingent aufgebraucht wird. Stattdessen werden bei dieser Verbindungsmethode Netzwerkanhänge verwendet, die Sie in Ihrer VPC erstellen.
Stellt Verbindungen zu Ihrer privaten Quell-IP-Adresse über eine Netzwerkverbindung her.
Bei dieser Methode wird kein Peering-Kontingent in Ihrer VPC verbraucht.
Die am einfachsten zu konfigurierende Methode für private Verbindungen für Quellen.
Dazu müssen Sie eine Netzwerkverbindung einrichten und Firewallregeln anpassen.
Sie können den Netzwerkanhang nach dem Herstellen der Verbindung nicht mehr ändern.
Weitere Informationen zum Zugriff auf private Dienste und zu Private Service Connect in AlloyDB for PostgreSQL finden Sie in der AlloyDB for PostgreSQL-Dokumentation unter Übersicht über private IP-Adressen.
Einschränkungen bei der Konnektivität
Für die Verbindung von PostgreSQL zu AlloyDB gelten die folgenden Einschränkungen:
AlloyDB unterstützt private Verbindungen über den Zugriff auf private Dienste. Das Zuweisen einer öffentlichen IP-Adresse zu einem Cluster wird nicht unterstützt.
Sie können die VPC, mit der der AlloyDB-Cluster per Peering verbunden ist, nach der Erstellung des Clusters nicht mehr ändern.
Da AlloyDB den Zugriff auf private Dienste verwendet, der intern VPC-Peering nutzt, wird transitives Peering nicht unterstützt. Ihr AlloyDB-Cluster kann nur interne IP-Adressen in derselben VPC erreichen, mit der er per Peering verbunden ist. Um andere VPCs zu erreichen, müssen Sie einen Zwischenproxy verwenden. Weitere Informationen finden Sie im folgenden Abschnitt.
Häufige Verbindungsszenarien und Lösungen
Von einer Cloud SQL-Instanz in der alten Producer-Netzwerkarchitektur migrieren
Abbildung 1. Private Verbindung über die TCP-Proxy-VM
(zum Vergrößern klicken)
Wenn Sie von einer Cloud SQL for PostgreSQL-Instanz in der alten Architektur für das Erstellernetzwerk migrieren möchten, müssen Sie die Verbindung über einen Zwischenproxy herstellen. Das liegt daran, dass keine direkte Verbindung zwischen der Cloud SQL-Quellinstanz und dem AlloyDB-Ziel möglich ist.
Sie können Ihre eigene Proxylösung einrichten. Wir empfehlen jedoch, die TCP-Proxy-VM mit dem automatisch generierten Skript einzurichten, das vom Database Migration Service bereitgestellt wird.
Weitere Informationen finden Sie unter TCP-Proxy-Verbindungsmethode.
Migration von einer Quelle im selben Google Cloud Projekt, aber in einer anderen VPC
Da die VPC, in der sich der AlloyDB-Cluster befindet, nach dem Erstellen des Clusters nicht mehr geändert werden kann, haben Sie die folgenden Optionen:
Die empfohlene Option besteht darin, die VPC der Quellinstanz so zu ändern, dass sie mit der VPC der Zielinstanz übereinstimmt. Wenn Sie beispielsweise eine Cloud SQL-Instanz zu AlloyDB migrieren möchten, aktualisieren Sie die Cloud SQL-VPC, damit sie mit der AlloyDB-VPC übereinstimmt.
Wenn Sie eine weitere Netzwerkschnittstelle hinzufügen möchten, hängen Sie --network-interface network=SOURCE_NETWORK_NAME an den Befehl gcloud compute instances create-with-container an, der im Skript angezeigt wird.
Von einer Quelle in einem anderen Google Cloud Projekt migrieren
Wenn Sie von einer Quelle in einem anderen Google Cloud Projekt migrieren möchten, müssen Sie entweder über das Internet migrieren oder für interne Google Cloud Verbindungen eine freigegebene VPC verwenden. Wählen Sie eine der folgenden Optionen aus:
Freigegebene VPC ohne Proxy verwenden Wenn sich Ihr AlloyDB-Cluster in einer freigegebenen VPC befinden soll, wählen Sie beim Erstellen des Clusters einfach die VPC aus, in der sich Ihre Quelle befindet. So haben Quelle und Ziel eine direkte Verbindung.
Freigegebene VPC mit einem Proxy verwenden Wenn sich Ihr AlloyDB-Cluster nicht in einer freigegebenen VPC befinden soll, müssen Sie einen Vermittlungsproxy verwenden. Sie können Ihre eigene Proxylösung einrichten, wir empfehlen jedoch die TCP-Proxy-Verbindungsmethode. Folgen Sie dieser Anleitung, um einen TCP-Proxy mit einer zusätzlichen Netzwerkschnittstelle in einer freigegebenen VPC zu erstellen.
Migrieren, ohne dem Ziel zu erlauben, das Netzwerk der Quelle zu erreichen
Diese Methode wird empfohlen, wenn Sie von einem lokalen Netzwerk migrieren und Bedenken haben, die Firewall des Netzwerks für eingehenden Google Cloud -Traffic zu öffnen. In diesem Szenario können Sie einen Reverse-Proxy einrichten, indem Sie eine Compute Engine-Instanz als Vermittlungsproxy verwenden. Wir empfehlen die Verwendung der Reverse-SSH-Verbindungsmethode.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-22 (UTC)."],[[["\u003cp\u003eDatabase Migration Service requires establishing connectivity between the source instance and the AlloyDB destination instance for migrations, with several methods available.\u003c/p\u003e\n"],["\u003cp\u003eThe 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.\u003c/p\u003e\n"],["\u003cp\u003eProxy 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.\u003c/p\u003e\n"],["\u003cp\u003eVPC 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.\u003c/p\u003e\n"],["\u003cp\u003eFor 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.\u003c/p\u003e\n"]]],[],null,["# Networking methods\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/networking-methods \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/networking-methods \"View this page for the PostgreSQL version of Database Migration Service.\") \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nTo 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. \n\nConnectivity limitations\n------------------------\n\nThe PostgreSQL to AlloyDB connectivity has the following limitations:\n\n- AlloyDB supports private connectivity using [private services access](/alloydb/docs/configure-connectivity). Assigning a public IP address to a cluster is not supported.\n- You can't change the VPC with which the AlloyDB cluster is peered after the cluster is created.\n- Because AlloyDB uses private services access which internally uses VPC peering, [transitive peering](/vpc/docs/vpc-peering#specifications) 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.\n\nCommon connectivity scenarios and solutions\n-------------------------------------------\n\n### Migrate from a Cloud SQL instance in the old producer network architecture\n\n[](#lightbox-trigger) **Figure 1.** A private connection facilitated by the TCP proxy VM (click to enlarge)\n\nTo migrate from a Cloud SQL for PostgreSQL instance in the old producer\nnetwork architecture, you must establish connectivity using an intermediary\nproxy. This is because it isn't possible to have direct connectivity between\nthe source Cloud SQL instance and the AlloyDB destination.\nYou can set up your own proxy solution, although we recommend setting up\nthe TCP proxy VM with the auto-generated script provided by Database Migration Service.\nSee [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm).\n\n### Migrate from a source in the same Google Cloud project but in a different VPC\n\nBecause the VPC in which the AlloyDB cluster resides can't be changed after the cluster is created, you have the following options:\n\n- 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](/sql/docs/postgres/configure-private-ip#existing-private-instance) to match the AlloyDB VPC.\n\n | **Caution:** Configuring a private IP address for an existing Cloud SQL instance causes the instance to restart, resulting in downtime.\n- 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](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm). 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.\n\n 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.\n | **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=`\u003cvar translate=\"no\"\u003eSOURCE_SUBNET_NAME\u003c/var\u003e.\n\n An example command to create the proxy: \n\n ```bash\n gcloud compute instances create-with-container … \\\n --network-interface subnet=DESTINATION-SUBNET-NAME \\\n --network-interface network=SOURCE-NETWORK-NAME\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDESTINATION-SUBNET-NAME\u003c/var\u003e: The name of the destination subnet.\n - \u003cvar translate=\"no\"\u003eSOURCE-NETWORK-NAME\u003c/var\u003e: The name of the source network.\n\nFor more information, see [Create VM instances with multiple network interfaces](/vpc/docs/create-use-multiple-interfaces#creating_virtual_machine_instances_with_multiple_network_interfaces).\n\n### Migrate over the public internet\n\nThis method is recommended when migrating from an on-premise instance or from\nother cloud providers, where there's no existing VPN or Interconnect connection\nto Google Cloud. To use this method, you need to\n[configure your destination AlloyDB cluster to use an outbound public IP address](/alloydb/docs/connect-public-ip#add-outbound-connectivity).\n\n### Migrate from a source in a different Google Cloud project\n\nTo 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:\n\n- 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.\n\n- 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](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm). Follow [these guidelines](#intermediaryproxy) to create a TCP proxy with an additional network interface on a shared VPC.\n\n### Migrate without allowing the destination to reach the network of the source\n\nThis 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](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-reverse-ssh-tunnel)."]]
