Database Migration Service는 데이터를 Google Cloud로 더 쉽게 마이그레이션할 수 있도록 지원하는 서비스입니다. Database Migration Service를 사용하면 PostgreSQL 워크로드를 AlloyDB로 리프트 앤 시프트할 수 있습니다.
어떤 소스가 지원되나요?
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, 15, 16, 17
자체 관리형 PostgreSQL (온프레미스 또는 완전히 제어하는 모든 Cloud VM) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17
Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17
어떤 대상이 지원되나요?
PostgreSQL용 AlloyDB 14, 15, 16, 17
교차 버전 지원이 있나요?
Database Migration Service는 지원되는 소스 데이터베이스 버전에서 PostgreSQL에서 AlloyDB로의 마이그레이션을 지원합니다.
어떤 데이터, 스키마, 메타데이터 구성요소가 이전되나요?
Database Migration Service는 소스에서 대상으로 스키마, 데이터, 메타데이터를 마이그레이션합니다. 다음 데이터, 스키마, 메타데이터 구성요소는 모두 데이터베이스 마이그레이션의 일부로 마이그레이션됩니다.
데이터 마이그레이션
선택한 데이터베이스의 모든 스키마와 모든 테이블
스키마 마이그레이션
이름 지정
기본 키
데이터 유형
서수 위치
기본값
null 허용 여부
자동 증가 속성
보조 색인
메타데이터 마이그레이션
저장 프로시저
함수
트리거
조회수
외래 키 제약 조건
연속 마이그레이션 중에 어떤 변경사항이 복제되나요?
마이그레이션 중에 DML 변경사항만 자동으로 업데이트됩니다. 소스 및 대상 데이터베이스가 계속 호환되도록 DDL을 관리하는 것은 사용자의 책임이며 다음 두 가지 방법을 사용할 수 있습니다.
소스 쓰기를 중지하고 소스 및 대상 모두에서 DDL 명령어를 실행합니다. 대상에서 DDL 명령어를 실행하기 전에 DDL 변경사항을 적용하는 Cloud SQL 사용자에게 alloydbexternalsync 역할을 부여합니다. 데이터 쿼리 또는 변경을 사용 설정하려면 관련 Cloud SQL 사용자에게 alloydbexternalsync 역할을 부여합니다.
pglogical.replicate_ddl_command를 사용하여 소스 및 대상의 일관된 지점에서 DDL을 실행합니다. 이 명령어를 실행하는 사용자는 소스와 대상에서 동일한 사용자 이름을 가져야 하며, 마이그레이션되는 아티팩트 (예: 테이블, 시퀀스, 뷰 또는 데이터베이스)의 슈퍼 사용자 또는 소유자여야 합니다.
다음은 pglogical.replicate_ddl_command 사용의 몇 가지 예입니다.
AlloyDB 대상 인스턴스에 사용자를 추가하려면 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 명령어를 실행합니다.
새 AlloyDB 대상의 SEQUENCE 상태 (예: last_value)는 소스 SEQUENCE 상태와 다를 수 있습니다.
어떤 네트워킹 방법을 사용하나요?
Database Migration Service에서 마이그레이션을 만들려면 소스와 Cloud SQL 대상 인스턴스 간에 연결이 설정되어야 합니다. 다양한 방법이 지원됩니다.
특정 워크로드에 가장 적합한 것을 선택합니다.
네트워킹 방법
설명
장점
단점
클라우드 호스팅 VM을 통한 역방향 SSH 터널
보안 역방향 SSH 터널을 통해 대상에서 소스로의 연결을 설정합니다.
Google Cloud 프로젝트의 배스천 호스트 VM과 소스에 연결할 수 있는 머신(예: 네트워크의 노트북)이 필요합니다. Database Migration Service는 마이그레이션 생성 시 필요한 정보를 수집하고 이를 설정하는 스크립트를 자동 생성합니다.
손쉬운 구성
맞춤 방화벽 구성이 필요하지 않습니다.
단기 마이그레이션 시나리오 (POC 또는 소규모 데이터베이스 마이그레이션)에 권장됩니다.
배스천 VM을 소유하고 관리합니다.
추가 비용이 발생할 수 있습니다.
클라우드 호스팅 VM을 통한 TCP 프록시
클라우드 호스팅 VM을 통한 TCP 프록시를 통해 대상에서 소스로 연결을 설정합니다.
Database Migration Service는 마이그레이션 생성 시 필요한 정보를 수집하고 이를 설정하는 스크립트를 자동 생성합니다.
소스가 이전 네트워크 아키텍처에 있는 AlloyDB 마이그레이션과 관련이 있습니다.
손쉬운 구성
맞춤 방화벽 구성이 필요하지 않습니다.
배스천 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)."]]
