연속 마이그레이션을 위해 소스 MySQL 데이터베이스 구성

이 페이지에서는 연속 동종 MySQL 마이그레이션을 위해 다음 소스 데이터베이스 인스턴스를 구성하는 방법을 설명합니다.

MySQL용 Cloud SQL 소스 구성

마이그레이션 프로세스에 MySQL용 Cloud SQL 소스 인스턴스를 구성하려면 다음을 수행하세요.

  1. 소스 데이터베이스에 DEFINER 절을 사용하여 사용자가 정의한 메타데이터가 포함되어 있는지 확인합니다. DEFINER 절로 메타데이터 확인을 참고하세요.

    동종 MySQL 마이그레이션을 위한 Database Migration Service는 사용자 계정 및 로그인을 마이그레이션하지 않습니다. DEFINER 절이 있는 사용자 계정으로 정의된 메타데이터가 포함된 소스는 마이그레이션을 차단할 수 있습니다.

  2. 소스 데이터베이스에 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마의 테이블을 참조하는 객체가 포함된 경우 복제본 데이터베이스에도 이러한 시스템 스키마 테이블이 포함되어 있는지 확인합니다.

    복제본 데이터베이스에 이러한 테이블이 없으면 마이그레이션 작업이 Unknown table in system schema 오류와 함께 실패할 수 있습니다.

  3. 소스 데이터베이스에서 바이너리 로그를 사용 설정하고 구성합니다.

    MySQL용 Cloud SQL에서는 PITR (point-in-time recovery)을 사용할 때 바이너리 로깅이 자동으로 사용 설정됩니다. Cloud SQL에서 사용할 수 있는 시스템 플래그를 사용하여 로그 형식과 보관 기간을 구성할 수 있습니다. 다음 단계를 따르세요.

    1. 인스턴스에서 PITR을 사용 설정합니다. 이 기능은 바이너리 로깅을 자동으로 사용 설정합니다. Cloud SQL에서는 PITR 없이 바이너리 로깅을 사용 설정할 수 없습니다. Cloud SQL 문서의 PITR (point-in-time recovery)을 참조하세요.
    2. Cloud SQL 플래그를 사용하여 로깅 구성을 조정합니다. 자세한 내용은 Cloud SQL 문서의 데이터베이스 플래그 구성을 참고하세요.
      1. Database Migration Service를 사용하려면 binlog_format를 ROW로 설정해야 합니다. 이 설정을 조정할 필요가 없습니다. MySQL용 Cloud SQL은 binlog_format 플래그를 ROW으로 자동 설정합니다.
      2. 로그 보관 기간을 데이터베이스 마이그레이션을 지원하기에 충분한 기간으로 설정합니다. 일반적으로 일주일 정도면 충분합니다. 다음 플래그 중 하나를 사용합니다.
        • MySQL 5.6~5.7: expire_logs_days
        • MySQL 8.0 이상: expire_logs_days, binlog_expire_logs_seconds

  4. 인스턴스에 전용 마이그레이션 사용자 계정을 만듭니다. Cloud SQL 문서의 사용자 만들기를 참조하세요. 다음 사항을 확인하세요.

    • 전용 사용자 계정이 모든 호스트(host=%)에서 연결할 수 있도록 허용합니다.
    • 계정의 비밀번호 길이가 32자를 초과하지 않습니다. MySQL 사용자 비밀번호 길이 제한에 대한 자세한 내용은 MySQL 버그 #43439를 참조하세요.

  5. 전용 마이그레이션 사용자 계정에 필요한 권한을 할당합니다. 지속적 마이그레이션의 경우 필요한 권한의 전체 목록은 자체 덤프 파일을 제공하는지 아니면 Database Migration Service 관리 덤프 기능을 사용하는지에 따라 달라집니다.

    관리형 덤프

    Database Migration Service에서 소스 데이터베이스의 전체 덤프를 자동으로 가져오도록 하려면 사용자 계정에 다음 권한을 할당하세요.

    수동 덤프

    mysqldump로 만든 자체 덤프 파일을 제공하는 경우 CDC 단계에 필요한 권한을 제공해야 합니다.

