마이그레이션은 소스 데이터베이스에서 대상 데이터베이스로 데이터와 메타데이터를 이동하는 프로세스입니다. 마이그레이션이 완료되면 대상 데이터베이스가 종속 애플리케이션이 읽고 쓸 수 있는 기본 데이터베이스가 되며 소스 데이터베이스는 종료할 수 있습니다.
Database Migration Service를 사용하면 데이터를 Google Cloud로 마이그레이션할 수 있습니다. 이 서비스는 PostgreSQL용 Cloud SQL 및 AlloyDB 인스턴스로의 데이터베이스 마이그레이션을 지원합니다. Database Migration Service는 네트워킹을 간소화하고 초기 스냅샷과 진행 중인 복제를 관리하며 마이그레이션 프로세스 전반에서 상태 업데이트를 제공합니다.
다음 다이어그램은 Google Cloud 아키텍처 컨텍스트에서 데이터베이스 마이그레이션 서비스의 주요 기능을 보여줍니다.
그림 1. Database Migration Service의 주요 기능 (확대하려면 클릭)
마이그레이션 유형
이전은 다음 유형으로 분류할 수 있습니다.
연속 마이그레이션
연속 (진행 중 또는 온라인이라고도 함) 마이그레이션은 초기 전체 덤프 및 로드 이후에 소스의 변경사항을 대상 위치로 지속적으로 전송하는 것입니다. 대상에서 읽기 및 쓰기를 수행할 준비가 되면 소스와 대상 간의 복제를 완료합니다. 그러면 대상 Cloud SQL 인스턴스 또는 PostgreSQL용 AlloyDB 클러스터를 독립형 기본 인스턴스로 사용할 수 있습니다. 소스와 대상이 동기화되었을 때 전환을 수행하면 다운타임이 최소화됩니다.
일회성 이전
일회성 마이그레이션은 데이터베이스의 단일 시점 스냅샷입니다.
Database Migration Service는 소스에서 스냅샷을 가져와 대상에 적용합니다. 이 프로세스는 덤프 및 로드이며, 로드가 완료되면 대상을 사용할 수 있습니다. 마이그레이션이 진행되는 동안 이 데이터베이스에 새 쓰기를 할 수 없으므로 소스 데이터베이스에 종속된 모든 애플리케이션은 마이그레이션 프로세스 중에 다운타임을 경험할 수 있습니다.
동종 마이그레이션
동종 마이그레이션은 동일한 데이터베이스 기술 간에 데이터를 마이그레이션할 때 발생합니다. 예를 들어 MySQL에서 MySQL용 Cloud SQL로 마이그레이션할 수 있습니다.
Database Migration Service는 동종 마이그레이션과 이기종 마이그레이션 모두에 대해 다운타임이 짧은 연속 서버리스 마이그레이션을 지원합니다. Database Migration Service의 서버리스 아키텍처는 소스 데이터베이스의 초기 스냅샷을 찍어 데이터의 현재 상태를 캡처합니다. 스냅샷이 완료되면 Database Migration Service는 스냅샷을 대상 데이터베이스에 로드하고 지속적인 데이터 복제가 시작됩니다. 데이터 복제는 원본 데이터베이스에 적용된 변경사항을 실시간으로 추적하고 복사하므로 연속 작업입니다. 변경 데이터 캡처 (CDC)를 기반으로 합니다. CDC는 초기 스냅샷을 찍은 후 데이터베이스에 적용한 삽입, 업데이트, 삭제와 같은 변경사항만 식별하고 캡처하는 프로세스입니다.
이러한 접근 방식은 다음과 같은 이유로 다운타임을 최소화합니다.
연속 복제는 수정사항에만 집중하므로 전체 데이터베이스를 자주 복제하는 것보다 효율적입니다.
소스 데이터베이스가 계속 작동하는 동안 데이터가 마이그레이션됩니다.
서버리스 마이그레이션은 대규모로 실행해도 성능이 우수합니다.
Gemini로 코드 및 스키마 변환 가속화
이기종 마이그레이션의 경우 Database Migration Service는 소스 데이터베이스의 스키마 및 객체를 대상 데이터베이스와 호환되는 형식으로 변환합니다. 전환 워크스페이스는 다음과 같은 기능을 제공합니다.
전환 워크스페이스를 만들면 자동으로 실행되는 초기 스키마 변환입니다.
변환 문제를 해결하거나 필요에 맞게 스키마를 조정하는 데 도움이 되는 대화형 SQL 편집기입니다.
Database Migration Service에는 마이그레이션 작업의 현재 상태와 진행 상황을 파악하는 데 도움이 되는 여러 다이어그램이 표시됩니다. 대부분의 이전 시나리오에서는 이전 작업에 포함된 각 데이터베이스에 대해 이러한 다이어그램의 정보를 필터링할 수 있습니다.
그림 1. Database Migration Service의 샘플 관측 가능성 다이어그램
(확대하려면 클릭)
자세한 내용은 이전 시나리오에 적용되는 이전 작업 측정항목 페이지를 참고하세요.
사용 사례
Database Migration Service를 사용하면 다음과 같은 사용 사례를 지원할 수 있습니다.
관리형 서비스로의 리프트 앤 시프트 마이그레이션
조직의 Google Cloud로의 이전의 일환으로 VM 기반 자체 호스팅 데이터베이스에서 관리형 데이터베이스 클라우드 서비스로 이전할 수 있습니다. 이를 통해 인프라를 관리하는 대신 관리형 서비스에서 실행되는 데이터베이스의 고가용성, 재해 복구, 성능에 집중할 수 있습니다.
멀티 클라우드 연속 복제
다른 클라우드 제공업체에 데이터가 있는 경우 리전 간 읽기 복제본과 마찬가지로 마이그레이션 작업은 멀티클라우드 읽기 가용성을 위해 데이터베이스를Google Cloud 에 지속적으로 복제할 수 있습니다. 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"]],["최종 업데이트: 2025-09-05(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)"]]
