Database Migration Service 可帮助您将数据迁移到 Google Cloud。该服务支持将数据库迁移到 Cloud SQL 和 AlloyDB for PostgreSQL 实例。Database Migration Service 可简化网络连接、管理初始快照和持续复制，并在整个迁移过程中提供状态更新。
Database Migration Service 支持无服务器迁移，可实现低停机时间的持续迁移，适用于同构和异构迁移。Database Migration Service 的无服务器架构会截取源数据库的初始快照，以捕获数据的当前状态。快照完成后，Database Migration Service 会将快照加载到目标数据库，并开始持续数据复制。数据复制是一项持续性操作，因为它会实时跟踪并复制对原始数据库所做的任何更改。它基于变更数据捕获 (CDC)，该过程仅识别和捕获您在初始快照创建后对数据库所做的更改，例如插入、更新和删除。
这种方法可最大限度地缩短停机时间，原因如下：
持续复制比频繁复制整个数据库更高效，因为它只关注修改。
在源数据库保持运行状态时迁移数据。
无服务器迁移在大规模下具有出色的性能。
使用 Gemini 加快代码和架构转换速度
对于异构迁移，Database Migration Service 会将源数据库中的架构和对象转换为与目标数据库兼容的格式。转化工作区提供以下功能：
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-05。"],[[["\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)"]]