자체 호스팅 MySQL 소스 구성

마이그레이션 프로세스에 자체 호스팅 MySQL 소스 인스턴스를 구성하려면 다음을 수행하세요.

  1. 모든 테이블 (시스템 데이터베이스의 테이블 제외)이 InnoDB 스토리지 엔진을 사용하는지 확인합니다. 다른 스토리지 엔진을 사용하는 경우 테이블을 변환해야 할 수 있습니다. 자세한 내용은 MyISAM에서 InnoDB로 테이블 변환을 참조하세요.
  2. 소스 데이터베이스에 사용자가 DEFINER 절로 정의한 메타데이터가 포함되어 있는지 확인합니다. DEFINER 절로 메타데이터 확인을 참조하세요.

    동종 MySQL 마이그레이션을 위한 Database Migration Service는 사용자 계정과 로그인을 마이그레이션하지 않습니다. DEFINER 절이 있는 사용자 계정으로 정의된 메타데이터가 포함된 소스는 마이그레이션을 차단할 수 있습니다.

  3. 소스 데이터베이스에 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마의 테이블을 참조하는 객체가 포함된 경우 복제본 데이터베이스에도 이러한 시스템 스키마 테이블이 포함되어 있는지 확인합니다.

    복제본 데이터베이스에 이러한 테이블이 없으면 마이그레이션 작업이 Unknown table in system schema 오류와 함께 실패할 수 있습니다.

  4. server-id 설정을 1 이상으로 구성합니다. 자세한 내용은 복제 및 바이너리 로그 옵션 및 변수를 참고하세요.

  5. GTID_MODE이 ON 또는 OFF로 설정되어 있는지 확인합니다. 다른 값은 지원되지 않습니다.

    Database Migration Service는 다음 시나리오에서 GTID_MODE를 ON로 설정해야 합니다.

    GTID_MODE에 대한 자세한 내용은 전역 거래 ID 시스템 변수를 참조하세요.

  6. 소스 데이터베이스에서 바이너리 로그를 사용 설정하고 구성합니다. 다음 단계를 따르세요.

      • 소스 데이터베이스에서 바이너리 로그를 사용 설정합니다.
      • binlog_format을 'ROW'로 설정합니다. 행 기반 바이너리 로깅을 참고하세요.
      • 로그 보관 기간을 데이터베이스 마이그레이션을 지원하기에 충분한 기간으로 설정합니다. 일반적으로 일주일 정도면 충분합니다. 다음 플래그 중 하나를 사용합니다.
        • MySQL 5.5~5.7: expire_logs_days
        • MySQL 8.0: expire_logs_days, binlog_expire_logs_seconds

  7. 인스턴스에 전용 마이그레이션 사용자 계정을 만듭니다. 계정 관리 문을 참조하세요. 다음 사항을 확인하세요.

    • 전용 사용자 계정이 모든 호스트(host=%)에서 연결할 수 있도록 허용합니다.
    • 계정의 비밀번호 길이가 32자를 초과하지 않습니다. MySQL 사용자 비밀번호 길이 제한에 대한 자세한 내용은 MySQL 버그 #43439를 참고하세요.

  8. 전용 마이그레이션 사용자 계정에 필요한 권한을 할당합니다. 연속 마이그레이션의 경우 필요한 전체 권한 목록은 자체 덤프 파일을 제공하는지 또는 Database Migration Service 관리형 덤프 기능을 사용하는지에 따라 달라집니다.

    관리형 덤프

    Database Migration Service에서 소스 데이터베이스의 전체 덤프를 자동으로 수행하도록 하려면 사용자 계정에 다음 권한을 할당합니다.

    수동 덤프

    mysqldump로 만든 자체 덤프 파일을 제공하는 경우 CDC 단계에 필요한 권한을 제공해야 합니다.

