다음을 통해 공유


Azure Database for MySQL 데이터 내부 복제를 구성하는 방법

적용 대상: Azure Database for MySQL - 단일 서버

Important

Azure Database for MySQL 단일 서버는 사용 중지를 향한 여정에 있습니다. Azure Database for MySQL 유연한 서버로 업그레이드하는 것이 좋습니다. Azure Database for MySQL 유연한 서버로 마이그레이션하는 방법에 대한 자세한 내용은 Azure Database for MySQL 단일 서버에 대한 새로운 소식을 참조하세요

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

참고 항목

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

Azure Database for MySQL 서비스에서 복제본을 만들기 위해 입력 데이터 복제가 온-프레미스, VM(가상 머신) 또는 클라우드 데이터베이스 서비스에서 원본 MySQL 서버의 데이터를 동기화합니다. 입력 데이터 복제는 MySQL에 네이티브인 이진 로그(binlog) 파일 위치 기반 또는 GTID 기반 복제를 기반으로 합니다. binlog 복제에 대한 자세히 알려면 MySQL binlog 복제 개요를 참조합니다.

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

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

  1. Azure Database for MySQL 단일 서버의 새 인스턴스(예: replica.mysql.database.azure.com)를 만듭니다. 서버를 만드는 방법은 Azure Portal을 사용하여 Azure Database for MySQL 서버 만들기를 참조하세요. 이 서버는 입력 데이터 복제에 대한 "복제본" 서버입니다.

    Important

    입력 데이터 복제는 이러한 계층에서만 지원되므로 Azure Database for MySQL 서버는 범용 또는 메모리 최적화 가격 책정 계층에서 만들어야 합니다. GTID는 버전 5.7 및 8.0에서 지원되며, 최대 16TB(범용 스토리지 v2) 스토리지를 지원하는 서버에서만 지원됩니다.

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

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

  3. 원본 서버의 IP 주소를 복제본의 방화벽 규칙에 추가합니다.

    Azure Portal 또는 Azure CLI를 사용하여 방화벽 규칙을 업데이트합니다.

  4. 선택 사항 - GTID 기반 복제를 원본 서버에서 Azure Database for MySQL 복제본 서버로 사용하려면 아래의 포털 이미지와 같이 Azure Database for MySQL 서버에서 다음 서버 매개 변수를 사용하도록 설정해야 합니다.

    Azure Database for MySQL 서버에서 GTID 사용

