Azure Database for MySQL 유연한 서버를 사용하면 자동 장애 조치(failover)로 고가용성을 구성할 수 있습니다. 이 솔루션은 오류가 커밋된 데이터를 손실하지 않도록 하고 데이터베이스가 소프트웨어 아키텍처에서 단일 실패 지점이 되지 않도록 보장합니다. 고가용성을 구성하는 경우 유연한 서버는 대기 복제본을 자동으로 프로비전하고 관리합니다. 주 복제본과 보조 복제본 모두에 대해 프로비전된 컴퓨팅 및 스토리지 비용을 지불합니다. 다음과 같은 두 가지 고가용성 아키텍처 모델을 사용할 수 있습니다.
영역 중복 고가용성. 이 옵션은 여러 가용성 영역에서 인프라의 완전한 격리 및 중복도를 제공합니다. 최고 수준의 가용성을 제공하지만 영역 간에 애플리케이션 중복도를 구성해야 합니다. 가용성 영역의 인프라 오류로부터 보호하려는 경우와 가용성 영역 간의 대기 시간이 허용되는 경우 영역 중복 HA를 선택합니다. 서버를 만들 때만 영역 중복 HA를 사용하도록 설정할 수 있습니다. 영역 중복 HA는 지역에서 여러 가용성 영역을 지원하고 영역 중복 프리미엄 파일 공유를 사용할 수 있는 Azure 지역의 하위 집합에서 사용할 수 있습니다.
로컬 중복 고가용성. 이 옵션은 기본 서버와 대기 서버가 동일한 가용성 영역에 있으므로 네트워크 대기 시간이 짧은 인프라 중복도를 제공합니다. 영역 간에 애플리케이션 중복도를 구성하지 않아도 고가용성을 제공합니다. 네트워크 대기 시간이 가장 낮은 단일 가용성 영역 내에서 가장 높은 수준의 가용성을 달성하려는 경우 로컬 중복 HA를 선택합니다. 로컬 중복 HA는 Azure Database for MySQL 유연한 서버를 사용할 수 있는 모든 Azure 지역에서 사용할 수 있습니다.
영역 중복 HA(고가용성) 아키텍처
영역 중복 고가용성이 있는 서버를 배포하는 경우 Azure는 다음 두 개의 서버를 만듭니다.
- 하나의 가용성 영역에 있는 주 서버
- 동일한 Azure 지역의 다른 가용성 영역에 있는 대기 복제본 서버입니다. 대기 복제본 서버는 컴퓨팅 계층, 컴퓨팅 크기, 스토리지 크기 및 네트워크 구성을 포함하여 주 서버와 구성이 동일합니다.
주 서버와 대기 복제본 모두에 대한 가용성 영역을 선택할 수 있습니다. 대기 데이터베이스 서버와 대기 애플리케이션을 동일한 영역에 배치하면 대기 시간이 줄어듭니다. 또한 재해 복구 상황 및 "영역 축소" 시나리오에 대비하는 데 도움이 됩니다.
데이터 및 로그 파일은 ZRS(영역 중복 스토리지)에서 호스트됩니다. 대기 서버는 스토리지 수준 복제가 보호하는 주 서버의 스토리지 계정에서 로그 파일을 지속적으로 읽고 재생합니다.
장애 조치(failover)가 발생하면
- 대기 복제본이 활성화됩니다.
- 주 서버의 이진 로그 파일은 주 서버에서 마지막으로 커밋된 트랜잭션으로 온라인 상태가 되도록 대기 서버에 계속 적용됩니다.
주 서버를 사용할 수 없는 경우에도 ZRS의 로그에 액세스할 수 있습니다. 이 가용성은 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 대기 복제본이 활성화되고 이진 로그가 적용되면 현재 대기 복제본 서버가 주 서버의 역할을 맡습니다. 클라이언트가 다시 연결될 때 클라이언트 연결이 새로운 주 서버로 전달되도록 DNS가 업데이트됩니다. 장애 조치(failover)는 클라이언트 애플리케이션에서 완전히 투명하며 사용자의 작업이 필요하지 않습니다. 그런 다음 HA 솔루션은 가능한 경우 이전 주 서버를 다시 가져와 대기 서버로 배치합니다.
데이터베이스 서버 이름을 사용하여 애플리케이션을 주 서버에 연결합니다. 솔루션은 직접 액세스를 위해 대기 복제본 정보를 노출하지 않습니다. 로그 파일이 주 서버의 ZRS에서 플러시되면 커밋과 쓰기가 승인됩니다. ZRS 스토리지에 사용되는 동기화 복제 기술 덕분에 애플리케이션 쓰기 및 커밋에 대해 5~10% 늘어난 대기 시간을 예측할 수 있습니다.
스냅샷과 로그 백업 모두, 자동 백업은 주 데이터베이스 서버의 영역 중복 스토리지에서 수행됩니다.
로컬 중복 고가용성(HA) 아키텍처
로컬 중복 HA를 사용하여 서버를 배포하는 경우 동일한 영역에 두 개의 서버를 만듭니다.
- 주 서버
- 주 서버와 구성(컴퓨팅 계층, 컴퓨팅 크기, 스토리지 크기 및 네트워크 구성)이 동일한 대기 복제본 서버
대기 서버는 별도의 가상 머신(컴퓨팅)을 사용하여 인프라 중복도를 제공합니다. 이러한 중복도는 공동 배치로 인한 애플리케이션과 데이터베이스 서버 간의 장애 조치(failover) 시간 및 네트워크 대기 시간을 줄여 줍니다.
데이터 및 로그 파일은 LRS(로컬 중복 스토리지)에서 호스트됩니다. 대기 서버는 스토리지 수준 복제로 보호되는 주 서버의 스토리지 계정에서 로그 파일을 지속적으로 읽고 재생합니다.
장애 조치(failover)가 발생하면
- 대기 복제본이 활성화됩니다.
- 주 서버의 이진 로그 파일은 주 서버에서 마지막으로 커밋된 트랜잭션으로 온라인 상태가 되도록 대기 서버에 계속 적용됩니다.
기본 서버를 사용할 수 없는 경우에도 LRS의 로그에 액세스할 수 있습니다. 이 가용성은 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 대기 복제본이 활성화되고 이진 로그가 적용되면 현재 대기 복제본이 주 서버의 역할을 합니다. DNS는 클라이언트가 다시 연결될 때 새로운 주 서버로 연결을 리디렉션하도록 업데이트됩니다. 장애 조치(failover)는 클라이언트 애플리케이션에서 완전히 투명하며 사용자의 작업이 필요하지 않습니다. 그런 다음 HA 솔루션은 가능한 경우 이전 주 서버를 다시 가져와 대기 서버로 배치합니다.
데이터베이스 서버 이름은 애플리케이션을 주 서버에 연결합니다. 대기 복제본 정보는 직접 액세스에 노출되지 않습니다. 주 서버의 LRS에서 로그 파일이 플러시되면 커밋과 쓰기가 승인됩니다. 주 복제본과 대기 복제본이 동일한 영역에 있기 때문에 복제 지연 시간이 줄어들고 애플리케이션 서버와 데이터베이스 서버 간의 대기 시간이 줄어듭니다. 로컬 중복 설정은 특정 가용성 영역에 대한 종속 인프라가 다운된 경우 고가용성을 제공하지 않습니다. 모든 종속 서비스가 해당 가용성 영역에 대해 다시 온라인 상태가 될 때까지 가동 중지 시간이 발생합니다.
스냅샷과 로그 백업 모두, 자동 백업은 주 데이터베이스 서버의 로컬 중복 스토리지에서 수행됩니다.
참고
영역 중복 및 로컬 중복 HA의 경우:
- 오류가 발생하는 경우 대기 복제본이 주 스토리지의 역할을 맡는 데 필요한 시간은 주 스토리지 계정에서 대기 스토리지로 이진 로그를 재생하는 데 걸리는 시간에 따라 달라집니다. 장애 조치(failover) 시간을 줄이려면 모든 테이블에서 기본 키를 사용합니다. 장애 조치(failover) 시간은 일반적으로 60초에서 120초 사이입니다.
- 대기 서버는 읽기 또는 쓰기 작업에 사용할 수 없습니다. 또한 빠른 장애 조치(failover)를 사용할 수 있는 수동 대기 상태입니다.
- 항상 FQDN(정규화된 도메인 이름)을 사용하여 주 서버에 연결합니다. IP 주소를 사용하여 연결하지 않습니다. 장애 조치(failover)가 수행되는 경우 기본 및 대기 서버 역할이 전환된 후 DNS A 레코드가 변경될 수 있습니다. 이러한 변경으로 인해 연결 문자열에 IP 주소가 사용되는 경우 애플리케이션이 새 주 서버에 연결할 수 없습니다.
장애 조치(failover) 프로세스
Azure Database for MySQL의 장애 조치(failover) 프로세스 중에 시스템은 자동으로 주 서버에서 대기 복제본으로 전환됩니다. 이러한 전환은 연속성을 보장하고 가동 중지 시간을 최소화합니다. 시스템에서 오류를 감지하면 대기 복제본을 새 주 서버로 승격합니다. 시스템은 원래 주 서버의 이진 로그 파일을 대기 복제본에 적용합니다. 이 프로세스는 대기 복제본을 마지막으로 커밋된 트랜잭션과 동기화하고 데이터 손실을 방지합니다. 이러한 원활한 전환은 데이터베이스 서비스의 고가용성 및 안정성을 유지하는 데 도움이 됩니다.
참고
DNS 캐싱에 대한 장애 조치(failover) 시간 종속성을 줄이기 위해 2025년 10월부터 공용 액세스 또는 프라이빗 링크로 만든 모든 새 HA 서버는 각 HA 서버에 대한 전용 SLB를 갖춘 새 아키텍처를 채택합니다. SLB는 MySQL 데이터 트래픽 경로를 관리하여 장애 조치(failover) 중에 DNS 변경이 필요하지 않으며 장애 조치(failover) 성능을 크게 향상시킵니다. 부하 분산 규칙을 사용하여 장애 조치(failover) 중에 트래픽을 현재 주 인스턴스로 리디렉션합니다. 퍼블릭 액세스 또는 프라이빗 링크가 있는 기존 서버는 영향을 최소화하기 위해 점진적으로 마이그레이션됩니다. 조기 마이그레이션을 선호하는 고객은 HA를 사용하지 않도록 설정하고 다시 사용하도록 설정할 수 있습니다. 이 기능은 VNet 통합과 함께 프라이빗 액세스를 사용하는 서버에서 지원되지 않습니다.
계획됨: 강제 장애 조치(failover)
Azure Database for MySQL 유연한 서버 강제 장애 조치(failover)를 사용하면 장애 조치(failover)를 수동으로 강제 적용할 수 있습니다. 이 기능을 사용하면 애플리케이션 시나리오에서 기능을 테스트할 수 있으며 중단에 대비하는 데 도움이 됩니다.
강제 장애 조치(failover)는 DNS 레코드를 업데이트하여 동일한 데이터베이스 서버 이름을 가진 주 서버가 되도록 대기 복제본을 활성화하는 장애 조치(failover)를 트리거합니다. 원래 주 서버가 다시 시작되고 대기 복제본으로 전환됩니다. 클라이언트 연결이 끊기며, 작업을 다시 시작하려면 다시 연결해야 합니다.
전체 장애 조치(failover) 시간은 현재 워크로드 및 마지막 검사점에 따라 달라집니다. 일반적으로 60~120초가 걸립니다.
참고
Azure Resource Health 이벤트는 계획된 장애조치 중에 생성됩니다. 이 이벤트는 서버를 사용할 수 없는 장애 조치(failover) 시간을 나타냅니다. 왼쪽 창의 Resource Health에서 선택하면 트리거된 이벤트를 볼 수 있습니다. 상태는 사용자가 시작한 장애 조치(failover) 또는 수동 장애 조치(failover)를 "사용할 수 없음"으로 나타내며 "계획됨"으로 태그가 지정됩니다. 예 - "권한 있는 사용자가 장애 조치 작업을 트리거했습니다(계획됨)." 리소스가 이 상태로 장기간 유지되는 경우 지원 티켓을 열고 지원을 받습니다.
계획되지 않음: 자동 장애 조치(failover)
계획되지 않은 서비스 가동 중지 시간은 컴퓨팅, 네트워크 또는 스토리지 오류와 같은 소프트웨어 버그 또는 인프라 오류로 인해 발생할 수 있습니다. 정전은 데이터베이스의 가용성에도 영향을 줄 수 있습니다. 데이터베이스를 사용할 수 없게 되면 대기 복제본에 대한 복제가 중지되고 대기 복제본이 주 데이터베이스가 됩니다. DNS 업데이트가 수행되고 클라이언트가 데이터베이스 서버에 다시 연결하여 작업을 다시 시작합니다.
전체 장애 조치(failover) 시간은 일반적으로 60초에서 120초 사이입니다. 그러나 장애 조치(failover) 시 주 데이터베이스 서버의 작업(예: 대용량 트랜잭션 및 복구 시간)에 따라 장애 조치(failover)가 더 오래 걸릴 수 있습니다.
참고
Azure Resource Health 이벤트는 계획되지 않은 장애 조치(failover) 중에 생성됩니다. 이 이벤트는 서버를 사용할 수 없는 장애 조치(failover) 시간을 나타냅니다. 왼쪽 창에서 Resource Health를 선택하면 트리거된 이벤트를 볼 수 있습니다. 자동 장애 조치(failover)는 "사용할 수 없음" 상태를 표시하며 "계획되지 않음"으로 태그가 지정됩니다.
예: 사용할 수 없음: 장애 조치(failover) 작업이 자동으로 트리거되었습니다(계획되지 않음). 리소스가 이 상태로 오랫동안 유지되는 경우 지원 티켓을 열고 지원을 받습니다.
HA 지원 서버에서 자동 장애 조치(failover) 검색이 작동하는 방식
주 서버와 보조 서버에는 각각 두 개의 네트워크 엔드포인트가 있습니다.
- 고객 엔드포인트: 고객은 이 엔드포인트를 사용하여 인스턴스에서 쿼리를 연결하고 실행합니다.
- 관리 엔드포인트: 관리 구성 요소에 대한 서비스 통신 및 백 엔드 스토리지에 연결하기 위해 내부적으로 사용됩니다.
상태 모니터 구성 요소는 다음 검사를 지속적으로 수행합니다.
- 모니터는 노드의 관리 네트워크 엔드포인트를 ping합니다. 이 검사가 두 번 연속 실패하면 자동 장애 조치(failover) 작업이 트리거됩니다. 이 상태 검사는 OS 문제, 관리 구성 요소와 노드 간의 네트워킹 문제 및 유사한 문제로 인한 노드 사용 불가 또는 응답하지 않는 시나리오를 해결합니다.
- 모니터는 인스턴스에서 간단한 쿼리를 실행합니다. 쿼리가 실행되지 않으면 자동 장애 조치(failover)가 트리거됩니다. 이 상태 검사는 MySQL 디먼 크래시, 중지 또는 중단, 백 엔드 스토리지 문제 및 이와 유사한 문제 같은 시나리오를 해결합니다.
참고
상태 검사는 애플리케이션과 고객 네트워킹 엔드포인트(프라이빗/퍼블릭 액세스) 간의 네트워킹 문제는 모니터링하지 않습니다. 이러한 문제는 네트워킹 경로, 엔드포인트 또는 클라이언트 쪽의 DNS 문제에서 발생할 수 있습니다. 프라이빗 액세스를 사용하는 경우 가상 네트워크에 대한 NSG 규칙이 포트 3306의 인스턴스 고객 네트워킹 엔드포인트에 대한 통신을 차단하지 않는지 확인합니다. 공용 액세스의 경우 방화벽 규칙이 설정되고 네트워크 트래픽이 포트 3306에서 허용되는지 확인합니다(네트워크 경로에 다른 방화벽이 있는 경우). 또한 클라이언트 애플리케이션 쪽에서 DNS 확인을 처리해야 합니다.
고가용성 모니터링
서버의 고가용성 구성 상태를 확인하려면 포털의 서버 고가용성 창에서 고가용성 상태를 사용합니다.
| 상태 | 설명 |
|---|---|
| NotEnabled | 고가용성을 사용할 수 없습니다. |
| ReplicatingData | 대기 서버는 고가용성 서버 프로비전 중 또는 고가용성 옵션을 사용하도록 설정하는 동안 주 서버와 동기화됩니다. |
| FailingOver | 데이터베이스 서버가 주 서버에서 대기로 장애 조치(failover)되는 중입니다. |
| 정상 | 고가용성 옵션을 사용할 수 있습니다. |
| RemovingStandby | 고가용성 옵션을 사용하지 않도록 설정하면 삭제 프로세스가 진행됩니다. |
고가용성 서버의 상태를 모니터링하려면 다음 메트릭을 사용합니다.
| 메트릭 표시 이름 | 메트릭 | 단위 | 설명 |
|---|---|---|---|
HA IO 상태 |
ha_io_running | 시스템 상태 | HA IO 상태는 HA 복제 상태를 표시합니다. I/O 스레드가 실행 중인 경우 메트릭 값은 1이고 그렇지 않은 경우 0입니다. |
| HA SQL 상태 | ha_sql_running | 시스템 상태 | HA SQL 상태는 HA 복제 상태를 표시합니다. SQL 스레드가 실행 중인 경우 메트릭 값은 1이고 그렇지 않으면 0입니다. |
| HA 복제 지연 | 복제 지연 | 초 | 복제 지연은 주 서버에서 받은 트랜잭션을 재생하는 데 대기 시간이 지연되는 시간(초)입니다. |
제한 사항
고가용성을 사용할 때는 다음 사항을 고려해야 합니다.
서버를 만드는 동안에만 영역 중복 고가용성을 구성할 수 있습니다.
버스트 가능 컴퓨팅 계층은 고가용성을 지원하지 않습니다.
주 데이터베이스 서버를 다시 시작하여 정적 매개 변수 변경 내용을 적용하면 대기 복제본도 다시 시작됩니다.
솔루션은 GTID를 사용하기 때문에 GTID 모드를 활성화합니다. 워크로드에 GTID를 사용한 복제에 대한 제한 또는 한계가 있는지 확인합니다.
참고
스토리지 자동 증가는 고가용성 구성 서버에 대해 기본적으로 사용하도록 설정되며 사용하지 않도록 설정할 수 없습니다.
상태 검사
Azure Database for MySQL에 대한 HA(고가용성)를 구성하는 경우 상태 검사는 데이터베이스의 안정성과 성능을 유지하는 데 중요한 역할을 합니다. 이러한 검사는 주 복제본과 대기 복제본의 상태 및 상태를 지속적으로 모니터링하여 문제를 즉시 감지하도록 합니다. 상태 검사는 서버 응답성, 복제 지연 시간 및 리소스 사용률과 같은 다양한 메트릭을 추적하여 장애 조치(failover) 프로세스를 원활하게 실행함으로써 가동 중지 시간을 최소화하고 데이터 손실을 방지하는 데 도움이 됩니다. 올바르게 구성된 상태 검사는 데이터베이스 설정에서 원하는 수준의 가용성 및 복원력을 달성하는 데 필수적입니다.
상태 모니터링
Azure Portal을 통해 HA 설정의 상태를 모니터링할 수 있습니다. 관찰할 주요 메트릭은 다음과 같습니다.
- 서버 응답성: 주 서버에 연결할 수 있는지 여부를 나타냅니다.
- 복제 지연 시간: 주 복제본과 대기 복제본 간의 지연을 측정하여 데이터 일관성을 보장합니다.
- 리소스 사용률: CPU, 메모리 및 스토리지 사용량을 모니터링하여 병목 상태를 방지합니다.