다음을 통해 공유

Azure Database for MySQL - 유연한 서버 입력 데이터 복제를 구성하는 방법

  • 아티클

이 문서에서는 원본 및 복제본 서버를 구성하여 Azure Database for MySQL - 유연한 서버의 Azure Database for MySQL 유연한 서버로 데이터 복제를 설정하는 방법을 설명합니다. 이 문서에서는 이전에 MySQL 서버 및 데이터베이스를 사용한 경험이 있다고 가정합니다.

참고 항목

이 문서에는 Microsoft에서 더 이상 사용하지 않는 용어인 슬레이브라는 용어에 대한 참조가 포함되어 있습니다. 소프트웨어에서 용어가 제거되면 이 문서에서 해당 용어가 제거됩니다.

Azure Database for MySQL 유연한 서버 인스턴스 에서 복제본을 만들려면 데이터를 Azure Database for MySQL로 복제 - 유연한 서버 는 온-프레미스, VM(가상 머신) 또는 클라우드 데이터베이스 서비스에서 원본 MySQL 서버의 데이터를 동기화합니다. 이진 로그(binlog) 파일 위치 기반 복제 또는 GTID 기반 복제를 사용하여 데이터 입력 복제를 구성할 수 있습니다. binlog 복제에 대한 자세한 내용은 MySQL 복제를 참조하세요.

이 문서의 단계를 수행하기 전에 입력 데이터 복제에 대한 제한 사항 및 요구 사항을 검토합니다.

복제본으로 사용할 Azure Database for MySQL 유연한 서버 인스턴스 만들기

  1. Azure Database for MySQL 유연한 서버의 새 인스턴스를 만듭니다(예: replica.mysql.database.azure.com). 빠른 시작을 참조하세요. 서버 만들기를 위해 Azure Portal을 사용하여 Azure Database for MySQL 인스턴스를 만듭니다. 이 서버는 입력 데이터 복제에 대한 "복제본" 서버입니다.

  2. 동일한 사용자 계정 및 해당 권한을 만듭니다.

    사용자 계정은 원본 서버에서 복제본 서버로 복제되지 않습니다. 사용자에게 복제본 서버에 대한 액세스 권한을 제공하려는 경우 새로 만든 이 Azure Database for MySQL 유연한 서버 인스턴스에서 모든 계정 및 해당 권한을 수동으로 만들어야 합니다.

원본 MySQL 서버 구성

