다음을 통해 공유

Azure Database for MySQL에 데이터 복제 - 유동 서버

  • 아티클

적용 대상: Azure Database for MySQL - 유연한 서버

입력 데이터 복제를 사용하면 외부 MySQL 서버에서 Azure Database for MySQL 유연한 서버 인스턴스로 데이터를 동기화할 수 있습니다. 외부 서버는 온-프레미스, 가상 머신, Azure Database for MySQL 단일 서버 또는 다른 클라우드 공급자가 호스트하는 데이터베이스 서비스에 있을 수 있습니다. 입력 데이터 복제는 이진 로그(binlog) 파일 위치 또는 GTID 기반 복제를 기반으로 합니다. binlog 복제에 대한 자세한 내용은 MySQL 복제를 참조하세요.

참고 항목

고가용성으로 사용하도록 설정된 서버에 대한 입력 데이터 복제 구성은 GTID 기반 복제를 통해서만 지원됩니다.

입력 데이터 복제를 사용하는 경우

입력 데이터 복제 사용을 고려할 주요 시나리오는 다음과 같습니다.

  • 하이브리드 데이터 동기화: 데이터 내부 복제를 사용하면 온-프레미스 서버와 Azure Databases for MySQL 유연한 서버 사이에 데이터를 동기화할 수 있습니다. 이렇게 동기화하면 하이브리드 애플리케이션을 만드는 데 도움이 됩니다. 이 메서드는 기존 로컬 데이터베이스 서버가 있지만 최종 사용자에게 더 가까운 지역으로 데이터를 이동하려는 경우 매력적입니다.
  • 다중 클라우드 동기화: 복잡한 클라우드 솔루션의 경우 데이터 내부 복제를 사용하여 해당 클라우드에 호스팅된 데이터베이스 서비스 및 가상 머신을 포함하여 Azure Database for MySQL Flexible Server와 다른 클라우드 공급자 간에 데이터를 동기화합니다.
  • 마이그레이션: 고객은 입력 데이터 복제를 통해 MyDumper/MyLoader 등의 오픈 소스 도구를 사용하여 최소 시간 마이그레이션을 수행할 수 있습니다. 원본에서 대상 데이터베이스로 프로덕션 부하를 선택적으로 사용하는 경우 데이터를 복제할 수 있습니다.

마이그레이션 시나리오에 대해서는 Azure DMS(Database Migration Service)를 사용합니다.

제한 사항 및 고려 사항

데이터가 복제되지 않음

원본 서버의 mysql 시스템 데이터베이스는 복제되지 않습니다. 또한 원본 서버에서 계정 및 사용 권한에 대해 변경한 내용은 복제되지 않습니다. 원본 서버에서 계정을 만들고 이 계정으로 복제 서버에 액세스해야 하는 경우 복제 서버에서 동일한 계정을 수동으로 만듭니다. 시스템 데이터베이스의 테이블을 이해하려면 MySQL 설명서를 참조하세요.

HA(고가용성) 지원 서버에서 입력 데이터 복제가 지원됨

HA(고가용성) 지원 서버에 대한 입력 데이터 복제 지원은 GTID 기반 복제를 통해서만 제공됩니다.

GTID를 사용한 복제를 위한 저장 프로시저는 모든 HA 지원 서버에서 이름 mysql.az_replication_change_master_with_gtid로 사용할 수 있습니다.

필터

매개 변수 replicate_wild_ignore_table은 복제본 서버 테이블용 복제 필터를 만듭니다. Azure Portal에서 이 매개 변수를 편집하려면 복제본으로 사용되는 Azure Database for MySQL 유연한 서버 인스턴스로 이동하고 "서버 매개 변수"를 선택하여 replicate_wild_ignore_table 매개 변수를 보거나 편집합니다.