MySQL용 Amazon RDS 소스 구성

마이그레이션 프로세스에 MySQL용 Amazon RDS 소스 인스턴스를 구성하려면 다음을 수행하세요.

  1. MySQL용 Amazon RDS는 기본적으로 InnoDB 스토리지 엔진을 사용하지만 다른 스토리지 엔진을 사용할 수 있습니다. 모든 테이블 (시스템 데이터베이스의 테이블 제외)이 InnoDB 스토리지 엔진을 사용하는지 확인합니다. 다른 스토리지 엔진을 사용하는 경우 테이블을 변환해야 할 수 있습니다. 자세한 내용은 MyISAM에서 InnoDB로 테이블 변환을 참고하세요.
  2. 소스 데이터베이스에 DEFINER 절을 사용하여 사용자가 정의한 메타데이터가 포함되어 있는지 확인합니다. DEFINER 절로 메타데이터 확인을 참조하세요.

    동종 MySQL 마이그레이션을 위한 Database Migration Service는 사용자 계정 및 로그인을 마이그레이션하지 않습니다. DEFINER 절이 있는 사용자 계정으로 정의된 메타데이터가 포함된 소스는 이전을 차단할 수 있습니다.

  3. 소스 데이터베이스에 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마의 테이블을 참조하는 객체가 포함된 경우 복제본 데이터베이스에도 이러한 시스템 스키마 테이블이 포함되어 있는지 확인합니다.

    복제본 데이터베이스에 이러한 테이블이 없으면 마이그레이션 작업이 Unknown table in system schema 오류와 함께 실패할 수 있습니다.

  4. GTID_MODE가 ON 또는 OFF로 설정되어 있는지 확인합니다. 다른 값은 지원되지 않습니다. MySQL용 Amazon RDS는 기본적으로 GTID_MODE = OFF을 사용합니다.

    Database Migration Service는 다음 시나리오에서 GTID_MODE이 ON로 설정되어야 합니다.

    GTID_MODE에 대한 자세한 내용은 전역 거래 ID 시스템 변수를 참조하세요.

  5. 소스 데이터베이스에서 바이너리 로그를 확인하고 구성합니다. 다음 단계를 따르세요.

    1. 인스턴스에서 자동 백업을 사용하는지 확인합니다. Amazon RDS는 자동 백업이 사용 설정된 경우에만 바이너리 로그를 생성합니다. 자세한 내용은 Amazon RDS 문서의 자동 백업 사용 설정을 참조하세요.

    2. 로그 보관 기간을 데이터베이스 마이그레이션을 지원하기에 충분한 기간으로 설정합니다. 일반적으로 일주일 정도면 충분합니다. Amazon RDS 문서의 바이너리 로그 구성 설정 및 표시를 참고하세요.

    3. 변경사항이 적용되도록 서버를 다시 시작합니다.

  6. 인스턴스에 전용 마이그레이션 사용자 계정을 만듭니다. 계정 관리 명세서를 참조하세요. 다음 사항을 확인하세요.

    • 전용 사용자 계정이 모든 호스트(host=%)에서 연결할 수 있도록 허용합니다.
    • 계정의 비밀번호 길이가 32자를 초과하지 않습니다. MySQL 사용자 비밀번호 길이 제한에 대한 자세한 내용은 MySQL 버그 #43439를 참조하세요.

  7. 전용 마이그레이션 사용자 계정에 필요한 권한을 할당합니다. 연속 마이그레이션의 경우 필요한 전체 권한 목록은 자체 덤프 파일을 제공하는지 또는 Database Migration Service 관리형 덤프 기능을 사용하는지에 따라 달라집니다.

    관리형 덤프

    Database Migration Service에서 소스 데이터베이스의 전체 덤프를 자동으로 수행하도록 하려면 사용자 계정에 다음 권한을 할당합니다.

    수동 덤프

    mysqldump로 만든 자체 덤프 파일을 제공하는 경우 CDC 단계에 필요한 권한을 제공해야 합니다.

