Database Migration Service で移行を作成するには、移行元と Cloud SQL 移行先インスタンス間の接続を確立する必要があります。さまざまな方法がサポートされています。特定のワークロードに最適なものを選択します。
ネットワーキングの方式
説明
長所
短所
クラウドでホストされている VM を経由したリバース SSH トンネル
セキュアなリバース SSH トンネルを介して、移行先から移行元への接続を確立します。 Google Cloud プロジェクトの踏み台ホスト VM と、ソースに接続できるマシン（ネットワーク上のノートパソコンなど）が必要です。Database Migration Service は、移行の作成時に必要な情報を収集し、設定用のスクリプトを自動生成します。
簡単に構成できる。
カスタム ファイアウォール構成は必要ありません。
短期間の移行シナリオ（POC や小規模なデータベースの移行）におすすめします。
踏み台 VM の所有と管理はお客様が行います。
追加費用が発生する場合があります。
クラウドでホストされている VM を経由した TCP プロキシ
クラウドでホストされている VM を経由した TCP プロキシを介して、移行先から移行元への接続を確立します。Database Migration Service は、移行の作成時に必要な情報を収集し、設定用のスクリプトを自動生成します。ソースが古いネットワーク アーキテクチャにある AlloyDB 移行に関連します。
簡単に構成できる。
カスタム ファイアウォール構成は必要ありません。
Bastion VM はユーザーが所有して管理するため、追加費用が発生する場合があります。
VPC ピアリング
この方法は、VPC が相互に通信するように構成することで機能します。
ネイティブ Google Cloud ソリューション。
簡単に構成できる。
高帯域幅
長時間実行される移行や大量の移行におすすめします。
移行元と移行先の両方のデータベースが Google Cloudでホストされている場合にのみ適用されます。
VPN
公共のインターネット経由の安全な接続を介して、内部ネットワークと Google Cloud VPC を接続する IPSec VPN トンネルを設定します。 Google Cloud VPN または内部ネットワーク用に設定された VPN ソリューションを使用します。
堅牢でスケーラブルな接続ソリューション。
中～高帯域幅。
組み込みのセキュリティ。
Google Cloud ソリューションとして提供されるか、他のサードパーティから提供されます。
追加費用が発生します。
複雑な構成（すでにインプレースの場合を除く）。
Cloud Interconnect
オンプレミス ネットワークと Google Cloudの間の高可用性で低レイテンシの接続を使用します。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-05 UTC。"],[[["\u003cp\u003eDatabase Migration Service facilitates the migration of PostgreSQL workloads to Google Cloud's AlloyDB.\u003c/p\u003e\n"],["\u003cp\u003eSupported source databases include Amazon RDS, Amazon Aurora, self-managed PostgreSQL, and Cloud SQL, with AlloyDB for PostgreSQL being the supported destination.\u003c/p\u003e\n"],["\u003cp\u003eThe service migrates schema, data, and metadata, including tables, keys, indexes, stored procedures, functions, triggers, and views from source to destination.\u003c/p\u003e\n"],["\u003cp\u003eDuring continuous migration, only Data Manipulation Language (DML) changes are automatically replicated; Data Definition Language (DDL) changes must be managed manually by the user to maintain compatibility.\u003c/p\u003e\n"],["\u003cp\u003eVarious networking methods are available for establishing connectivity between the source and destination, including reverse SSH tunnels, TCP proxy via cloud-hosted VMs, VPC peering, VPN, and Cloud Interconnect, each with its own advantages and limitations.\u003c/p\u003e\n"]]],[],null,["# Database Migration Service for AlloyDB FAQ\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/faq \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/faq \"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\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n- [What is Database Migration Service?](#whatisdms)\n- [Which sources are supported?](#sources)\n- [Is there cross-version support?](#crossversion)\n- [Which data, schema, and metadata components are migrated?](#migrated)\n- [Which changes are replicated during continuous migration?](#replicated)\n- [What isn't migrated?](#notmigrated)\n- [Which networking methods are used?](#networking)\n- [What are the known limitations?](#limitations)\n\n\u003cbr /\u003e\n\nWhat is Database Migration Service?\n: Database Migration Service is a service that makes it easier for you to migrate your data to Google Cloud. Database Migration Service helps you lift and shift your PostgreSQL workloads into AlloyDB.\n\nWhich sources are supported?\n:\n\n\n - Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17\n - Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14, 15, 16, 17\n - Self-managed PostgreSQL (on premises or on any cloud VM that you fully control) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17\n - Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17\n\n\nWhich destinations are supported?\n:\n\n\n - AlloyDB for PostgreSQL 14, 15, 16, 17\n\n\nIs there cross-version support?\n:\n\n Database Migration Service supports PostgreSQL to AlloyDB migrations from any of the supported source database versions.\n\nWhich data, schema, and metadata components are migrated?\n\n: Database Migration Service migrates schema, data, and metadata from the source to the destination. All of the following data, schema, and metadata components are migrated as part of the database migration: \u003cbr /\u003e\n\n Data Migration\n\n - All schemas and all tables from the selected database.\n\n Schema Migration\n\n \u003c!-- --\u003e\n\n - Naming\n - Primary key\n - Data type\n - Ordinal position\n - Default value\n - Nullability\n - Auto-increment attributes\n - Secondary indexes\n\n Metadata Migration\n\n \u003c!-- --\u003e\n\n - Stored Procedures\n - Functions\n - Triggers\n - Views\n - Foreign key constraints\n\nWhich changes are replicated during continuous migration?\n:\n\n Only DML changes are automatically updated during the migration. Managing DDL so that the source and\n destination database(s) remain compatible is the responsibility of the user, and can be achieved in\n two ways:\n\n 1. Stop writes to the source and run the DDL commands in both the source and the destination. Before running DDL commands on the destination, grant the `alloydbexternalsync` role to the Cloud SQL user applying the DDL changes. To enable querying or changing the data, grant the `alloydbexternalsync` role to the relevant Cloud SQL users.\n 2. Use the `pglogical.replicate_ddl_command` to run DDL on the source and destination at a consistent\n point. The user running this command must have the same username on both the source and the destination, and should be the superuser or the owner of the artifact being migrated (for example, the table, sequence, view, or database).\n\n Here are a few examples of using the `pglogical.replicate_ddl_command`.\n\n To add a column to a database table, run the following command:\n\n `select pglogical.replicate_ddl_command('ALTER TABLE `\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e` add column surname varchar(20)', '{default}');`\n\n To change the name of a database table, run the following command:\n\n `select pglogical.replicate_ddl_command('ALTER TABLE `\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e` RENAME TO `\u003cvar translate=\"no\"\u003e[table_name]\u003c/var\u003e`','{default}');`\n\n To create a database table, run the following commands:\n 1. `select pglogical.replicate_ddl_command(command := 'CREATE TABLE `\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e` (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);`\n 2. `select pglogical.replication_set_add_table('default', '`\u003cvar translate=\"no\"\u003e[schema].[table]\u003c/var\u003e`');`\n\nWhat isn't migrated?\n\n: To add users to the AlloyDB destination instance, add them from the PostgreSQL client. Learn more about [creating\n and managing PostgreSQL users](https://cloud.google.com/sql/docs/postgres/create-manage-users).\n\n [Large objects](https://www.postgresql.org/docs/current/largeobjects.html) can't be\n replicated because PostgreSQL's logical decoding facility doesn't\n support decoding changes to large objects. For tables that have [column type oid](https://www.postgresql.org/docs/current/datatype-oid.html) referencing large\n objects, the rows are still synced, and new rows are replicated. However, trying to access\n the large object on the destination database\n (read using [lo_get](https://www.postgresql.org/docs/current/lo-funcs.html),\n export using [lo_export](https://www.postgresql.org/docs/current/lo-funcs.html), or check\n the catalog `pg_largeobject` for the given oid), fails with a message saying that the large\n object doesn't exist.\n\n For tables that don't have primary keys, Database Migration Service supports migration of the **initial snapshot and `INSERT` statements during the change data capture (CDC) phase** . You should migrate `UPDATE` and `DELETE` statements manually.\n\n Database Migration Service doesn't migrate data from materialized views, just the view schema. To populate the views, run the following command: `REFRESH MATERIALIZED VIEW `\u003cvar translate=\"no\"\u003eview_name\u003c/var\u003e.\n\n The `SEQUENCE` states (for example, `last_value`) on the new AlloyDB destination might vary from the source `SEQUENCE` states.\n\nWhich networking methods are used?\n: To create a migration in Database Migration Service, connectivity must be established\n between the source and the Cloud SQL destination instance. There are a variety of methods supported.\n Choose the one that works best for the specific workload.\n\n\nWhat are the known limitations?\n: See [Known limitations](/database-migration/docs/postgresql-to-alloydb/known-limitations)."]]
