다음을 통해 공유

Azure Database for MySQL - 유연한 서버의 읽기 복제본

  • 아티클

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

MySQL은 인터넷 규모 웹 및 모바일 애플리케이션을 실행하는 데 널리 사용되는 데이터베이스 엔진 중 하나입니다. 대부분의 고객은 온라인 교육 서비스, 비디오 스트리밍 서비스, 디지털 결제 솔루션, 전자 상거래 플랫폼, 게임 서비스, 뉴스 포털, 정부 및 의료 웹 사이트에서 이 기능을 사용합니다. 이러한 서비스는 웹 또는 모바일 애플리케이션의 트래픽이 늘어남에 따라 서비스를 제공하고 확장해야 합니다.

애플리케이션 쪽에서 애플리케이션은 일반적으로 Java 또는 php로 개발되고 Azure Virtual Machine Scale Sets 또는 Azure App Services에서 실행되거나 AKS(Azure Kubernetes Service)에서 실행되도록 마이그레이션됩니다. 가상 머신 확장 집합, App Service 또는 AKS를 기본 인프라로 사용하면 새 VM을 즉시 프로비저닝하고 애플리케이션의 상태 비저장 구성 요소를 복제하여 요청을 처리함으로써 애플리케이션 크기 조정이 단순화되지만, 데이터베이스는 중앙 집중식 상태 저장 구성 요소로 인해 병목 현상이 발생하는 경우가 많습니다.

읽기 복제본 기능을 사용하면 Azure Database for MySQL 유연한 서버 인스턴스의 데이터를 읽기 전용 서버로 복제할 수 있습니다. 원본 서버에서 최대 10개의 복제본으로 복제할 수 있습니다. 읽복제본은 MySQL 엔진의 네이티브 이진 로그(binlog) 파일의 위치 기반 복제 기술을 사용하여 비동기식으로 업데이트됩니다. binlog 복제에 대한 자세히 알려면 MySQL binlog 복제 개요를 참조합니다.

복제본은 원본 Azure Database for MySQL 유연한 서버 인스턴스와 유사하게 관리하는 새 서버입니다. VCore에 프로비전된 컴퓨팅 및 스토리지에 따라 각 읽기 복제본에 매월 GB 단위로 청구 요금이 부과됩니다. 자세한 내용은 가격 책정을 참조하세요.

참고 항목

읽기 복제본 기능은 범용 또는 중요 비즈니스용 가격 책정 계층의 Azure Database for MySQL 유연한 서버 인스턴스에만 사용할 수 있습니다. 원본 서버가 이러한 가격 책정 계층 중 하나에 포함되어 있는지 확인합니다.

MySQL 복제 기능 및 문제에 대한 자세한 내용은 MySQL 복제 설명서를 참조하세요.

참고 항목

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

읽기 복제본의 일반적인 사용 사례

읽기 복제본 기능은 읽기 작업이 많은 워크로드의 성능과 규모를 향상시키는 데 도움이 됩니다. 읽기 워크로드를 복제본과 격리할 수 있고, 쓰기 워크로드를 원본으로 보낼 수 있습니다.

일반적인 시나리오는 다음과 같습니다.

  • ProxySQL과 같은 경량 연결 프록시를 사용하거나 마이크로서비스 기반 패턴을 사용하여 애플리케이션에서 들어오는 읽기 워크로드를 확장하여 복제본을 읽기 위해 애플리케이션에서 들어오는 읽기 쿼리를 읽기 복제본으로 스케일 아웃하는 경우
  • BI 또는 분석 보고 워크로드에서 읽기 복제본을 보고용 데이터 원본으로 사용할 수 있는 경우
  • 원격 분석 정보가 MySQL 데이터베이스 엔진으로 수집되고, 여러 개의 읽기 복제본이 데이터 보고에 사용되는 IoT 또는 제조 시나리오

복제본은 읽기 전용이기 때문에 원본에 대한 쓰기 용량 부담을 직접적으로 줄이지는 못합니다. 이 기능은 쓰기 작업이 많은 워크로드를 대상으로 하지 않습니다.

