Untuk membuat migrasi di Database Migration Service, konektivitas harus dibuat antara instance sumber dan instance tujuan AlloyDB. Ada berbagai metode yang didukung. Pilih salah satu yang paling sesuai untuk workload tertentu.
Metode jaringan
Deskripsi
Kelebihan
Kekurangan
Daftar IP yang diizinkan
Metode ini berfungsi dengan mengonfigurasi server database sumber agar menerima koneksi
dari IP keluar instance Cloud SQL.
Jika Anda memilih metode ini, Database Migration Service akan memandu Anda
melalui proses penyiapan selama pembuatan migrasi.
Mudah dikonfigurasi.
Tidak memerlukan konfigurasi firewall kustom.
Traffic jaringan terjadi melalui internet publik.
Kurang aman.
Performa menurun.
Proxy melalui VM yang dihosting di cloud - Tunnel SSH terbalik
Membuat konektivitas dari tujuan ke sumber melalui
tunnel SSH terbalik yang aman.
Memerlukan VM bastion host di project Google Cloud Platform serta mesin
(misalnya, laptop di jaringan) yang memiliki konektivitas ke
sumber.
Database Migration Service mengumpulkan informasi yang diperlukan pada
waktu pembuatan migrasi, dan membuat skrip secara otomatis untuk
menyiapkan semuanya.
Mudah dikonfigurasi.
Tidak memerlukan konfigurasi firewall kustom.
Direkomendasikan untuk skenario migrasi jangka pendek (POC atau migrasi database kecil).
Bastion VM dimiliki dan dikelola oleh Anda, dan dapat menimbulkan biaya tambahan.
Proxy melalui VM yang dihosting di cloud - TCP
Membangun konektivitas dari tujuan ke sumber menggunakan proxy TCP melalui VM yang dihosting di cloud.
Database Migration Service mengumpulkan informasi yang diperlukan pada
waktu pembuatan migrasi, dan membuat skrip secara otomatis untuk
menyiapkan semuanya.
Relevan pada migrasi AlloyDB saat sumber berada di arsitektur jaringan lama.
Mudah dikonfigurasi.
Tidak memerlukan konfigurasi firewall kustom.
Bastion VM dimiliki dan dikelola oleh Anda, dan dapat menimbulkan biaya tambahan.
Peering VPC
Metode ini berfungsi dengan mengonfigurasi VPC agar dapat berkomunikasi satu sama lain.
Solusi Google Cloud Native.
Mudah dikonfigurasi.
Bandwidth tinggi.
Direkomendasikan untuk migrasi yang berjalan lama atau bervolume tinggi.
Berlaku jika database sumber dan tujuan dihosting di
Google Cloud, atau jika sumber terhubung ke VPC tujuan
menggunakan VPN (dihosting di cloud atau lokal) atau Cloud Interconnect.
Antarmuka Private Service Connect
Antarmuka Private Service Connect memungkinkan database tujuan Anda
memulai koneksi ke IP pribadi database sumber Anda tanpa menggunakan kuota peering. Sebagai gantinya, metode konektivitas ini
menggunakan lampiran jaringan yang Anda buat di VPC.
Membuat koneksi ke IP pribadi sumber Anda menggunakan lampiran jaringan.
Metode ini tidak menggunakan kuota peering di VPC Anda.
Metode konektivitas pribadi sumber yang paling mudah dikonfigurasi.
Memerlukan penyiapan lampiran jaringan dan penyesuaian aturan firewall.
Anda tidak dapat mengubah lampiran jaringan setelah membuat
koneksi.
Untuk mengetahui informasi selengkapnya tentang akses layanan pribadi dan
Private Service Connect di
AlloyDB untuk PostgreSQL,
lihat Ringkasan IP pribadi
dalam dokumentasi AlloyDB untuk PostgreSQL.
Batasan konektivitas
Konektivitas PostgreSQL ke AlloyDB memiliki batasan berikut:
AlloyDB mendukung konektivitas pribadi menggunakan akses layanan pribadi. Penetapan alamat IP publik ke cluster tidak didukung.
Anda tidak dapat mengubah VPC yang digunakan untuk peering cluster AlloyDB setelah cluster dibuat.
Karena AlloyDB menggunakan akses layanan pribadi yang secara internal menggunakan peering VPC, peering transitif tidak didukung. Cluster AlloyDB Anda hanya dapat menjangkau alamat IP internal di VPC yang sama dengan yang di-peering. Untuk menjangkau VPC lain, Anda harus menggunakan proxy perantara. Untuk mengetahui detail selengkapnya, lihat bagian berikut.
Skenario dan solusi konektivitas umum
Bermigrasi dari instance Cloud SQL dalam arsitektur jaringan produsen lama
Gambar 1. Koneksi pribadi yang difasilitasi oleh VM proxy TCP
(klik untuk memperbesar)
Untuk bermigrasi dari instance Cloud SQL untuk PostgreSQL dalam arsitektur jaringan produsen lama, Anda harus membuat konektivitas menggunakan proxy perantara. Hal ini karena konektivitas langsung antara instance Cloud SQL sumber dan tujuan AlloyDB tidak dapat dilakukan.
Anda dapat menyiapkan solusi proxy sendiri, meskipun sebaiknya siapkan
VM proxy TCP dengan skrip yang dibuat otomatis yang disediakan oleh Database Migration Service.
Lihat Metode konektivitas proxy TCP.
Bermigrasi dari sumber di Google Cloud project yang sama, tetapi di VPC yang berbeda
Karena VPC tempat cluster AlloyDB berada tidak dapat diubah setelah cluster dibuat, Anda memiliki opsi berikut:
Opsi yang direkomendasikan adalah mengubah VPC instance sumber agar cocok dengan VPC instance tujuan. Misalnya, jika Anda ingin memigrasikan instance Cloud SQL ke AlloyDB, perbarui VPC Cloud SQL agar cocok dengan VPC AlloyDB.
Untuk menambahkan antarmuka jaringan lain, tambahkan --network-interface network=SOURCE_NETWORK_NAME ke perintah gcloud compute instances create-with-container yang muncul dalam skrip.
Bermigrasi dari sumber di project Google Cloud lain
Untuk bermigrasi dari sumber di project Google Cloud lain, Anda harus bermigrasi melalui internet, atau, untuk konektivitas Google Cloud internal, menggunakan VPC bersama. Pilih salah satu opsi berikut:
Gunakan VPC bersama tanpa proxy. Jika Anda ingin cluster AlloyDB berada di VPC bersama, cukup pilih VPC tempat sumber Anda berada saat membuat cluster. Dengan cara ini, sumber dan tujuan memiliki konektivitas langsung.
Menggunakan VPC bersama dengan proxy. Jika tidak ingin cluster AlloyDB Anda berada di VPC bersama, Anda harus menggunakan proxy perantara. Anda dapat menyiapkan solusi proxy Anda sendiri, tetapi sebaiknya gunakan metode konektivitas proxy TCP. Ikuti panduan ini untuk membuat proxy TCP dengan antarmuka jaringan tambahan di VPC bersama.
Memigrasikan tanpa mengizinkan tujuan menjangkau jaringan sumber
Metode ini direkomendasikan saat bermigrasi dari jaringan lokal, yang khawatir membuka firewall jaringan untuk traffic Google Cloud masuk. Untuk skenario ini, Anda dapat menyiapkan proxy terbalik menggunakan instance Compute Engine sebagai proxy perantara. Sebaiknya gunakan metode konektivitas SSH terbalik.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-01 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)."]]
