마이그레이션 충실도

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

개요

스키마, 데이터, 메타데이터를 소스 데이터베이스에서 대상 데이터베이스로 마이그레이션할 때는 이 모든 정보가 정확하게 마이그레이션되는지 확인해야 합니다. Database Migration Service는 데이터베이스 객체 (스키마, 데이터, 메타데이터 포함)를 한 데이터베이스에서 다른 데이터베이스로 마이그레이션하는 고화질 방법을 제공합니다.

마이그레이션 프로세스 중에 데이터와 제약조건이 별도로 마이그레이션됩니다. 데이터가 먼저 마이그레이션되고 기본 키, 외래 키, 색인과 같은 제약조건은 초기 전체 덤프 및 로드 후에 인스턴스에 다시 생성됩니다.

다음 데이터, 스키마, 메타데이터 구성요소가 모두 데이터베이스 마이그레이션의 일부로 마이그레이션됩니다.

데이터

• 다음 스키마를 제외한 모든 데이터베이스 및 스키마의 모든 테이블:

  • 정보 스키마 information_schema
  • pg로 시작하는 모든 스키마 (예: pg_catalog)

  이러한 스키마에 대한 자세한 내용은 알려진 제한사항을 참고하세요.

스키마

• 이름 지정

• 기본 키

• 데이터 유형

• 서수 순위

• 기본값

• null 허용 여부

• 자동 증가 속성

• 보조 색인

메타데이터

• 저장 프로시저

• 함수

• 트리거

• 뷰

• 외래 키 제약조건

연속 이전

연속 마이그레이션 중에 데이터 조작 언어 (DML) 변경사항만 자동으로 업데이트됩니다. 소스 및 대상 데이터베이스가 계속 호환되도록 데이터 정의 언어 (DDL) 변경사항을 관리하는 것은 사용자의 책임이며 다음 두 가지 방법으로 할 수 있습니다.

1. 소스 쓰기를 중지하고 소스 및 대상 모두에서 DDL 명령어를 실행합니다. 대상에서 DDL 명령어를 실행하기 전에 DDL 변경사항을 적용하는 Cloud SQL 사용자에게 cloudsqlexternalsync 역할을 부여합니다. 데이터 쿼리 또는 변경을 사용 설정하려면 관련 Cloud SQL 사용자에게 cloudsqlexternalsync 역할을 부여합니다.
2. pglogical.replicate_ddl_command를 사용하여 소스 및 대상의 일관된 지점에서 DDL을 실행합니다. 이 명령어를 실행하는 사용자는 소스와 대상 모두에서 동일한 사용자 이름을 사용해야 하며, 마이그레이션되는 아티팩트(예: 테이블, 시퀀스, 뷰 또는 데이터베이스)의 슈퍼 사용자 또는 소유자여야 합니다.

   다음은 pglogical.replicate_ddl_command 사용의 몇 가지 예입니다.

   다음과 같이 바꿉니다.

   • [SCHEMA]을 사용하려는 테이블 스키마의 이름으로 바꿉니다.
   • [TABLE_NAME]: 테이블 이름
   • 이름 변경 작업을 실행할 때 테이블의 새 이름으로 [NEW_NAME_FOR_TABLE]

   기본 키가 있는 데이터베이스 테이블에 열 추가

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default}'
   );

   기본 키가 없는 데이터베이스 테이블에 열 추가

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default_insert_only}'
   );

   기본 키가 있는 데이터베이스 테이블의 이름 변경

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default}'
   );

   기본 키가 없는 데이터베이스 테이블의 이름 변경

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default_insert_only}'
   );

   기본 키가 있는 데이터베이스 테이블 만들기

   다음 명령어를 실행합니다.

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
          (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default']
      );

   2. select pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

   기본 키가 없는 데이터베이스 테이블 만들기

   다음 명령어를 실행합니다.

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
         (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default_insert_only']
      );

   2. select pglogical.replication_set_add_table(
        'default_insert_only', '[SCHEMA].[TABLE_NAME]'
      );

이전되지 않는 항목

• Cloud SQL 대상 인스턴스에 사용자를 추가하려면 인스턴스로 이동하여 사용자 탭에서 사용자를 추가하거나 PostgreSQL 클라이언트에서 사용자를 추가합니다. PostgreSQL 사용자 만들기 및 관리에 대해 자세히 알아보세요.

• Database Migration Service는 Cloud SQL에서 지원하지 않는 확장 프로그램을 마이그레이션하지 않습니다. 이러한 확장 프로그램이 있더라도 이전이 차단되지는 않지만 원활한 이전 프로세스를 위해 객체나 애플리케이션이 지원되지 않는 확장 프로그램을 참조하지 않는지 확인합니다. 계속하기 전에 소스 데이터베이스에서 이러한 확장 프로그램과 참조를 삭제하는 것이 좋습니다.

• PostgreSQL의 논리적 디코딩 기능이 대규모 객체의 변경사항 디코딩을 지원하지 않으므로 대규모 객체는 복제할 수 없습니다. 대용량 객체를 참조하는 열 유형 oid가 있는 테이블의 경우 행이 동기화되고 새 행이 복제됩니다. 그러나 대상 데이터베이스의 대용량 객체에 액세스하려고 하면(lo_get를 사용하여 읽거나, lo_export를 사용하여 내보내거나, 지정된 oid의 카탈로그 pg_largeobject를 확인) 대용량 객체가 존재하지 않는다는 메시지와 함께 실패합니다.

• 기본 키가 없는 테이블의 경우 Database Migration Service는 변경 데이터 캡처 (CDC) 단계 중에 초기 스냅샷과 INSERT 문의 마이그레이션을 지원합니다. UPDATE 및 DELETE 문은 수동으로 마이그레이션해야 합니다.

• Database Migration Service는 구체화된 뷰의 데이터가 아닌 뷰 스키마만 마이그레이션합니다. 뷰를 채우려면 REFRESH MATERIALIZED VIEW view_name 명령어를 실행합니다.

• 새 대상의 SEQUENCE 상태 (예: last_value)는 소스 SEQUENCE 상태와 다를 수 있습니다.

• 맞춤설정된 테이블스페이스는 대상 Cloud SQL 인스턴스에서 지원되지 않습니다. 맞춤설정된 테이블스페이스 내의 모든 데이터가 Cloud SQL의 기본 pg_default 테이블스페이스로 마이그레이션됩니다.