Database Migration Service는 데이터를 Google Cloud로 더 쉽게 마이그레이션할 수 있는 서비스입니다. Database Migration Service를 사용하면 PostgreSQL 워크로드를 Cloud SQL로 리프트 앤 시프트할 수 있습니다.
어떤 소스가 지원되나요?
Amazon RDS 9.6.10 이상, 10.5 이상, 11.1 이상, 12, 13, 14, 15, 16, 17
Amazon Aurora 10.11 이상, 11.6 이상, 12.4 이상, 13.3 이상, 14.6 이상, 15.2 이상, 16, 17
자체 관리형 PostgreSQL (온프레미스 또는 완전히 제어하는 모든 Cloud VM) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17
Database Migration Service는 대상이 소스 데이터베이스와 동일하거나 더 높은 버전인 경우 모든 주요 버전에서 PostgreSQL-to-Cloud SQL 마이그레이션을 지원합니다.
어떤 데이터, 스키마, 메타데이터 구성요소가 이전되나요?
Database Migration Service는 스키마, 데이터, 메타데이터를 소스에서 대상으로 마이그레이션합니다. 다음 데이터, 스키마, 메타데이터 구성요소가 모두 데이터베이스 마이그레이션의 일부로 마이그레이션됩니다.
데이터 이전
선택한 데이터베이스의 모든 스키마 및 모든 테이블
스키마 이전
이름 지정
기본 키
데이터 유형
서수 순위
기본값
null 허용 여부
자동 증가 속성
보조 색인
메타데이터 이전
저장 프로시저
함수
트리거
조회수
외래 키 제약조건
연속 마이그레이션 중 복제되는 변경사항은 무엇인가요?
마이그레이션 중에 DML 변경사항만 자동으로 업데이트됩니다. 소스 및 대상 데이터베이스가 계속 호환되도록 DDL을 관리하는 것은 사용자의 책임이며 다음 두 가지 방법으로 할 수 있습니다.
소스 쓰기를 중지하고 소스 및 대상 모두에서 DDL 명령어를 실행합니다. 대상에서 DDL 명령어를 실행하기 전에 DDL 변경사항을 적용하는 Cloud SQL 사용자에게 cloudsqlexternalsync 역할을 부여합니다. 데이터 쿼리 또는 변경을 사용 설정하려면 관련 Cloud SQL 사용자에게 cloudsqlexternalsync 역할을 부여합니다.
pglogical.replicate_ddl_command를 사용하여 소스 및 대상의 일관된 지점에서 DDL을 실행합니다. 이 명령어를 실행하는 사용자는 소스와 대상 모두에서 동일한 사용자 이름을 사용해야 하며, 마이그레이션되는 아티팩트 (예: 테이블, 시퀀스, 뷰 또는 데이터베이스)의 슈퍼사용자 또는 소유자여야 합니다.
다음은 pglogical.replicate_ddl_command 사용의 몇 가지 예입니다.
Cloud SQL 대상 인스턴스에 사용자를 추가하려면 인스턴스로 이동하여 사용자 탭에서 사용자를 추가하거나 PostgreSQL 클라이언트에서 사용자를 추가합니다. PostgreSQL 사용자 만들기 및 관리에 대해 자세히 알아보세요.
PostgreSQL의 논리적 디코딩 기능이 대규모 객체의 변경사항 디코딩을 지원하지 않으므로 대규모 객체는 복제할 수 없습니다. 대용량 객체를 참조하는
열 유형 oid가 있는 테이블의 경우 행은 계속 동기화되고 새 행은 복제됩니다. 그러나 대상 데이터베이스의 대형 객체에 액세스하려고 하면(lo_get을 사용하여 읽거나 lo_export를 사용하여 내보내거나 지정된 oid의 카탈로그 pg_largeobject를 확인) 대형 객체가 존재하지 않는다는 메시지와 함께 실패합니다.
기본 키가 없는 테이블의 경우 Database Migration Service는 변경 데이터 캡처 (CDC) 단계 중에 초기 스냅샷과 INSERT 문의 마이그레이션을 지원합니다. UPDATE 및 DELETE 문은 수동으로 마이그레이션해야 합니다.
Database Migration Service는 구체화된 뷰의 데이터가 아닌 뷰 스키마만 마이그레이션합니다. 뷰를 채우려면 REFRESH MATERIALIZED VIEW view_name 명령어를 실행합니다.
새 Cloud SQL 대상의 SEQUENCE 상태 (예: last_value)는 소스 SEQUENCE 상태와 다를 수 있습니다.
어떤 네트워킹 방법이 사용되나요?
Database Migration Service에서 마이그레이션을 만들려면 소스와 Cloud SQL 대상 인스턴스 간에 연결을 설정해야 합니다. 다양한 메서드가 지원됩니다.
특정 워크로드에 가장 적합한 방법을 선택합니다.
네트워킹 방법
설명
장점
단점
IP 허용 목록
Cloud SQL 인스턴스의 공개 IP 주소에서 들어오는 연결을 허용하도록 소스 데이터베이스 서버를 구성하여 작동합니다. 이 방법을 선택하면 Database Migration Service에서 마이그레이션 생성 중에 설정 프로세스를 안내합니다.
손쉬운 구성
단기 마이그레이션 시나리오 (POC 또는 소규모 데이터베이스 이전)에 권장됩니다.
방화벽을 구성하려면 IT의 지원이 필요할 수 있습니다.
소스 데이터베이스를 공개 IP에 노출합니다.
기본적으로 연결은 암호화되지 않습니다. 연결을 암호화하려면 소스 데이터베이스에서 SSL을 사용 설정해야 합니다.
클라우드 호스팅 VM을 통한 역방향 SSH 터널
보안 역방향 SSH 터널을 통해 대상에서 소스로의 연결을 설정합니다.
Google Cloud 프로젝트에 방어 호스트 VM과 소스에 연결된 머신(예: 네트워크의 노트북)이 필요합니다. Database Migration Service는 마이그레이션 생성 시 필요한 정보를 수집하고 설정 스크립트를 자동으로 생성합니다.
손쉬운 구성
맞춤 방화벽 구성이 필요하지 않습니다.
단기 마이그레이션 시나리오 (POC 또는 소규모 데이터베이스 이전)에 권장됩니다.
배스천 VM을 소유하고 관리합니다.
추가 비용이 발생할 수 있습니다.
VPC 피어링
이 방법은 VPC가 서로 통신하도록 구성하는 방식으로 작동합니다. 소스와 대상이 모두 Google Cloud에 호스팅된 경우에만 적용됩니다. 장기 실행 또는 대규모 마이그레이션에 권장됩니다.
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-08-22(UTC)"],[[["\u003cp\u003eDatabase Migration Service simplifies migrating PostgreSQL workloads to Cloud SQL, supporting various source types like Amazon RDS, Aurora, self-managed PostgreSQL, and others.\u003c/p\u003e\n"],["\u003cp\u003eThe service migrates data, schema, and metadata, including schemas, tables, stored procedures, functions, triggers, and views, with DML changes automatically updated during continuous migration.\u003c/p\u003e\n"],["\u003cp\u003ePostgreSQL-to-Cloud SQL migrations are supported across any major version, provided the destination is the same or higher than the source.\u003c/p\u003e\n"],["\u003cp\u003eSeveral networking methods are available, including IP allowlist, reverse SSH tunnel, VPC peering, VPN, and Cloud Interconnect, each with its own set of pros and cons.\u003c/p\u003e\n"],["\u003cp\u003eLarge objects, data from materialized views, and \u003ccode\u003eUPDATE\u003c/code\u003e/\u003ccode\u003eDELETE\u003c/code\u003e statements for tables without primary keys are not migrated by the service.\u003c/p\u003e\n"]]],[],null,["# Database Migration Service for PostgreSQL FAQ\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/faq \"View this page for the MySQL version of Database Migration Service.\") \\| PostgreSQL \\| [PostgreSQL to AlloyDB](/database-migration/docs/postgresql-to-alloydb/faq \"View this page for the PostgreSQL to AlloyDB version of Database Migration Service.\")\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- [Which destinations are supported?](#destinations)\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 Cloud SQL.\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.6+, 15.2+, 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 for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.\n - Microsoft Azure Database for PostgreSQL Flexible Server: 11+\n\n\nWhich destinations are supported?\n:\n\n\n - Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.\n\n\nIs there cross-version support?\n:\n\n Database Migration Service supports PostgreSQL-to-Cloud SQL migrations across any major\n version, where the destination is the same or higher version than the source database.\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 `cloudsqlexternalsync` role to the Cloud SQL user applying the DDL changes. To enable querying or changing the data, grant the `cloudsqlexternalsync` 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 Cloud SQL destination instance, navigate to the instance and add users\n from the **Users** tab, or 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 Cloud SQL 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/postgres/known-limitations)."]]