Database Migration Service は、 Google Cloudにデータを移行するのに役立ちます。このサービスは、Cloud SQL インスタンスと AlloyDB for PostgreSQL インスタンスへのデータベース移行をサポートしています。Database Migration Service は、ネットワークを合理化し、最初のスナップショットと継続的なレプリケーションを管理し、移行プロセス全体でステータスの更新を提供します。
Database Migration Service は、同種と異種の両方の移行で、ダウンタイムが短く、継続的なサーバーレス移行をサポートしています。Database Migration Service のサーバーレス アーキテクチャは、移行元データベースの最初のスナップショットを取得して、データの現在の状態をキャプチャします。スナップショットが完了すると、Database Migration Service はスナップショットを移行先データベースに読み込み、継続的なデータ レプリケーションが開始されます。データ レプリケーションは、元のデータベースに加えられた変更をリアルタイムで追跡してコピーするため、継続的なオペレーションです。これは変更データ キャプチャ（CDC）に基づいています。これは、最初のスナップショットの取得後にデータベースに加えた挿入、更新、削除などの変更のみを特定してキャプチャするプロセスです。
[[["わかりやすい","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-08-18 UTC。"],[[["\u003cp\u003eDatabase Migration Service facilitates the transfer of data and metadata from a source database to a destination database, eventually allowing for the source database to be decommissioned.\u003c/p\u003e\n"],["\u003cp\u003eThis service supports migrations to Cloud SQL and AlloyDB for PostgreSQL, offering features like networking management, initial snapshot handling, ongoing replication, and status updates.\u003c/p\u003e\n"],["\u003cp\u003eIt offers continuous migration for minimal downtime, as well as one-time migrations for a snapshot transfer, supporting both homogeneous (same database technology) and heterogeneous (different database technologies) migrations.\u003c/p\u003e\n"],["\u003cp\u003eThe service ensures data security through SSL/TLS encryption for network connections and customer-managed encryption keys (CMEK) during continuous migrations.\u003c/p\u003e\n"],["\u003cp\u003eDatabase Migration Service provides conversion features for heterogeneous migrations, such as automated initial schema conversion, an interactive SQL editor, Gemini-assisted conversion features, and customizable directives.\u003c/p\u003e\n"]]],[],null,["# Database Migration Service overview\n\nMigration is a process of moving data and metadata from a source database to a\ndestination database. After your migration is completed, the destination database\nbecomes the primary database that dependent applications can read and write to,\nand the source database can be shut down.\n\nDatabase Migration Service helps you migrate your data to Google Cloud. The service\nsupports database migrations into Cloud SQL and AlloyDB for PostgreSQL\ninstances. Database Migration Service streamlines networking, manages the initial\nsnapshot and ongoing replication, and provides status updates throughout the\nmigration process.\n\nWith Database Migration Service, you can:\n\n- Perform different [types of migrations](#migration-types).\n- Move your databases to Google Cloud with [minimal downtime](#minimal-downtime).\n- Use Gemini-powered [conversion features](#conversion-workspaces) in heterogeneous migrations.\n- Migrate encrypted data [securely](#security-encryption).\n- Monitor your migration job with [observability metrics](#observability-metrics).\n\nThe following diagram shows the key features of Database Migration Service in the context of Google Cloud architecture:\n[](#lightbox-trigger) **Figure 1.** The key features of Database Migration Service (click to enlarge).\n\nMigration types\n---------------\n\nMigrations can be categorized into the following types:\n\n### Continuous migration\n\nContinuous (sometimes referred to as ongoing or online) migration is a\ncontinuous flow of changes from your source to your destination that follows an\ninitial full dump and load. When the destination is ready for reads and writes,\nyou finalize replication between the source and the destination. The destination\nCloud SQL instance or AlloyDB for PostgreSQL cluster is then ready to be\nused as a standalone primary instance. Doing the switch when the source and\ndestination are in sync gives you minimal downtime.\n\n### One-time migration\n\nA one-time migration is a single point-in-time snapshot of the database.\nDatabase Migration Service takes the snapshot from the source and applies it to the\ndestination. This process is a dump and load, where the destination is ready to\nbe used when the load completes. Any applications that depend on the source\ndatabase can experience downtime during the migration process because there can\nbe no new writes to this database while the migration is in progress.\n\n### Homogeneous migrations\n\nHomogeneous migrations take place when you migrate data between the same\ndatabase technology. For example, from MySQL to Cloud SQL for MySQL.\n\nFor more information, see\n[Homogeneous migrations](/database-migration/docs/homogeneous-migrations).\n\n### Heterogeneous migrations\n\nUnlike homogeneous migrations, in heterogeneous migrations, such as Oracle to\nCloud SQL for PostgreSQL, the database technology of the source and\ndestination are different.\n\nFor more information, see\n[Heterogeneous migrations](/database-migration/docs/heterogeneous-migrations).\n\nMinimal downtime\n----------------\n\nDatabase Migration Service supports low downtime, continuous, serverless migrations for\nboth homogeneous and heterogeneous migrations. The serverless architecture of\nDatabase Migration Service takes an initial snapshot of the source database to capture\nthe current state of the data. Once the snapshot is complete, Database Migration Service\nloads the snapshot onto the destination database, and continuous data\nreplication begins. Data replication is a continuous operation because it tracks\nand copies any changes made to the original database in real-time. It's based\non Change Data Capture (CDC), a process that identifies and captures only the\nchanges, such as inserts, updates, deletes that you made to the database after\nthe initial snapshot is taken.\n\nSuch an approach minimises downtime for the following reasons:\n\n- Continuous replication is more efficient than replicating the entire database frequently, as it only focuses on modifications.\n- Data migrates while the source database remains operational.\n- Serverless migrations perform highly at scale.\n\nAccelerate code and schema conversion with Gemini\n-------------------------------------------------\n\nFor heterogeneous migrations, Database Migration Service converts the schema and objects\nfrom your source database into a format that is compatible with your destination\ndatabase. Conversion workspaces offer the following features:\n\n- Initial schema conversion that happens automatically, once you create your conversion workspace.\n- The interactive SQL editor that helps you fix conversion issues or adjust the schema to better fit your needs.\n- Assistance of Gemini conversion features.\n- Customization directives that you can use to override the rules of automated schema conversion.\n\nFor more information, see\n[Gemini-powered conversion](/database-migration/docs/convert-sql-with-dms#gemini-conversion).\n\nSecurity and encryption\n-----------------------\n\nDatabase Migration Service migrates data securely by using SSL/TLS certificates to\nencrypt network connections and customer-managed encryption keys (CMEK) for\ncontinuous migrations.\n\nFor more information, see\n[Security and encryption](/database-migration/docs/security-and-encryption).\n\nObservability metrics\n---------------------\n\nDatabase Migration Service shows several diagrams that can help you understand\nthe current state and progress of your migration job. Most migration scenarios let you filter the\ninformation in these diagrams for each database included in your migration job.\n[](#lightbox-trigger) **Figure 1.** Sample observability diagrams in Database Migration Service. (click to enlarge)\n\nFor more information, see the migration job metrics pages that apply to your migration scenario.\n\nUse cases\n---------\n\nDatabase Migration Service enables the following use cases:\n\nLift-and-shift migration to a managed service\n: As part of an organization's move to Google Cloud, you can move from\n VM-based self-hosted databases to managed database cloud services. This lets you\n focus on the high availability, disaster recovery, and performance of running\n databases on managed services, instead of managing the infrastructure.\n\nMulti-cloud continuous replication\n: Much like the read replicas across regions, if data exists in another cloud\n provider, a migration job can continuously replicate the database into\n Google Cloud for multi-cloud read-availability. Database Migration Service\n doesn't support a dual-write scenario, that is writing to and reading from\n both the source and destination.\n\nWhat's next\n-----------\n\nLearn more about available migration scenarios:\n\nHomogeneous migrations\n:\n - [Migrate to Cloud SQL for MySQL](/database-migration/docs/mysql/migration-src-and-dest)\n - [Migrate to Cloud SQL for SQL Server](/database-migration/docs/sqlserver/scenario-overview)\n - [Migrate to Cloud SQL for PostgreSQL](/database-migration/docs/postgres/migration-src-and-dest)\n - [Migrate to AlloyDB for PostgreSQL](/database-migration/docs/postgresql-to-alloydb/migration-src-and-dest)\n\nHeterogeneous migrations\n:\n - [Migrate from Oracle to Cloud SQL for PostgreSQL](/database-migration/docs/oracle-to-postgresql/scenario-overview)\n - [Migrate from Oracle to AlloyDB for PostgreSQL](/database-migration/docs/oracle-to-alloydb/scenario-overview)\n - [Migrate from SQL Server to Cloud SQL for PostgreSQL](/database-migration/docs/sqlserver-to-csql-pgsql/scenario-overview)\n - [Migrate from SQL Server to AlloyDB for PostgreSQL](/database-migration/docs/sqlserver-to-alloydb/scenario-overview)"]]
