MySQL은 인터넷 규모 웹 및 모바일 애플리케이션을 실행하는 데 널리 사용되는 데이터베이스 엔진 중 하나입니다. 많은 고객이 온라인 교육, 비디오 스트리밍, 디지털 결제, 전자 상거래, 게임, 뉴스 포털, 정부 및 의료 웹 사이트를 비롯한 다양한 애플리케이션에 Azure Database for MySQL을 사용합니다. 이러한 서비스는 웹 또는 모바일 애플리케이션의 트래픽이 증가함에 따라 서비스를 제공하고 확장할 수 있어야 합니다.
애플리케이션 쪽에서 개발자는 일반적으로 Java 또는 PHP를 사용합니다. Azure Virtual Machine Scale Sets, Azure App Services에서 실행되도록 애플리케이션을 마이그레이션하거나 AKS(Azure Kubernetes Service)에서 실행되도록 컨테이너화합니다. Virtual Machine Scale Set, 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 또는 분석 보고 워크로드에 대한 데이터 원본으로 읽기 복제본 사용
- IoT 또는 제조 시나리오에서 데이터를 보고하기 위해 여러 읽기 복제본을 사용하는 동안 원격 분석 정보를 MySQL 데이터베이스 엔진에 수집
복제본은 읽기 전용이기 때문에 원본에 대한 쓰기 용량 부담을 직접적으로 줄이지는 못합니다. 이 기능은 쓰기 작업이 많은 워크로드를 대상으로 하지 않습니다.
읽기 복제본 기능은 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에 복제 지연 시간(초) 메트릭을 제공합니다. 이 메트릭은 복제본에만 사용할 수 있습니다. Azure Monitor는 MySQL 명령의 메트릭을 seconds_behind_master 사용하여 이 메트릭을 SHOW SLAVE STATUS 계산합니다. 복제 지연이 워크로드에 대해 허용할 수 없는 임계값을 초과하는 경우 알리도록 경고를 설정합니다.
복제 지연 시간이 늘어나면 복제 대기 시간 문제 해결을 참조하여 문제를 해결하고 가능한 원인을 파악하세요.
중요합니다
읽기 복제본은 MySQL의 명령에서 사용할 수 있는 메트릭을 SLAVE_IO_RUNNING/REPLICA_IO_RUNNING 더 이상 사용하지 않는 스토리지 기반 복제 기술을 사용합니다.SHOW SLAVESTATUS'/'SHOWREPLICA STATUS 이 값은 항상 "아니요"로 표시되며 복제 상태를 나타내지 않습니다. 복제의 올바른 상태를 확인하려면 복제 메트릭 ( 모니터링 페이지 아래 의 복제본 IO 상태 및 복제본 SQL 상태 )을 참조하세요.
복제 중지
원본 서버와 복제본 서버 간의 복제를 중지할 수 있습니다. 원본 서버와 읽기 복제본 간의 복제를 중지하면 복제본 서버가 독립 실행형 서버가 됩니다. 독립 실행형 서버에는 복제 중지 명령을 시작할 때 복제본 서버에서 사용할 수 있었던 데이터가 포함됩니다. 독립 실행형 서버는 원본 서버에서 누락된 데이터를 동기화하지 않습니다.
복제본 서버에 대한 복제를 중지하면 복제본 서버는 이전 원본 서버 및 다른 복제본 서버에 대한 모든 링크를 잃게 됩니다. 원본 서버와 해당 복제본 서버 간에는 자동화된 장애 조치(failover)가 없습니다.
중요합니다
독립 실행형 서버를 복제본 서버로 다시 변환할 수 없습니다. 읽기 복제본에서 복제를 중지하기 전에 복제본 서버에 필요한 모든 데이터가 있는지 확인합니다.
자세한 내용은 복제본에 대한 복제 중지를 참조하세요.
장애 조치(Failover)
원본과 해당 복제본 서버 사이에는 자동화된 장애 조치(failover)가 없습니다.
읽기 복제본은 읽기 집약적 워크로드의 크기를 조정하며 서버에 고가용성을 제공하지 않습니다. 읽기-쓰기 모드에서 온라인 상태로 전환하여 읽기 복제본에서 복제를 중지하여 수동 장애 조치(failover)를 수행합니다.
복제는 비동기이므로 원본과 복제본 사이에 지연이 있습니다. 원본 서버의 워크로드 및 데이터 센터 간의 대기 시간과 같은 많은 요인은 지연 양에 영향을 줍니다. 대부분의 경우 복제본 지연 범위는 몇 초에서 몇 분 사이입니다. 각 복제본에 사용할 수 있는 복제본 지연 시간 메트릭을 사용하여 실제 복제 지연을 추적할 수 있습니다. 이 메트릭은 마지막으로 재생된 트랜잭션 이후의 시간을 보여 줍니다. 시간 경과에 따른 복제본 지연 시간을 관찰하여 평균 지연 시간을 식별하는 것이 좋습니다. 예상 범위를 벗어나면 조치를 취할 수 있도록 복제본 지연 시간에 대한 경고를 설정할 수 있습니다.
팁
복제본으로 장애 조치(failover)하는 경우 원본에서 복제본의 연결을 해제할 때의 지연 시간은 손실된 데이터의 양을 나타냅니다.
복제본으로 장애 조치(failover)하기로 결정한 후:
복제본에 대한 복제를 중지합니다.
복제 서버가 쓰기를 수락할 수 있도록 복제를 중지해야 합니다. 이 프로세스는 원본에서 복제본 서버를 연결 해제합니다. 복제 중지를 시작한 후 백 엔드 프로세스를 완료하는 데 일반적으로 약 2분이 걸립니다. 이 작업의 의미를 이해하려면 이 문서의 복제 중지 섹션을 참조하세요.
애플리케이션이 (이전) 복제본을 가리키도록 합니다.
각 서버에는 고유한 연결 문자열이 있습니다. 원본 대신 (이전) 복제본을 가리키도록 애플리케이션을 업데이트합니다.
애플리케이션이 읽기 및 쓰기를 성공적으로 처리하면 장애 조치(failover)를 완료합니다. 애플리케이션 환경의 가동 중지 시간은 문제를 감지하고 1단계와 2단계를 완료하는 시기에 따라 달라집니다.
GTID(전역 트랜잭션 식별자)
GTID(전역 트랜잭션 식별자)는 원본 서버가 커밋된 각 트랜잭션을 사용하여 만드는 고유 식별자입니다. Azure Database for MySQL 유연한 서버는 기본적으로 GTID를 해제합니다. 버전 5.7 및 8.0은 GTID를 지원합니다. GTID 및 복제에서 사용하는 방법에 대한 자세한 내용은 GTID 설명서를 사용하여 MySQL 의 복제를 참조하세요.
다음 서버 매개 변수를 사용하여 GTID를 구성합니다.
| 서버 매개 변수 | 설명 | 기본값 | 값 |
|---|---|---|---|
gtid_mode |
GTID가 트랜잭션을 식별하는 데 사용되는지 여부를 나타냅니다. 모드 간 변경은 오름차순으로 한 번에 한 단계만 수행할 수 있습니다(예: OFF -OFF_PERMISSIVE> -ON>ON_PERMISSIVE>) |
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 변경할 수 있지만 변경할 ON_PERMISSIVE 수는 없습니다ON.OFF_PERMISSIVE
복제를 일관성 있게 유지하기 위해 주 서버 또는 복제본 서버에 대해 복제를 업데이트할 수 없습니다.
로 설정하기 전에 로 설정합니다 enforce_gtid_consistencygtid_modeON.ON
GTID를 사용하도록 설정하고 일관성 동작을 구성하려면 및 enforce_gtid_consistency 서버 매개 변수를 gtid_mode 업데이트합니다.
Azure Portal을 사용하여 Azure Database for MySQL - 유연한 서버에서 서버 매개 변수 구성을 사용하거나 Azure CLI를 사용하여 Azure Database for MySQL - 유연한 서버에서 서버 매개 변수를 구성합니다.
원본 서버에서 GTID()gtid_mode = ON를 사용하도록 설정하는 경우 새로 만든 복제본도 GTID를 사용하도록 설정하고 GTID 복제를 사용합니다. 복제 일관성을 보장하기 위해 GTID를 사용하도록 설정된 주 또는 복제본 서버를 만든 후에는 변경할 gtid_mode 수 없습니다.
고려 사항 및 제한 사항
| 시나리오 | 제한 사항/고려 사항 |
|---|---|
| 버스트 가능 가격 책정 계층의 서버 복제본 | 지원되지 않음 |
| 가격 책정 | 복제본 서버 실행 비용은 복제본 서버가 실행되는 지역에 따라 달라집니다. |
| 원본 서버 가동 중지 시간/다시 시작 | 읽기 복제본을 만들 때 다시 시작 또는 가동 중지 시간이 필요하지 않습니다. 이 작업은 온라인 작업입니다. |
| 새 복제본 | 읽기 복제본을 새 Azure Database for MySQL 유연한 서버 인스턴스로 만듭니다. 기존 서버를 복제본으로 만들 수 없습니다. 다른 읽기 복제본의 복제본은 만들 수 없습니다. |
| 복제본 구성 | 원본과 동일한 서버 구성을 사용하여 복제본을 만듭니다. 복제본을 만든 후에는 컴퓨팅 생성, vCore, 스토리지 및 백업 보존 기간과 같은 여러 설정을 원본 서버와 독립적으로 변경할 수 있습니다. 컴퓨팅 계층을 독립적으로 변경할 수도 있습니다. 중요 - 원본 서버 구성을 새 값으로 업데이트하기 전에 복제본 구성을 같거나 더 큰 값으로 업데이트합니다. 이렇게 하면 복제본이 원본에 대한 변경 내용을 유지할 수 있습니다. 연결 방법 및 매개 변수 설정은 복제본을 만들 때 원본 서버에서 복제본으로 상속됩니다. 나중에 복제본의 규칙은 독립적입니다. |
| 중지된 복제본 | 원본 서버와 읽기 복제본 간의 복제를 중지하면 중지된 복제본은 읽기와 쓰기를 모두 허용하는 독립 실행형 서버가 됩니다. 독립 실행형 서버를 복제본으로 다시 만들 수 없습니다. |
| 삭제된 원본 서버 | 원본 서버를 삭제하면 모든 읽기 복제본에 대한 복제가 중지됩니다. 이러한 복제본은 자동으로 독립 실행형 서버가 되며 읽기와 쓰기를 모두 허용할 수 있습니다. 원본 서버 자체는 삭제됩니다. |
| 사용자 계정 | 원본 서버의 사용자는 읽기 복제본으로 복제됩니다. 원본 서버에서 사용할 수 있는 사용자 계정을 사용하여 읽기 복제본에만 연결할 수 있습니다. |
| 서버 매개 변수 | 데이터가 동기화되지 않고 데이터가 손실 또는 손상될 가능성으로부터 데이터를 보호하기 위해 읽기 복제본을 사용하는 경우 일부 서버 매개 변수는 업데이트할 수 없도록 잠깁니다. 다음 서버 매개 변수는 원본 서버와 복제 서버에서 모두 잠깁니다. - innodb_file_per_table- log_bin_trust_function_creatorsevent_scheduler 매개 변수가 복제본 서버에서 잠겨 있습니다.원본 서버에서 이전 매개 변수 중 하나를 업데이트하려면 복제본 서버를 삭제하고, 원본의 매개 변수 값을 업데이트하고, 복제본을 다시 만듭니다. |
| 세션 수준 매개 변수 | 읽기 복제본에서 'foreign_keys_checks'과 같은 세션 수준 매개 변수를 구성할 때 읽기 복제본에서 설정하는 매개 변수 값이 원본 서버의 매개 변수 값과 일치하는지 확인합니다. |
| 원본 서버의 기존 테이블에 AUTO_INCREMENT 기본 키 열 추가 | 이 작업은 복제를 중단하므로 읽기 복제본을 만든 후에 테이블을 AUTO_INCREMENT 변경하지 않는 것이 좋습니다. 복제본 서버를 만든 후 자동 증가 열을 추가하려면 다음 방법을 고려합니다.- 수정하려는 테이블과 동일한 스키마를 사용하여 새 테이블을 만듭니다. 새 테이블에서 열을 AUTO_INCREMENT변경한 다음 원래 테이블에서 데이터를 복원합니다. 이전 테이블을 삭제하고 원본에서 이름을 바꿉니다. 이 방법은 복제본 서버를 삭제할 필요가 없지만 백업 테이블을 만드는 데 큰 삽입 비용이 발생할 수 있습니다.- 모든 자동 증가 열을 추가한 후 복제본을 다시 만듭니다. |
| 기타 | 복제본의 복제본 만들기는 지원되지 않습니다. - 메모리 내 테이블로 인해 복제본이 동기화될 수 있습니다. 이 제한은 MySQL 복제 기술 때문입니다. 자세한 내용은 MySQL 참조 설명서를 참조하세요. - 원본 서버 테이블에 기본 키가 있는지 확인합니다. 기본 키가 부족하면 원본과 복제본 간의 복제 대기 시간이 발생할 수 있습니다. - MySQL 설명서에서 MySQL 복제 제한 사항의 전체 목록을 검토합니다. |