원본 MySQL 서버 구성

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

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

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

    다른 컴퓨터에서 호스팅되는 MySQL 명령줄과 같은 도구 또는 Azure Portal에서 사용할 수 있는 Azure Cloud Shell에서 연결을 시도하여 원본 서버에 대한 연결을 테스트합니다.

    조직에 엄격한 보안 정책이 있고 원본 서버의 모든 IP 주소가 Azure에서 원본 서버로 통신할 수 있도록 허용하지 않는 경우 아래 명령을 사용하여 MySQL 서버의 IP 주소를 확인할 수 있습니다.

    1. MySQL 명령줄과 같은 도구를 사용하여 Azure Database for MySQL 서버에 로그인합니다.

    2. 다음 쿼리를 실행합니다.

      mysql> SELECT @@global.redirect_server_host;
      

      다음은 몇 가지 샘플 출력입니다.

      +-----------------------------------------------------------+
      | @@global.redirect_server_host                             |
      +-----------------------------------------------------------+
      | e299ae56f000.tr1830.westus1-a.worker.database.windows.net |
       +-----------------------------------------------------------+
      
    3. MySQL 명령줄에서 종료합니다.

    4. IP 주소를 가져오려면 ping 유틸리티에서 다음 명령을 실행합니다.

      ping <output of step 2b>
      

      예시:

      C:\Users\testuser> ping e299ae56f000.tr1830.westus1-a.worker.database.windows.net
      Pinging tr1830.westus1-a.worker.database.windows.net (**11.11.111.111**) 56(84) bytes of data.
      
    5. 이전 단계의 출력된 IP 주소를 3306 포트에 포함하도록 원본 서버의 방화벽 규칙을 구성합니다.

      참고 항목

      이 IP 주소는 유지 관리/배포 작업으로 인해 변경될 수 있습니다. 이 연결 방법은 3306 포트에서 모든 IP 주소를 허용할 여유가 없는 고객만을 위한 것입니다.

  3. 이진 로깅을 설정합니다.

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

    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;
    

    선택 사항 - GTID 기반 복제를 사용하려는 경우 원본 서버에서 GTID가 사용하도록 설정되어 있는지 확인해야 합니다. 원본 MySQL 서버에 대해 다음 명령을 실행하여 gtid_mode가 ON인지 확인할 수 있습니다.

    show variables like 'gtid_mode';
    

    Important

    모든 서버에는 gtid_mode가 기본값인 OFF로 설정되어 있습니다. 특별히 입력 데이터 복제를 설정하기 위해 원본 MySQL 서버에서 GTID를 사용하도록 설정할 필요는 없습니다. 원본 서버에서 GTID가 이미 사용하도록 설정된 경우 필요에 따라 Azure Database for MySQL 단일 서버에서도 GTID 기반 복제를 사용하여 입력 데이터 복제를 설정할 수 있습니다. 원본 서버의 gitd_mode 구성에 관계없이 파일 기반 복제를 사용하여 모든 서버에 대한 입력 데이터 복제를 설정할 수 있습니다.

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

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

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

    SQL 명령

    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'@'%';
    

    MySQL Workbench

    MySQL Workbench에서 복제 역할을 만들려면 관리 패널에서 사용자 및 권한 패널을 연 다음, 계정 추가를 선택합니다.

    사용자 및 권한

    로그인 이름 필드에 사용자 이름을 입력합니다.

    사용자 동기화

    관리 역할 패널을 선택한 다음, 전체 권한 목록에서 복제 슬레이브를 선택합니다. 그런 다음, 적용을 선택하여 복제 역할을 만듭니다.

    복제 슬레이브

  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. 선택 사항 - gtid 기반 복제를 사용하려면 주 서버에서 마지막으로 실행된 트랜잭션의 GTID를 식별해야 합니다. 다음 명령을 사용하여 마스터 서버에서 마지막으로 실행된 트랜잭션의 GTID를 확인할 수 있습니다.

    show global variables like 'gtid_executed';
    
  3. 원본 서버를 읽기/쓰기 모드로 설정합니다.

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

    SET GLOBAL read_only = OFF;
    UNLOCK TABLES;
    
  4. 덤프 파일을 새 서버로 복원합니다.

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

  5. 선택 사항 - Azure Database for MySQL에서 복원된 서버의 GTID를 확인하여 주 서버와 동일한지 확인합니다. 다음 명령을 사용하여 Azure Database for MySQL 복제본 서버에서 제거된 GTID 값의 GTID를 확인할 수 있습니다. GTID 기반 복제가 작동하려면 gtid_purged의 값이 2단계에서 확인한 마스터의 gtid_executed와 동일해야 합니다.

    show global variables like 'gtid_purged';
    
  1. 원본 서버를 설정합니다.

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

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

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

    선택 사항 - gtid 기반 복제를 사용하려면 다음 명령을 사용하여 두 서버를 연결해야 합니다.

    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 서비스에 대한 액세스 허용"을 "켜기"로 설정합니다. 이 설정은 연결 보안 옵션에서 변경할 수 있습니다. 자세한 내용은 포털을 사용하여 방화벽 규칙 관리를 참조하세요.

    예제

    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);
    

    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, '');
    
  2. 필터링을 설정합니다.

    마스터 서버에서 일부 테이블 복제를 건너뛰려면 복제본 서버에서 replicate_wild_ignore_table 서버 매개 변수를 업데이트합니다. 쉼표로 구분된 목록을 사용하여 둘 이상의 테이블 패턴을 제공할 수 있습니다.

    이 매개 변수에 대한 자세한 내용은 MySQL 설명서를 참조하세요.

    매개 변수를 업데이트하려면 Azure Portal 또는 Azure CLI를 사용할 수 있습니다.

  3. 복제를 시작합니다.

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

    CALL mysql.az_replication_start;
    
  4. 복제 상태를 확인합니다.

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

    show slave status;
    

    Slave_IO_RunningSlave_SQL_Running의 상태가 "yes"이고 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;

선택 사항 - gtid 기반 복제를 사용하려면 다음 저장 프로시저를 사용하여 트랜잭션을 건너뜁니다.

call mysql. az_replication_skip_gtid_transaction(‘<transaction_gtid>’)

이 프로시저는 지정된 GTID에 대한 트랜잭션을 건너뛸 수 있습니다. GTID 형식이 올바르지 않거나 GTID 트랜잭션이 이미 실행된 경우 프로시저가 실행되지 않습니다. 트랜잭션의 GTID는 이진 로그를 구문 분석하여 트랜잭션 이벤트를 확인하는 방법으로 확인할 수 있습니다. MySQL은 이진 로그를 구문 분석하고 해당 내용을 텍스트 형식으로 표시하는 mysqlbinlog 유틸리티를 제공합니다. 이 유틸리티는 트랜잭션의 GTID를 식별하는 데 사용할 수 있습니다.

Important

이 절차는 하나의 트랜잭션을 건너뛰는 데만 사용할 수 있으며 gtid 집합을 건너뛰거나 gtid_purged를 설정하는 데 사용할 수 없습니다.

현재 복제 위치 이후의 다음 트랜잭션을 건너뛰려면 다음 명령을 사용하여 아래와 같이 다음 트랜잭션의 GTID를 식별합니다.

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

이진 로그 결과 표시

다음 단계