다음 단계에서는 입력 데이터 복제를 위해 온-프레미스, 가상 머신 또는 다른 클라우드 공급자가 호스트하는 데이터베이스 서비스에서 호스트되는 MySQL 서버를 준비하고 구성합니다. 이 서버는 입력 데이터 복제에 대한 "원본" 서버입니다.

  1. 계속하기 전에 원본 서버 요구 사항을 검토합니다.

  2. 네트워킹 요구 사항

    • 원본 서버가 3306 포트에서 인바운드 및 아웃바운드 트래픽을 모두 허용하고 공용 IP 주소가 있는지, DNS에 공개적으로 액세스할 수 있는지, 아니면 FQDN(정규화된 도메인 이름)이 있는지 확인합니다.

    • 프라이빗 액세스(VNet 통합)를 사용 중인 경우 원본 서버와 복제본 서버가 호스트되는 VNet 간에 연결이 있는지 확인합니다.

    • ExpressRoute 또는 VPN을 사용하여 온-프레미스 원본 서버에 사이트 간 연결을 제공하는지 확인하세요. 가상 네트워크를 만드는 방법에 대한 자세한 내용은 Virtual Network 설명서를 참조하세요. 특히 단계별 세부 정보를 제공하는 빠른 시작 문서를 참조하세요.

    • 복제본 서버에서 프라이빗 액세스(VNet 통합)가 사용되고 원본이 Azure VM인 경우 VNet 간 연결이 설정되었는지 확인합니다. VNet-Vnet 피어링이 지원됩니다. 다른 연결 방법을 사용하여 VNet 간 연결과 같이 여러 지역에서 VNet 간에 통신할 수도 있습니다. 자세한 내용은 VNet 간 VPN 게이트웨이를 참조하세요.

    • 가상 네트워크 네트워크 보안 그룹 규칙이 아웃바운드 포트 3306(MySQL이 Azure VM에서 실행 중인 경우에도 인바운드)을 차단하지 않는지 확인합니다. 가상 네트워크 NSG 트래픽 필터링에 대한 자세한 내용은 네트워크 보안 그룹을 사용하여 네트워크 트래픽 필터링 문서를 참조하세요.

    • 복제 서버 IP 주소를 허용하도록 원본 서버의 방화벽 규칙을 구성합니다.

  3. bin-log 위치 또는 GTID 기반 데이터 입력 복제를 사용할지에 따라 적절한 단계를 수행합니다.

    다음 명령을 실행하여 원본에서 이진 로깅이 사용하도록 설정되어 있는지 확인합니다.

    SHOW VARIABLES LIKE 'log_bin';

    log_bin 변수가 "ON" 값으로 반환되면 서버에서 이진 로깅이 사용하도록 설정됩니다.

    log_bin이 'OFF' 값으로 반환되고 원본 서버가 온-프레미스 또는 구성 파일(my.cnf)에 액세스할 수 있는 가상 머신에서 실행되는 경우 다음 단계를 따르면 됩니다.

    1. 원본 서버에서 MySQL 구성 파일(my.cnf)을 찾습니다. 예를 들어: /etc/my.cnf입니다.

    2. 구성 파일을 열어 편집하고, 파일에서 mysqld 섹션을 찾습니다.

    3. mysqld 섹션에서 다음 줄을 추가합니다.

      log-bin=mysql-bin.log

    4. 변경 사항을 적용하려면 원본 서버에서 MySQL 서비스를 다시 시작합니다.

    5. 서버가 다시 시작되면 이전과 동일한 쿼리를 실행하여 이진 로깅이 사용하도록 설정되었는지 확인합니다.

      SHOW VARIABLES LIKE 'log_bin';

  4. 원본 서버 설정을 구성합니다.

    입력 데이터 복제를 사용하려면 원본 서버와 복제본 서버 간에 lower_case_table_names 매개 변수가 일치해야 합니다. Azure Database for MySQL유연한 서버에서 이 매개 변수는 기본적으로 1입니다.

    SET GLOBAL lower_case_table_names = 1;

  5. 새 복제 역할을 만들고, 권한을 설정합니다.

    원본 서버에서 복제 권한으로 구성된 사용자 계정을 만듭니다. 이 작업은 SQL 명령 또는 MySQL Workbench와 같은 도구를 통해 수행할 수 있습니다. 사용자를 만들 때 지정해야 하므로 SSL을 사용하여 복제할지 여부를 고려합니다. 원본 서버에서 사용자 계정을 추가하는 방법을 이해하려면 MySQL 설명서를 참조하세요.

    다음 명령에서 새로 만든 복제 역할은 원본 자체를 호스팅하는 컴퓨터뿐만 아니라 모든 컴퓨터에서도 원본에 액세스할 수 있습니다. 이 작업은 create user 명령에 “syncuser@’%’”를 지정하여 수행합니다. 계정 이름 지정에 대한 자세한 내용은 MySQL 설명서를 참조하세요.

    SSL을 사용한 복제

    모든 사용자 연결에 SSL이 필요하도록 설정하려면 다음 명령을 사용하여 사용자를 만듭니다.

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;

    SSL 없이 복제

    모든 연결에 SSL이 필요하지 않은 경우 다음 명령을 사용하여 사용자를 만듭니다.

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

  6. 원본 서버를 읽기 전용 모드로 설정합니다.

    데이터베이스를 덤프하기 전에 서버를 읽기 전용 모드로 설정해야 합니다. 읽기 전용 모드에 있는 동안 원본 서버에서 쓰기 트랜잭션을 처리할 수 없습니다. 비즈니스에 미치는 영향을 평가하고, 필요한 경우 사용량이 적은 시간에 읽기 전용 창을 예약합니다.

    FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;

  7. 이진 로그 파일 이름 및 오프셋을 가져옵니다.

    show master status 명령을 실행하여 현재 이진 로그 파일 이름 및 오프셋을 확인합니다.

    show master status;

    결과는 다음과 비슷합니다. 이후 단계에서 사용할 수 있도록 이진 파일 이름을 적어 두세요.

    마스터 상태 결과의 스크린샷.