읽기 복제본 기능은 MySQL 동기식 복제를 사용합니다. 이 기능은 동기식 복제 시나리오를 위한 것이 아닙니다. 원본과 복제본 간에는 측정 가능한 지연이 발생합니다. 복제본의 데이터는 결과적으로 원본의 데이터와 일치하게 됩니다. 이러한 지연 시간을 수용할 수 있는 워크로드에 이 기능을 사용합니다.

지역 간 복제

원본 서버와 다른 지역에 읽기 복제본을 만들 수 있습니다. 지역 간 복제는 재해 복구 계획 또는 사용자에게 더 가까운 데이터 가져오기 등의 시나리오에 유용할 수 있습니다. Azure Database for MySQL 유연한 서버를 사용하면 Azure Database for MySQL 유연한 서버를 사용할 수 있는 모든 Azure 지원 지역에서 읽기 복제본을 프로비전할 수 있습니다. 이 기능을 사용할 경우 원본 서버는 쌍을 이루는 지역 또는 유니버설 복제본 지역에 복제본이 있을 수 있습니다. 오늘 Azure Database for MySQL 유연한 서버를 사용할 수 있는 Azure 지역 목록을 찾으려면 여기를 참조하세요.

복제본 만들기

원본 서버에 기존 복제본 서버가 없는 경우 원본은 먼저 자체적으로 복제를 위한 준비를 위해 다시 시작됩니다.

복제본 만들기 워크플로를 시작하면 빈 Azure Database for MySQL 유연한 서버 인스턴스가 만들어집니다. 새 서버는 원본 서버에 있던 데이터로 채워집니다. 생성 시간은 원본의 데이터 양과 마지막 매주 전체 백업 이후의 시간에 따라 달라집니다. 시간은 몇 분에서 몇 시간까지 걸릴 수 있습니다.

참고 항목

읽기 복제본은 원본과 동일한 서버 구성으로 만들어집니다. 복제본이 생성된 후에 복제본 서버 구성을 변경할 수 있습니다. 복제본 서버는 항상 원본 서버와 동일한 리소스 그룹 및 동일한 구독에 생성됩니다. 다른 리소스 그룹 또는 다른 구독에 대한 복제본 서버를 만들려는 경우 복제본 서버를 만든 후 이동할 수 있습니다. 복제본이 원본을 따라갈 수 있도록 복제본 서버의 구성을 원본과 동등하거나 더 큰 값으로 설정하기를 권합니다.

Azure Portal에서 읽기 복제본을 만드는 방법을 알아봅니다.

복제본에 연결

복제본은 생성될 때 원본 서버의 연결 방법을 상속합니다. 복제본의 연결 방법은 변경할 수 없습니다. 예를 들어 원본 서버에 프라이빗 액세스(VNet 통합) 권한이 있는 경우 복제본에 퍼블릭 액세스(허용된 IP 주소) 권한이 있을 수 없습니다.

복제본은 원본 서버에서 해당 관리자 계정을 상속합니다. 원본 서버의 모든 사용자 계정은 읽기 복제본으로 복제됩니다. 원본 서버에서 사용 가능한 사용자 계정을 사용해야만 읽기 복제본에 연결할 수 있습니다.

일반 Azure Database for MySQL 유연한 서버 인스턴스에서와 마찬가지로 호스트 이름 및 유효한 사용자 계정을 사용하여 복제본에 연결할 수 있습니다. 관리 사용자 이름이 myadmin인 myreplica라는 서버의 경우 mysql CLI를 사용하여 복제본에 연결할 수 있습니다.

mysql -h myreplica.mysql.database.azure.com -u myadmin -p

프롬프트가 표시되면 사용자 계정의 암호를 입력합니다.

복제 모니터링

Azure Database for MySQL 유연한 서버는 Azure Monitor에 복제 지연 시간(초) 메트릭을 제공합니다. 이 메트릭은 복제본에만 사용할 수 있습니다. 이 메트릭은 seconds_behind_masterMySQL에서 사용할 수 있는 메트릭SHOW SLAVE STATUS 명령을 사용하여 계산됩니다. 복제 지연 시간이 워크로드에 적합하지 않은 값에 도달하면 알리도록 경고를 설정합니다.

복제 지연 시간이 늘어나면 복제 대기 시간 문제 해결을 참조하여 문제를 해결하고 가능한 원인을 파악하세요.

Important