MySQL용 Amazon Aurora 소스 구성

마이그레이션 프로세스에 MySQL용 Amazon Aurora 소스 인스턴스를 구성하려면 다음을 수행하세요.

  1. 소스 데이터베이스에 DEFINER 절을 사용하여 사용자가 정의한 메타데이터가 포함되어 있는지 확인합니다. DEFINER 절로 메타데이터 확인을 참고하세요.

    동종 MySQL 마이그레이션을 위한 Database Migration Service는 사용자 계정 및 로그인을 마이그레이션하지 않습니다. DEFINER 절이 있는 사용자 계정으로 정의된 메타데이터가 포함된 소스는 이전을 차단할 수 있습니다.

  2. 소스 데이터베이스에 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마의 테이블을 참조하는 객체가 포함된 경우 복제본 데이터베이스에도 이러한 시스템 스키마 테이블이 포함되어야 합니다.

    복제본 데이터베이스에 이러한 테이블이 없으면 마이그레이션 작업이 Unknown table in system schema 오류와 함께 실패할 수 있습니다.

  3. GTID_MODE이 ON 또는 OFF로 설정되어 있는지 확인합니다. 다른 값은 지원되지 않습니다. MySQL용 Amazon Aurora는 기본적으로 GTID_MODE = OFF를 사용합니다.

    Database Migration Service는 다음 시나리오에서 GTID_MODE를 ON로 설정해야 합니다.

    GTID_MODE에 대한 자세한 내용은 전역 거래 ID 시스템 변수를 참조하세요.

  4. 소스 데이터베이스에서 바이너리 로그를 사용 설정하고 구성합니다. 다음 단계를 따르세요.

    1. MySQL 데이터베이스에 바이너리 로깅을 사용 설정합니다.

    2. 데이터베이스 마이그레이션을 지원하기에 충분한 기간으로 로그 보관 기간을 설정합니다. 일반적으로 일주일 정도면 충분합니다. 바이너리 로그 구성 설정 및 표시를 참조하세요.

    3. 변경사항이 적용되도록 서버를 다시 시작합니다.

  5. 인스턴스에 전용 마이그레이션 사용자 계정을 만듭니다. 계정 관리 명세서를 참조하세요. 다음 사항을 확인하세요.

    • 전용 사용자 계정이 모든 호스트(host=%)에서 연결할 수 있도록 허용합니다.
    • 계정 비밀번호가 32자(영문 기준)를 초과하지 않습니다. MySQL 사용자 비밀번호 길이 제한에 대한 자세한 내용은 MySQL 버그 #43439를 참조하세요.

  6. 전용 마이그레이션 사용자 계정에 필요한 권한을 할당합니다. 연속 마이그레이션의 경우 필요한 전체 권한 목록은 자체 덤프 파일을 제공하는지 또는 Database Migration Service 관리형 덤프 기능을 사용하는지에 따라 달라집니다.

    관리형 덤프

    Database Migration Service에서 소스 데이터베이스의 전체 덤프를 자동으로 수행하도록 하려면 사용자 계정에 다음 권한을 할당합니다.

    수동 덤프

    mysqldump로 생성된 덤프 파일을 직접 제공하는 경우 CDC 단계에 필요한 권한을 제공해야 합니다.

MySQL용 Microsoft Azure Database 소스 구성