원본 서버 덤프 및 복원

  1. Azure Database for MySQL 유연한 서버에 복제할 데이터베이스 및 테이블을 결정하고 원본 서버에서 덤프를 수행합니다.

    mysqldump를 사용하여 주 서버에서 데이터베이스를 덤프할 수 있습니다. 자세한 내용은 덤프 및 복원을 참조하세요. MySQL 라이브러리 및 테스트 라이브러리는 덤프할 필요가 없습니다.

  2. 원본 서버를 읽기/쓰기 모드로 설정합니다.

    데이터베이스가 덤프되면 원본 MySQL 서버를 읽기/쓰기 모드로 다시 변경합니다.

    SET GLOBAL read_only = OFF;
UNLOCK TABLES;

    참고 항목

    서버가 읽기/쓰기 모드로 다시 설정되기 전에 전역 변수 GTID_EXECUTED를 사용하여 GTID 정보를 검색할 수 있습니다. 이 작업은 이후 단계에서 복제본 서버에서 GTID를 설정하는 데 사용됩니다.

  3. 덤프 파일을 새 서버로 복원합니다.

    Azure Database for MySQL 유연한 서버에서 만든 서버로 덤프 파일을 복원합니다. 덤프 파일을 MySQL 서버로 복원하는 방법은 덤프 및 복원을 참조하세요. 덤프 파일이 큰 경우, 복제본 서버와 동일한 지역 내의 Azure 가상 머신에 업로드합니다. 가상 머신에서 Azure Database for MySQL 유연한 서버 인스턴스로 복원합니다.

참고 항목

덤프 및 복원할 때에만 데이터베이스를 읽도록 설정하지 않으려면 mydumper/myloader를 사용하면 됩니다.

복제본 서버에서 GTID 설정

  1. bin-log 위치 기반 복제를 사용하는 경우 단계를 건너뜁니다.

  2. 대상(복제본) 서버의 GTID 기록을 재설정하려면 원본에서 가져온 덤프 파일의 GTID 정보가 필요합니다.

  3. 원본의 이 GTID 정보를 사용하여 다음 CLI 명령을 사용하여 복제본 서버에서 GTID 재설정을 실행합니다.

    az mysql flexible-server gtid reset --resource-group  <resource group> --server-name <replica server name> --gtid-set <gtid set from the source server> --subscription <subscription id>

자세한 내용은 GTID 재설정을 참조하세요.

참고 항목