읽기 복제본은 MySQL의 'SHOW SLAVE STATUS'/'SHOW REPLICA STATUS' 명령에서 사용할 수 있는 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' 메트릭을 더 이상 사용하지 않는 스토리지 기반 복제 기술을 사용합니다. 값은 항상 "아니요"로 표시되며 복제 상태를 나타내지 않습니다. 올바른 복제 상태를 확인하려면 모니터링 블레이드에서 복제 메트릭 - 복제본 IO 상태 및 복제본 SQL 상태를 참조하세요.

복제 중지

원본 및 복제본 간의 복제를 중지할 수 있습니다. 원본 서버와 읽기 복제본 간의 복제가 중지되면 복제본이 독립 실행형 서버가 됩니다. 독립 실행형 서버의 데이터는 복제 중지 명령이 시작될 때 복제본에서 사용할 수 있던 데이터입니다. 독립 실행형 서버는 원본 서버를 따라잡지 않습니다.

복제본에 대한 복제를 중지하도록 선택하면 이전 원본 및 기타 복제본에 대한 모든 링크가 끊깁니다. 원본과 해당 복제본 사이에는 자동화된 장애 조치(failover)가 없습니다.

Important

독립 실행형 서버를 다시 복제본으로 만들 수 없습니다. 읽기 복제본에서 복제를 중지하기 전에 복제본에 필요한 모든 데이터가 있는지 확인하십시오.

복제본에 대한 복제를 중지하는 방법을 알아봅니다.

장애 조치(Failover)

원본과 해당 복제본 서버 사이에는 자동화된 장애 조치(failover)가 없습니다.

읽기 복제본은 읽기 집약적 워크로드의 크기 조정을 위한 것이며, 서버의 고가용성 요구 사항을 충족하도록 설계되지 않았습니다. 수동 장애 조치(failover)를 수행하는 방법은 읽기 복제본에서 복제를 중지하여 읽기 쓰기 모드에서 온라인 상태로 전환하는 것입니다.

복제는 비동기식이므로 원본과 복제본 사이에 지연이 발생합니다. 지연 시간은 원본 서버에서 실행되는 워크로드의 크기와 데이터 센터 간에 발생하는 대기 시간 등 여러 가지 요인에 영향을 받을 수 있습니다. 대부분의 경우 복제본 지연 시간 범위는 몇 초에서 몇 분 사이입니다. 각 복제본에 사용 가능한 복제본 지연 시간 메트릭을 사용하여 실제 복제 지연 시간을 추적할 수 있습니다. 이 메트릭은 마지막으로 재생된 트랜잭션 이후의 시간을 보여 줍니다. 일정 기간 동안 복제본 지연 시간을 관찰하여 평균 지연 시간을 확인하는 것이 좋습니다. 예상 범위를 벗어나면 조치를 취할 수 있도록 복제본 지연 시간에 대한 경고를 설정할 수 있습니다.

팁

복제본으로 장애 조치(failover)하는 경우 복제본이 원본에서 분리될 때 발생하는 지연 시간이 손실된 데이터의 양을 나타냅니다.

복제본으로 장애 조치(failover)하기로 결정했으면 다음을 수행합니다.

  1. 복제본에 대한 복제를 중지합니다.
    이 단계는 복제본 서버에서 쓰기를 허용하도록 하는 데 필요합니다. 이 프로세스의 일부로 복제본 서버가 원본에서 분리됩니다. 복제 중지를 시작한 후 백 엔드 프로세스를 완료하는 데 일반적으로 약 2분이 소요됩니다. 이 작업의 의미를 이해하려면 이 문서의 복제 중지 섹션을 참조하세요.

  2. 애플리케이션이 (이전) 복제본을 가리키도록 합니다.
    각 서버에는 고유한 연결 문자열이 있습니다. 원본 대신 (이전) 복제본을 가리키도록 애플리케이션을 업데이트합니다.

애플리케이션이 읽기 및 쓰기를 성공적으로 처리하면 장애 조치(failover)를 완료한 것입니다. 응용 프로그램의 가동 중지 시간은 문제를 감지하고 위의 1단계와 2단계를 완료하는 시기에 따라 달라집니다.

GTID(전역 트랜잭션 식별자)