요구 사항

  • 원본 서버 버전은 MySQL 버전 5.7 이상이어야 합니다.

  • 원본 및 복제 서버 버전에 대해 동일한 버전을 사용하는 것을 권장합니다. 예를 들어 둘 다 MySQL 버전 5.7이거나 둘 다 MySQL 버전 8.0이어야 합니다.

  • 각 테이블에 기본 키를 포함하는 것을 권장합니다. 기본 키가 없는 테이블이 있는 경우 복제 시 속도가 저하될 수도 있습니다.

  • 원본 서버는 MySQL InnoDB 엔진을 사용해야 합니다.

  • 사용자는 원본 서버에서 이진 파일 로깅을 구성하고 새 사용자를 만들 수 있는 올바른 권한이 있어야 합니다.

  • 복제본이 이러한 변경 내용을 적용하기 전에 원본 서버의 이진 로그 파일을 제거하면 안 됩니다. 원본이 Azure Database for MySQL 유연한 서버인 경우 유연한 서버 또는 단일 서버에 대한 binlog_expire_logs_seconds를 구성하는 방법을 참조하세요.

  • 원본 서버에 SSL을 사용하도록 설정한 경우 도메인에 제공된 SSL CA 인증서가 mysql.az_replication_change_master 저장 프로시저에 포함되어 있는지 확인합니다. 다음 예 및 master_ssl_ca 매개 변수를 참조하세요.

  • 원본 서버를 호스트하는 컴퓨터에서 포트 3306에 대한 인바운드 및 아웃바운드 트래픽을 둘 다 허용하는지 확인합니다.

  • 공용 액세스의 경우, 공용 IP 주소가 원본 서버에 있는지, DNS에 공개적으로 액세스할 수 있는지 또는 FQDN(정규화된 도메인 이름)이 원본 서버에 있는지 확인합니다. 프라이빗 엔드포인트가 있고 공용 액세스를 사용하지 않도록 설정한 경우 입력 데이터 복제가 지원되지 않음

  • 프라이빗 액세스(VNet 통합)를 사용하여 원본 서버 이름을 확인할 수 있고 Azure Database for MySQL 유연한 서버 인스턴스가 실행되는 VNet에서 액세스할 수 있는지 확인합니다. (자세한 내용은 Azure Virtual Network에서 리소스의 이름 확인을 참조하세요.)

생성된 보이지 않는 기본 키

MySQL 버전 8.0 이상의 경우 생성된 GIPK(보이지 않는 기본 키)는 모든 Azure Database for MySQL 유연한 서버 인스턴스에 대해 기본적으로 사용 설정됩니다. MySQL 8.0 이상 서버는 보이지 않는 열 my_row_id를 테이블에 추가하고 해당 열의 기본 키를 추가합니다. 여기서 InnoDB 테이블은 명시적 기본 키 없이 만들어집니다. 이 기능을 사용하도록 설정하면 아래 설명대로 일부 데이터 입력 복제 사용 사례에 영향을 줄 수 있습니다.

  • 원본 서버가 기본 키 없이 테이블에 기본 키를 만드는 경우 "오류 1068(42000): 기본 키가 여러 개 정의됨"이라는 복제 오류로 인해 데이터 입력 복제가 실패합니다. 상황을 완화하려면 다음 sql 명령을 실행하고 복제 오류를 건너뛰어 데이터 입력 복제를 다시 시작합니다.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • 원본 서버에 auto_increment 열을 고유 키로 추가하는 경우 "오류 1075(42000): 테이블 정의가 올바르지 않습니다. 하나의 자동 열만 허용되며 해당 열을 키로 정의해야 합니다"라는 복제 오류로 인해 데이터 입력 복제가 실패합니다. 상황을 완화하려면 다음의 sql 명령을 실행한 다음 "sql_generate_invisible_primary_key"를 OFF로 설정하고, 복제 오류를 건너뛰어 데이터 입력 복제를 재시작합니다.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • "sql_generate_invisible_primary_key"가 ON일 때 지원하지 않는 여타 SQL을 원본 서버가 실행하는 경우 데이터 입력 복제가 실패합니다. 예를 들어, 파티션 테이블을 만듭니다. 이러한 시나리오에서의 완화책은 "sql_generate_invisible_primary_key"를 OFF로 설정하고 데이터 입력 복제를 재시작하는 것입니다.

다음 단계