마이그레이션 프로세스에 Microsoft Azure Database for MySQL 소스 인스턴스를 구성하려면 다음을 수행하세요.

  1. 소스 데이터베이스에 DEFINER 절을 사용하여 사용자가 정의한 메타데이터가 포함되어 있는지 확인합니다. DEFINER 절로 메타데이터 확인을 참고하세요.

    동종 MySQL 마이그레이션을 위한 Database Migration Service는 사용자 계정 및 로그인을 마이그레이션하지 않습니다. DEFINER 절이 있는 사용자 계정으로 정의된 메타데이터가 포함된 소스는 이전을 차단할 수 있습니다.

  2. 소스 데이터베이스에 mysql, performance_schema, information_schema, ndbinfo 또는 sys 시스템 스키마의 테이블을 참조하는 객체가 포함된 경우 복제본 데이터베이스에도 이러한 시스템 스키마 테이블이 포함되어야 합니다.

    복제본 데이터베이스에 이러한 테이블이 없으면 마이그레이션 작업이 Unknown table in system schema 오류와 함께 실패할 수 있습니다.

  3. GTID_MODE이 ON 또는 OFF로 설정되어 있는지 확인합니다. 다른 값은 지원되지 않습니다. MySQL용 Microsoft Azure Database는 기본적으로 GTID_MODE = OFF를 사용합니다.

    Database Migration Service는 다음 시나리오에서 GTID_MODE를 ON로 설정해야 합니다.

    GTID_MODE에 대한 자세한 내용은 전역 거래 ID 시스템 변수를 참조하세요.

  4. 소스 데이터베이스에서 바이너리 로깅 설정을 확인하고 구성합니다. 다음 단계를 따르세요.

    1. 바이너리 로깅은 MySQL용 Microsoft Azure Database에서 기본적으로 사용 설정됩니다. 사용 설정할 필요는 없지만 기능이 사용 설정되어 있는지 확인합니다. 자세한 내용은 Microsoft 문서를 참고하세요.

    2. binlog_expire_logs_seconds를 데이터베이스 마이그레이션을 지원하기에 충분한 기간으로 설정합니다. 일반적으로 일주일이면 충분합니다.

      자세한 내용은 MySQL용 Azure Database에서 서버 파라미터 구성 및 Microsoft 문서의 binlog_expire_logs_seconds 파라미터를 참고하세요.

    3. 변경사항이 적용되도록 서버를 다시 시작합니다.

  5. require_secure_transport 설정 값을 확인합니다.

    기본적으로 Microsoft Azure 데이터베이스는 모든 수신 연결에 SSL/TLS 암호화를 요구합니다. require_secure_transport 값에 따라 소스 연결 프로필을 만들 때 다음 암호화 설정 중 하나를 사용합니다.

    • require_secure_transport가 on로 설정된 경우 기본, TLS 또는 mTLS를 선택합니다.
    • require_secure_transport이 off로 설정된 경우 없음을 선택합니다.

  6. 인스턴스에 전용 마이그레이션 사용자 계정을 만듭니다. 계정 관리 문을 참조하세요. 다음 사항을 확인하세요.

    • 전용 사용자 계정이 모든 호스트(host=%)에서 연결할 수 있도록 허용합니다.
    • 계정 비밀번호는 32자(영문 기준) 이하여야 합니다. MySQL 사용자 비밀번호 길이 제한에 대한 자세한 내용은 MySQL 버그 #43439를 참고하세요.

  7. 전용 마이그레이션 사용자 계정에 필요한 권한을 할당합니다. 연속 마이그레이션의 경우 필요한 전체 권한 목록은 자체 덤프 파일을 제공하는지 또는 Database Migration Service 관리형 덤프 기능을 사용하는지에 따라 달라집니다.

    관리형 덤프

    Database Migration Service에서 소스 데이터베이스의 전체 덤프를 자동으로 가져오도록 하려면 사용자 계정에 다음 권한을 할당하세요.

    수동 덤프

    mysqldump로 생성된 덤프 파일을 직접 제공하는 경우 CDC 단계에 필요한 권한을 제공해야 합니다.

다음 단계

동종 MySQL용 Cloud SQL 마이그레이션에 관한 단계별 마이그레이션 안내를 확인하려면 MySQL용 Cloud SQL 마이그레이션 시작하기를 참고하세요.