GTID(전역 트랜잭션 식별자)는 원본 서버에서 커밋된 각 트랜잭션을 사용하여 만든 고유 식별자이며 Azure Database for MySQL 유연한 서버에서 기본적으로 OFF입니다. GTID는 버전 5.7 및 8.0에서 지원됩니다. GTID 및 GTID가 복제에 사용되는 방법에 대한 자세한 내용은 MySQL의 GTID를 사용하는 복제 설명서를 참조하세요.

GTID를 구성하는 데 사용할 수 있는 서버 매개 변수는 다음과 같습니다.

서버 매개 변수 설명 기본값 값
gtid_mode GTID가 트랜잭션을 식별하는 데 사용되는지 여부를 나타냅니다. 모드 간 변경 작업은 오름차순으로 한 번에 한 단계씩만 진행될 수 있습니다. (예: OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF* OFF: 새 트랜잭션과 복제 트랜잭션은 모두 익명이어야 합니다.
OFF_PERMISSIVE: 새 트랜잭션은 익명입니다. 복제된 트랜잭션은 익명 또는 GTID 트랜잭션이 될 수 있습니다.
ON_PERMISSIVE: 새 트랜잭션은 GTID 트랜잭션입니다. 복제된 트랜잭션은 익명 또는 GTID 트랜잭션이 될 수 있습니다.
ON: 신규 및 복제된 트랜잭션은 모두 GTID 트랜잭션이어야 합니다.
enforce_gtid_consistency 트랜잭션 측면에서 안전하게 기록될 수 있는 문만 실행하도록 허용하여 GTID 일관성을 적용합니다. GTID 복제를 사용하도록 설정하려면 먼저 이 값을 ON으로 설정해야 합니다. OFF* OFF: 모든 트랜잭션은 GTID 일관성을 위반할 수 있습니다.
ON: 어떠한 트랜잭션도 GTID 일관성을 위반해서는 안 됩니다.
WARN: 모든 트랜잭션은 GTID 일관성을 위반할 수 있지만 경고가 생성됩니다.

고가용성 기능을 사용하도록 설정된 Azure Database for MySQL 유연한 서버 인스턴스의 경우 기본값은 .로 ON설정됩니다.

참고 항목

  • GTID를 사용하도록 설정한 후에는 다시 해제할 수 없습니다. GTID를 해제해야 하는 경우 고객 지원팀에 문의하세요.
  • 모드의 오름차순으로 한 번에 한 단계씩만 GTID의 값을 변경할 수 있습니다. 예를 들어 gtid_mode가 현재 OFF_PERMISSIVE로 설정되어 있는 경우 ON_PERMISSIVE로 변경할 수 있지만 ON으로는 변경할 수 없습니다.
  • 복제를 일관되게 유지하기 위해 마스터/복제본 서버에 대해 업데이트할 수 없습니다.
  • gtid_mode=ON을 설정하기 전에 enforce_gtid_consistency를 ON으로 설정하는 것이 좋습니다.

GTID를 사용하도록 설정하고 일관성 동작을 구성하려면 Azure Portal 또는 Azure CLI을 사용하여 gtid_mode 및 enforce_gtid_consistency 서버 매개 변수를 업데이트합니다.

원본 서버에서 GTID를 사용하는 경우(gtid_mode = ON) 새로 만든 복제본도 GTID를 사용하도록 설정하고 GTID 복제를 사용합니다. GTID를 사용하도록 설정하고 마스터 또는 복제본 서버를 만든 다음에는 복제를 일관되게 유지하기 위해 gtid_mode를 변경할 수 없습니다.

고려 사항 및 제한 사항

시나리오 제한 사항/고려 사항
버스트 가능 가격 책정 계층의 서버 복제본 지원되지 않음
가격 책정 복제 서버의 실행 비용은 복제본 서버가 실행되는 지역을 기반으로 책정됩니다.
원본 서버 다시 시작 기존 복제본이 없는 원본에 대한 복제본을 만들 때는 원본이 먼저 다시 시작되어 자체적으로 복제를 준비합니다. 이를 고려하여 사용량이 적은 기간 동안 이러한 작업을 수행합니다.
새 복제본 읽기 복제본은 새 Azure Database for MySQL 유연한 서버 인스턴스로 만들어집니다. 기존 서버를 복제본으로 만들 수 없습니다. 다른 읽기 복제본의 복제본은 만들 수 없습니다.
복제본 구성 복제본은 원본과 같은 서버 구성을 사용하여 생성됩니다. 복제본을 만든 후에는 원본 서버와는 별도로 컴퓨팅 생성, vCore, 스토리지 및 백업 보존 기간 등의 일부 설정을 변경할 수 있습니다. 컴퓨팅 계층을 독립적으로 변경할 수도 있습니다.

중요 - 원본 서버 구성을 새 값으로 업데이트하기 전에 복제본의 구성을 같거나 더 큰 값으로 업데이트합니다. 이렇게 하면 복제본이 원본에 대한 변경 내용을 유지할 수 있습니다.
복제본을 만들 때 연결 방법 및 매개 변수 설정은 원본 서버에서 복제본으로 상속됩니다. 나중에 복제본의 규칙은 독립적입니다.
중지된 복제본 원본 서버와 읽기 복제본 간의 복제를 중지하면 중지된 복제본은 읽기와 쓰기를 모두 허용하는 독립 실행형 서버가 됩니다. 독립 실행형 서버를 다시 복제본으로 만들 수 없습니다.
삭제된 원본 및 독립 실행형 서버 원본 서버가 삭제되면 모든 읽기 복제본에 대한 복제가 중지됩니다. 이러한 복제본은 자동으로 독립 실행형 서버가 되며 읽기와 쓰기를 모두 허용할 수 있습니다. 원본 서버 자체는 삭제됩니다.
사용자 계정 원본 서버의 사용자는 읽기 복제본으로 복제됩니다. 원본 서버에서 사용 가능한 사용자 계정을 사용하여 읽기 복제본에만 연결할 수 있습니다.
서버 매개 변수 데이터가 동기화되지 않고 데이터가 손실 또는 손상될 가능성으로부터 데이터를 보호하기 위해 읽기 복제본을 사용하는 경우 일부 서버 매개 변수는 업데이트할 수 없도록 잠깁니다.
다음 서버 매개 변수는 원본 서버와 복제 서버에서 모두 잠깁니다.
- innodb_file_per_table
- log_bin_trust_function_creators
event_scheduler 매개 변수가 복제본 서버에서 잠겨 있습니다.
원본 서버에서 위의 매개 변수 중 하나를 업데이트하려면 복제본 서버를 삭제하고, 원본의 매개 변수 값을 업데이트하고, 복제본을 다시 만듭니다.
세션 수준 매개 변수 읽기 복제본에 'foreign_keys_checks'와 같은 세션 수준 매개 변수를 구성할 때 읽기 복제본에 설정되는 매개 변수 값이 원본 서버의 값과 일치하는지 확인합니다.
원본 서버의 기존 테이블에 AUTO_INCREMENT 기본 키 열을 추가합니다. AUTO_INCREMENT 읽기 후 복제본 만들기를 사용하여 테이블을 변경하면 복제가 중단되므로 피합니다. 그러나 복제본 서버를 만든 후에 자동 증가 열 게시물을 추가하려고 할 수 있습니다. 다음과 같은 두 가지 접근 방식을 권장합니다.
- 수정하려는 테이블의 스키마가 동일한 새 테이블을 만듭니다. 새 테이블에서 AUTO_INCREMENT를 사용하여 열을 변경한 다음, 원래 테이블에서 데이터를 복원합니다. 이전 테이블을 삭제하고 원본에서 이름을 바꿉니다. 복제본 서버는 삭제할 필요는 없지만 백업 테이블을 만드는 데 큰 삽입 비용이 필요할 수 있습니다.
- 다른 더 빠른 방법은 모든 자동 증가 열을 추가한 후 복제본을 다시 만드는 것입니다.
기타 복제본의 복제본 만들기는 지원되지 않습니다.
- 메모리 내 테이블이 있으면 복제본이 동기화되지 않을 수 있기 때문입니다. 이것은 MySQL 복제 기술의 제한 사항입니다. 자세한 내용은 MySQL 참조 문서를 참조하세요.
- 원본 서버 테이블에 기본 키가 있는지 확인합니다. 기본 키가 없는 경우 원본 및 복제본 간의 복제 대기 시간이 발생할 수 있습니다.
- MySQL 설명서에서 MySQL 복제 제한 사항의 전체 목록을 검토하세요.

다음 단계