지역 중복 백업이 설정된 서버에서는 GTID 재설정을 수행할 수 없습니다. 서버에서 GTID 재설정을 수행하려면 지역 중복을 사용하지 않도록 설정하세요. GTID를 재설정한 후 지역 중복 옵션을 다시 사용하도록 설정할 수 있습니다. GTID 재설정 작업은 사용 가능한 모든 백업을 무효화하므로 지역 중복성을 다시 사용하도록 설정하면 서버에서 지역 복원을 수행하기까지 하루가 걸릴 수 있습니다.

  1. 원본 서버를 설정합니다.

    모든 입력 데이터 복제 기능은 저장 프로시저에 의해 수행됩니다. 입력 데이터 복제 저장 프로시저에서 모든 프로시저를 확인할 수 있습니다. 저장 프로시저는 MySQL 셸 또는 MySQL Workbench에서 실행할 수 있습니다.

    두 서버를 연결하고 복제를 시작하려면, Azure Database for MySQL 서비스에서 대상 복제본 서버에 로그인하고 외부 인스턴스를 원본 서버로 설정합니다. 이 작업은 Azure Database for MySQL 서버의 mysql.az_replication_change_master 또는 mysql.az_replication_change_master_with_gtid 저장 프로시저를 사용하여 수행됩니다.

    CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', <master_port>, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');

    CALL mysql.az_replication_change_master_with_gtid('<master_host>', '<master_user>', '<master_password>', <master_port>,'<master_ssl_ca>');
    • master_host: 원본 서버의 호스트 이름
    • master_user: 원본 서버의 사용자 이름
    • master_password: 원본 서버의 암호
    • master_port: 원본 서버에서 연결을 수신 대기하는 포트 번호 (3306은 MySQL에서 수신 대기하는 기본 포트임)
    • master_log_file: 실행 중인 show master status의 이진 로그 파일 이름
    • master_log_pos: 실행 중인 show master status의 이진 로그 위치
    • master_ssl_ca: CA 인증서의 컨텍스트. SSL을 사용하지 않는 경우 빈 문자열을 전달합니다.

    이 매개 변수를 변수로 전달하는 것이 좋습니다. 자세한 내용은 다음 예제를 참조하세요.

    참고 항목

    • 원본 서버가 Azure VM에서 호스팅되는 경우 원본 서버와 복제본 서버가 서로 통신할 수 있도록 "Azure 서비스에 대한 액세스 허용"을 "켜기"로 설정합니다. 이 설정은 연결 보안 옵션에서 변경할 수 있습니다. 자세한 내용은 Azure Portal을 사용하여 Azure Database for MySQL - 유연한 서버에 대한 방화벽 규칙 관리를 참조 하세요.
    • mydumper/myloader를 사용하여 데이터베이스를 덤프한 경우 /backup/metadata 파일에서 master_log_file 및 master_log_pos를 가져올 수 있습니다.

    예제

    SSL을 사용한 복제

    @cert 변수는 다음 MySQL 명령을 실행하여 만듭니다.

    SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'`S CONTEXT HERE
-----END CERTIFICATE-----'

    SSL을 사용한 복제는 "companya.com" 도메인에서 호스트되는 원본 서버와 Azure Database for MySQL 유연한 서버에서 호스트되는 복제본 서버 간에 설정됩니다. 이 저장 프로시저는 복제본에서 실행됩니다.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, @cert);

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, @cert);

    SSL 없이 복제

    SSL이 없는 복제는 "companya.com" 도메인에서 호스트되는 원본 서버와 Azure Database for MySQL 유연한 서버에서 호스트되는 복제본 서버 간에 설정됩니다. 이 저장 프로시저는 복제본에서 실행됩니다.

    CALL mysql.az_replication_change_master('master.companya.com', 'syncuser', 'P@ssword!', 3306, 'mysql-bin.000002', 120, '');

    CALL mysql.az_replication_change_master_with_gtid('master.companya.com', 'syncuser', 'P@ssword!', 3306, '');

  2. 복제를 시작합니다.

    mysql.az_replication_start 저장 프로시저를 호출하여 복제를 시작합니다.

    CALL mysql.az_replication_start;

  3. 복제 상태를 확인합니다.

    복제본 서버에서 show slave status 명령을 호출하여 복제 상태를 확인합니다.

    show slave status;

    올바른 복제 상태를 확인하려면 모니터링 페이지에서 복제 메트릭 - 복제본 IO 상태 및 복제본 SQL 상태를 참조하세요.

    Seconds_Behind_Master가 '0'이면 복제가 잘 작동하는 것입니다. Seconds_Behind_Master는 복제본이 얼마나 지연되었는지를 나타냅니다. 값이 "0"이 아니면 복제본 서버에서 업데이트를 처리하고 있는 것입니다.

입력 데이터 복제 작업에 대한 기타 유용한 저장 프로시저

복제 중지

원본 서버와 복제본 서버 간의 복제를 중지하려면 다음 저장 프로시저를 사용합니다.

CALL mysql.az_replication_stop;

복제 관계 제거

원본 서버와 복제본 서버 간의 관계를 제거하려면 다음 저장 프로시저를 사용합니다.

CALL mysql.az_replication_remove_master;

복제 오류 건너뛰기

복제 오류를 건너뛰고 복제를 계속 진행하려면 다음 저장 프로시저를 사용합니다.

CALL mysql.az_replication_skip_counter;

SHOW BINLOG EVENTS [IN 'log_name'] [FROM pos][LIMIT [offset,] row_count]

이진 로그 결과 표시 스크린샷

다음 단계

Azure Database for MySQL - 유연한 서버로 데이터 복제