다음을 통해 공유

Azure Database for MySQL 안정성

Azure Database for MySQL 데이터베이스 관리 기능 및 구성 설정에 대한 세부적인 제어 및 유연성을 제공하도록 설계된 완전 관리형 데이터베이스 서비스입니다. 이 서비스는 요구 사항에 따라 고가용성 및 재해 복구 기능을 제공합니다.

Azure 사용하는 경우 신뢰성은 공유 책임입니다. Microsoft 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.

이 문서에서는 일시적인 오류, 가용성 영역 중단, 지역 중단 및 서비스 유지 관리를 포함하여 다양한 잠재적 중단 및 문제에 Azure Database for MySQL 복원력을 제공하는 방법을 설명합니다. 또한 백업을 사용하여 다른 유형의 문제에서 복구하는 방법을 설명하고 Azure Database for MySQL SLA(서비스 수준 계약)에 대한 몇 가지 주요 정보를 강조 표시합니다.

프로덕션 배포 권장 사항

솔루션의 안정성 요구 사항을 지원하기 위해 Azure Database for MySQL 배포하는 방법과 안정성이 아키텍처의 다른 측면에 미치는 영향에 대해 알아보려면 Azure Well-Architected Framework Azure Database for MySQL 대한Architecture 모범 사례를 참조하세요.

안정성 아키텍처 개요

이 섹션에서는 안정성 관점에서 가장 관련성이 높은 서비스가 작동하는 방식의 몇 가지 중요한 측면을 설명합니다. 이 섹션에서는 배포하고 사용하는 일부 리소스 및 기능을 포함하는 논리 아키텍처를 소개합니다. 또한 서비스의 작동 방식에 대한 세부 정보를 제공하는 물리적 아키텍처에 대해서도 설명합니다.

논리 아키텍처

Azure Database for MySQL 사용하는 경우 데이터베이스 서버를 지원하는 데 필요한 컴퓨팅 및 스토리지 리소스를 나타내는 server 배포합니다. 서버에 하나 이상의 데이터베이스를 배포합니다 .

버스트 가능, 범용 및 메모리 최적화 등 여러 컴퓨팅 계층에 서버를 배포할 수 있으며, 각 서버는 다양한 종류의 워크로드에 최적화되어 있습니다.

일반 서비스 아키텍처 및 배포 모델에 대한 자세한 내용은 Azure Database for MySQL? 참조하세요.

물리적 아키텍처

  • 컴퓨트 및 스토리지 분리: Azure Database for MySQL 컴퓨팅 및 스토리지 분리 아키텍처를 사용하여 고가용성을 지원합니다. 데이터베이스 엔진은 가상 머신에서 실행됩니다. 데이터 파일은 스토리지 하드웨어 오류로부터 보호하기 위해 데이터의 복사본 3개를 동기적으로 유지 관리하는 Azure Storage 저장됩니다. 서버의 고가용성 구성에 따라 데이터 파일을 ZRS(영역 중복 스토리지) 또는 LRS(로컬 중복 스토리지)에 저장할 수 있습니다.

  • 고가용성: 필요에 따라 서버에서 고가 용성 구성 을 사용하도록 설정할 수 있습니다. 고가용성 구성을 활성화하면 서비스가 웜 스탠바이 복제 서버를 설정하고 유지 관리합니다. 주 서버의 데이터 변경 내용은 주 서버가 실패하는 동안 데이터가 손실되지 않도록 대기 복제본 서버에 동기적으로 복제됩니다.

    아키텍처는 컴퓨팅 계층을 스토리지 계층과 분리하여 서비스가 다양한 유형의 오류를 적절하게 처리할 수 있도록 합니다. 복원력을 높이기 위해 가용성 영역에 서버를 분산할 수 있습니다.

    대기 복제본 서버는 vCore, 스토리지 및 네트워크 설정을 포함하여 주 서버와 동일한 VM 구성에 배포됩니다.

    장애 조치( failover)를 수행하여 서버 간에 전환할 수 있습니다. 기본 서버가 실패할 때 사용되는 계획되지 않은 장애 조치(failover)와 장애 조치(failover) 중에 애플리케이션 가동 중지 시간을 최소화해야 하는 다른 시나리오에서 사용되는 계획된 장애 조치(failover)의 두 가지 유형이 있습니다.

    자세한 내용은 MySQL용 Azure Database에서 고가용성을 참조하세요.

  • Backups: Azure Database for MySQL 자동으로 서버 백업을 만듭니다. 자세한 내용은 백업 및 복원을 참조하세요.

일시적인 오류에 대한 복원력

일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.

모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 일시적인 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.

애플리케이션은 유지 관리, 크기 조정 작업 또는 네트워크 중단 중에 발생할 수 있는 일시적인 연결 오류를 처리해야 합니다. 다음 권장 사항을 따릅니다.

  • 애플리케이션에 일시적인 오류가 발생하면 지수 백오프를 사용하여 작업을 다시 시도합니다. 재시도 사이의 지연 시간을 늘리고 시도 횟수를 제한합니다. 최대 재시도 후에도 작업이 계속 실패하는 경우 실패로 처리합니다.
  • 가능한 경우 재시도를 자동으로 처리하는 클라이언트 라이브러리 를 사용합니다.
  • 쓰기 작업 중에 발생하는 일시적인 오류는 더 신중하게 고려해야 합니다. 여러 번 안전하게 실행할 수 있도록 쓰기 작업을 idempotent로 만드는 것이 좋습니다.

가용성 영역 오류에 대한 복원력

사용 가능성 영역은 Azure 지역 내에서 물리적으로 분리된 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.

고가용성 구성을 통해 가용 영역 지원 유형을 선택할 수 있습니다. 고가용성을 사용하도록 설정하면 주 서버와 함께 대기 복제본 서버가 배포됩니다. 이 고가용성 모델은 오류가 발생하는 동안 커밋된 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 어떤 고가용성 배포 모델을 선택하든 데이터는 주 복제본 서버와 대기 복제본 서버 모두에 동기적으로 커밋됩니다. 주 서버에 중단이 발생하면 서버는 자동으로 대기 복제본 서버로 장애 조치됩니다.

데이터는 Azure Files Premium Storage에 저장됩니다. 서버의 고가용성 구성에 따라 영역 중복 스토리지 또는 LRS(로컬 중복 스토리지)를 사용하여 가용성 영역 내 또는 가용성 영역 간에 세 개의 데이터 복사본을 저장합니다.

Azure Database for MySQL 고가용성을 사용하는 경우 두 가지 가용성 영역 구성 유형을 지원합니다.

  • 영역 중복 고가용성: 영역 중복성은 하나의 가용성 영역에 주 서버를 배포하고 다른 가용성 영역에 대기 복제본 서버를 배포하여 가장 높은 수준의 영역 복원력을 제공합니다. 대기 복제본 서버는 주 복제본과 유사한 컴퓨팅, 스토리지 및 네트워크 구성을 사용합니다. 영역 중복 구성은 주 서버와 대기 서버 간의 전체 스택을 물리적으로 격리합니다.

    기본 및 대기 서버에 대한 가용성 영역을 선택합니다.

    프로덕션 서버에 대한 영역 중복 배포를 권장합니다.

    쓰기 작업은 서비스가 대기 서버에 데이터를 동기적으로 복제하기 때문에 커밋 대기 시간이 약간 증가할 수 있습니다. 평균적으로 애플리케이션 쓰기 및 커밋의 대기 시간이 5~10% 증가할 것으로 예상할 수 있지만 그 영향은 워크로드, 선택한 SKU 및 지역에 따라 달라집니다.

  • 로컬 중복 고가용성: 주 서버와 대기 서버는 동일한 가용성 영역을 사용합니다. 주 서버에 장애가 발생해도 영역이 여전히 정상이면 서버가 자동으로 대기 서버로 장애 조치됩니다.

    로컬 중복 배포는 단일 가용성 영역 내에서 고가용성을 제공합니다. 노드 수준 오류로부터 보호하고 계획 및 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데도 도움이 됩니다. 하지만 해당 지역에서의 서비스 중단을 방지하지는 않습니다. 가용성 영역이 있는 지역에서는 이러한 종류의 구성을 영역 또는 단일 영역이라고도 합니다.

    특정 시나리오에서만 로컬 중복 고가용성을 권장합니다.

    • 비정상적으로 대기 시간이 중요한 애플리케이션이 있는 경우 주 복제본과 보조 복제본 간의 대기 시간을 최소화해야 하는 필요성을 확인했으며 다른 아키텍처 방법을 사용하여 영역 복원력을 직접 계획했습니다.
    • 가용성 영역을 지원하지 않는 지역에 배포하는 경우 지역은 효과적으로 단일 영역으로 작동하여 로컬 중복 고가용성을 유일한 고가용성 옵션으로 만듭니다.

    서버는 동일한 영역에 있으므로 해당 영역 내에 배포하는 애플리케이션에 대한 쓰기 대기 시간을 줄일 수 있습니다.

고가용성 없이 서버를 구성하는 경우 단일 서버에서 실행됩니다. 해당 서버 또는 해당 영역이 다운되면 서버를 사용할 수 없습니다.

요구 사항

  • Region support: Azure Database for MySQL 가용성 영역 구성에 대한 지원은 Azure 지역마다 다릅니다. 전체 지역 목록 및 가용성 영역 지원 유형 및 해당 지역에 대한 특정 고려 사항은 Azure 지역 참조하세요.

  • 서비스 계층: 고가용성을 위해서는 범용 또는 메모리 최적화 계층이 필요합니다. 버스트 가능한 계층은 높은 가용성(영역 중복 또는 지역 중복)을 지원하지 않습니다.

Cost

고가용성을 사용하도록 설정하면 대기 서버가 생성되고 기본 서버와 동일한 속도로 요금이 청구됩니다. 가용성 영역 구성은 비용에 영향을 주지 않습니다. 가용성 영역 내에서 또는 가용성 영역 간에 데이터 복제에 대한 요금은 없습니다. 백업 스토리지 볼륨에 따라 백업 스토리지에 대한 요금이 청구될 수도 있습니다. 자세한 가격 책정 정보는 Azure Database for MySQL 가격 책정 참조하세요.

고려 사항

  • 기본 키: 이 방법을 사용하면 복제 및 장애 조치(failover) 시간이 단축되므로 모든 테이블에서 기본 키를 사용하는 것이 좋습니다.
  • 제한 사항 및 알려진 문제:제한 사항 및 알려진 문제 목록을 검토합니다.

가용성 영역 지원 구성

서버에 대한 가용성 영역 지원을 구성하려면 고가용성 설정을 구성합니다.

메모

사용할 가용성 영역을 선택하면 실제로 논리적 가용성 영역을 선택합니다. 다른 Azure 구독에 다른 워크로드 구성 요소를 배포하는 경우 다른 논리 가용성 영역 번호를 사용하여 동일한 물리적 가용성 영역에 액세스할 수 있습니다. 자세한 내용은 물리적 및 논리적 가용성 영역을 참조하세요.

모든 영역이 정상인 경우의 동작

이 섹션에서는 서버가 고가용성 및 가용성 영역 지원으로 구성되고 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.

  • 영역 간 작업: MySQL 클라이언트 애플리케이션은 데이터베이스 서버의 FQDN(정규화된 도메인 이름)을 사용하여 주 서버에 연결합니다. 장애 조치(failover) 중을 포함하여 IP 주소가 변경 될 수 있으므로 주 서버의 IP 주소를 사용하지 마십시오.

    Azure Database for MySQL 모든 데이터베이스 연결 및 쿼리가 주 가용성 영역의 주 서버에서 처리되는 활성/수동 구성을 사용합니다. 대기 복제본 서버는 정상적인 작업 중에 클라이언트 트래픽을 제공하지 않습니다.

  • 영역 간 데이터 복제: 쓰기는 주 서버에서 커밋되며 ZRS를 사용하여 대기 서버의 로그에 동기적으로 기록됩니다. 주 서버는 대기 서버가 로그를 적용할 때까지 기다리지 않지만 로그가 ZRS에 있으므로 복제본 또는 영역 오류가 발생하더라도 사용할 수 있습니다.

    복제의 효과는 서버에서 사용하는 가용성 영역 구성에 따라 다릅니다.

    • 영역 중복: 서버는 별도의 영역에 있으므로 이 방법을 사용하면 영역 오류가 발생한 동안 데이터가 손실되지 않습니다. 이 상황을 영역 오류에 대해 RPO(복구 지점 목표)를 0으로 달성하는 것으로도 알려져 있습니다.

      그러나 영역 간 복제로 인해 약간의 추가 대기 시간이 발생할 수 있습니다. 평균적으로 애플리케이션 쓰기 및 커밋의 대기 시간이 5~10% 증가할 것으로 예상할 수 있지만 그 영향은 워크로드, 선택한 SKU 및 지역에 따라 달라집니다.

    • 로컬 중복: 영역 간에 복제되는 트래픽이 없습니다.

    메모

    시스템은 실수로 테이블 삭제 또는 잘못된 데이터 업데이트와 같은 의도하지 않은 사용자 오류를 포함하여 대기 복제본 서버에 모든 변경 내용을 실시간으로 복제합니다. 즉각적인 복제로 인해 복구에 대기 복제본을 사용할 수 없습니다. 사용자 오류에서 복구하려면 백업에서 지정 시간 복원을 수행해야 합니다. 자세한 내용은 백업 및 복원을 참조하세요.

영역 오류 중 동작

이 섹션에서는 서버가 고가용성 및 가용성 영역 지원으로 구성되고 가용성 영역 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 검색 및 응답: Azure 주 서버와 대기 서버의 상태를 주기적으로 확인합니다. 여러 ping 후 상태 모니터링에서 주 서버에 연결할 수 없음을 감지하면 서비스는 대기 서버에 대한 자동 장애 조치(failover)를 시작합니다. 상태 모니터링 알고리즘은 여러 데이터 요소를 사용하여 가양성 상황을 방지합니다.

    영역 오류가 발생할 경우 서버에서 사용하는 가용성 영역 구성에 따라 동작이 다릅니다.

    • Zone-redundant: Azure Database for MySQL 여러 서버 엔드포인트를 지속적으로 모니터링하여 가용성 영역 오류를 자동으로 검색합니다. 자세한 내용은 HA 지원 서버에서 자동 장애 조치(failover) 탐지 작동 방식을 참조하세요.

      가능한 고가용성 상태 유형을 보려면 고가용성 모니터링을 참조하세요. 영역이 실패하면 Azure 작업을 수행할 필요 없이 대기 서버에 계획되지 않은 장애 조치를 시작합니다.

    • 로컬 중복: 로컬 중복 서버를 호스트하는 가용성 영역을 사용할 수 없게 되면 주 서버와 대기 서버를 모두 사용할 수 없습니다. 이 시나리오에서 서비스는 자동 장애 조치(failover)를 제공하지 않습니다. 영역 중단을 감지하고 다른 가용성 영역 또는 지역의 별도 서버로 영역 중복 백업 복원과 같은 복구 작업을 수행할 책임이 있습니다.

  • Notification: 영역에 문제가 발생하면 Microsoft는 자동으로 알림을 보내지 않습니다. 그러나 Azure Resource Health 사용하여 개별 리소스의 상태를 모니터링하고 Resource Health 경고 설정하여 문제를 알릴 수 있습니다. 또한 Azure Service Health 사용하여 영역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며 Service Health 경고를 설정하여 문제를 알릴 수 있습니다.

    Azure Database for MySQL 계획되지 않은 장애 조치(failover)가 발생할 때 Azure Resource Health 이벤트를 생성합니다.

  • 활성 요청: 가용성 영역을 사용할 수 없게 되면 영향을 받는 영역의 서버에 대한 진행 중인 요청이 종료될 수 있습니다. 애플리케이션은 이러한 요청을 다시 시도해야 합니다. 클라이언트가 짧은 시간 후에 다시 시도하여 일시적인 오류를 적절하게 처리하는 경우 일반적으로 상당한 영향을 받지 않습니다.

  • 예상 데이터 손실: 데이터 손실의 양은 서버의 가용성 영역 구성에 따라 달라집니다.

    • 영역 중복: 서로 다른 영역의 주 서버와 대기 서버 간의 동기 복제로 인해 영역 장애 조치(failover) 중에 데이터 손실이 0으로 예상됩니다.

    • 로컬 중복: 영역이 복구될 때까지 영향을 받는 영역의 서버에 있는 데이터를 사용할 수 없습니다.

  • 예상 가동 중지 시간: 가동 중지 시간은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.

    • 영역 중복: 장애 조치(failover)는 일반적으로 60-120초 내에 완료됩니다. 클라이언트가 짧은 시간 후에 다시 시도하여 일시적인 오류를 적절하게 처리하는 경우 일반적으로 상당한 영향을 받지 않습니다.

    • 로컬 중복: 영향을 받은 영역의 서버는 가용성 영역이 복구될 때까지 사용할 수 없습니다.

  • 재배포: 트래픽 경로 변경 동작은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.

    • 영역 중복: 장애 조치(failover) 후 이전 대기 서버는 새로운 주 서버가 되고, 새 연결을 수락하기 시작합니다. Azure 복구한 후 원래 기본 영역에 대기 서버를 자동으로 설정합니다. 자세한 내용은 계획되지 않은 장애 조치(failover)를 참조하세요.

    • 로컬 중복: 영역을 사용할 수 없는 경우 서버를 사용할 수 없습니다. 다른 가용성 영역 또는 지역에서 미리 생성한 별도의 서버가 있는 경우 해당 서버로 트래픽을 다시 라우팅해야 합니다.

영역 복구

영역 복구 동작은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.

  • Zone-redundant: 가용성 영역이 복구되면 Azure Database for MySQL 자동으로 복구된 영역에서 대기 서버를 다시 빌드하고 현재 주 서버와 동기화합니다. 그러면 복구된 영역이 대기 위치로 사용됩니다. 서비스는 불필요한 중단을 방지하기 위해 기본 역할을 원래 영역으로 자동으로 다시 이동하지 않습니다. 주 영역을 원래 위치로 복원하려는 경우 계획된 장애 조치(failover)를 수동으로 시작할 수 있습니다.

  • 지역 중복: 영역의 상태가 정상이 되면, 해당 영역의 서버를 다시 사용할 수 있습니다. 워크로드에 필요한 영역 복구 절차 및 데이터 동기화를 담당합니다.

영역 오류 테스트

영역 오류 테스트 옵션은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.

  • 영역 중복성: 계획된 장애 조치(failover)를 시작하여 애플리케이션의 복원력을 테스트할 수 있습니다. 계획된 장애 조치(failover)를 사용하면 워크로드를 실행하는 동안 계획되지 않은 중단 시나리오를 시뮬레이션하고 애플리케이션 가동 중지 시간을 관찰할 수 있습니다. 비프로덕션 환경에서 또는 조용한 시간에 시뮬레이션을 실행하는 것이 좋습니다. 자세한 내용은 계획된 장애 조치(failover)를 참조하세요.

  • 로컬 중복: 전체 영역 중단을 시뮬레이트할 수는 없지만 영역 중단 시 발생하는 것과 비슷한 방식으로 서버를 사용할 수 없는 것을 시뮬레이션할 수 있습니다. 자세한 내용은 다음을 참조하십시오.

지역 전체 오류에 대한 복원력

Azure Database for MySQL cross 지역 읽기 복제본을 지원합니다. 이 복제본을 사용하여 더 빠른 복구를 위해 다른 지역에서 데이터베이스의 동기화된 복사본을 유지 관리할 수 있습니다.

지원되는 지역에서 지역 중복 백업을 사용하여 지역 간 복구를 제공할 수도 있습니다. 그러나 백업에는 일반적으로 복제보다 더 많은 가동 중지 시간과 데이터 손실이 포함됩니다. 자세한 내용은 백업 및 복원을 참조하세요.

지역 간 읽기 복제본

읽기 복제본을 배포하여 지역 수준 오류로부터 데이터베이스를 보호할 수 있습니다. 각 읽기 복제본은 별도의 Azure Database for MySQL 서버입니다. 두 번째 Azure 지역에 읽기 복제본을 배치하면 데이터베이스 서버가 지역 전체 문제에 대한 복원력을 제공할 수 있습니다. 필요에 따라 다른 Azure 지역에 있을 수 있는 최대 10개의 읽기 복제본을 배포할 수 있습니다. MySQL의 물리적 복제 기술은 주 지역의 원본 서버에서 읽기 복제본을 비동기적으로 업데이트하고 원본을 지연할 수 있습니다. 지역 간 읽기 복제본은 필요에 따라 읽기 전용 워크로드를 사용하여 전역적으로 분산된 애플리케이션의 대기 시간을 줄이거나 원본 서버에서 읽기 트래픽을 오프로드할 수 있습니다. 읽기 복제본 기능 및 고려 사항에 대한 자세한 내용은 읽기 복제본을 참조하세요.

주 지역이 실패하면 보조 복제본이 주 서버가 되도록 수동으로 장애 조치(failover)할 수 있습니다. 이렇게 하려면 읽기 복제본을 읽기-쓰기 서버로 승격하는 복제 프로세스를 중지합니다. 비동기 복제로 인해 장애 조치(failover) 시 데이터가 손실될 수 있습니다. 그러면 애플리케이션이 새 주 서버에 연결해야 하며, 이 애플리케이션 재구성을 담당합니다.

메모

이 섹션에서는 읽기 복제본이 지역 전체 오류에 대한 복원력을 지원할 수 있는 방법에 대한 몇 가지 중요한 정보를 요약합니다. 읽기 복제본을 사용하여 성능을 향상시키고 지리적으로 분산된 대규모 사용자 기반을 지원할 수도 있습니다. 자세한 내용은 리드 레플리카 참조하세요.

요구 사항

  • Region support: Azure Database for MySQL 지원하는 모든 지역에서 지역 간 읽기 복제본을 만들 수 있습니다. Azure에서 쌍으로 연결된 지역으로 제한되지 않습니다.

  • 컴퓨팅 계층: 범용 및 메모리 최적화 컴퓨팅 계층은 읽기 복제본을 지원합니다. 버스트 가능 계층은 읽기 복제본을 지원하지 않습니다.

고려 사항

  • 구성 차이점: 복제본을 만들 때 컴퓨팅 생성, vCore 및 스토리지를 포함하여 원본 서버에서 여러 설정을 상속합니다. 읽기 복제본을 만든 후 읽기 복제본에서 이러한 값을 사용자 지정할 수 있습니다. 그러나 복제본이 원본의 변경 내용을 따라갈 수 있도록 하려면 같거나 더 큰 값을 사용하는 것이 가장 좋습니다.

  • 복제 지연 모니터링: 비동기 복제 프로세스에는 여러 요인에 따라 달라질 수 있는 복제 지연 시간이 필요합니다. 복제 지연 시간이 매우 높으면 서버에 문제가 발생할 수 있습니다. 문제가 에스컬레이션되기 전에 완화할 수 있도록 복제 지연 시간을 모니터링하는 것이 중요합니다. 자세한 내용은 복제 모니터링을 참조하세요.

  • 고가용성: 읽기 복제본은 고가용성을 사용할 수 없으며 주 서버가 되기 위해 장애 조치(failover)된 경우에도 고가용성이 없습니다. 복제본으로 장애 조치(failover)한 후 고가용성을 구성할 책임이 있습니다.

Cost

읽기 복제본에는 복제에 대한 지역 간 데이터 전송 요금뿐만 아니라 컴퓨팅 및 스토리지 비용이 발생합니다. 자세한 가격 책정 정보는 Azure Database for MySQL 가격 책정 및 Bandwidth 가격 책정 참조하세요.

다중 지역 지원 구성

모든 지역이 정상인 경우의 동작

이 섹션에서는 서버가 다른 지역의 읽기 복제본으로 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.

  • 지역 간 트래픽 라우팅: 일반적인 작업에서 애플리케이션은 읽기/쓰기 트래픽을 주 지역의 원본 서버로 전달해야 합니다. 필요에 따라 읽기 요청을 읽기 복제본으로 전송할 수 있습니다.

  • 지역 간 데이터 복제: 지역 간 읽기 복제본은 비동기 복제를 사용하여 원본 서버 성능에 미치는 영향을 최소화합니다. 복제 지연 시간은 쓰기 로드 및 원본 서버와 복제본 간의 대기 시간을 비롯한 다양한 요인에 따라 달라집니다. 복제 지연 시간은 일반적으로 몇 분 이상이지만 훨씬 더 길어질 수 있습니다. 자세한 내용은 모니터 복제를 참조하고 자세한 지침은 Azure Portal모니터 복제 참조하세요.

지역 오류 중 동작

이 섹션에서는 서버가 다른 지역의 읽기 복제본으로 구성되고 주 지역에 중단이 발생할 때 예상되는 사항에 대해 설명합니다.

  • 탐지 및 대응: 귀하는 주 지역에서 중단을 탐지하고 장애 조치(failover)를 수동으로 트리거해야 할 책임이 있습니다. 이 작업을 수행하면 복제되지 않은 데이터가 손실될 수 있습니다.

    중요합니다

    장애 조치(failover)를 트리거할 책임이 있습니다. Azure 지역 오류가 있더라도 복제본을 자동으로 읽도록 장애 조치(failover)하지 않습니다.

    장애 조치(failover)를 수행하려면 다음을 수행해야 합니다.

    1. 복제를 중지합니다. 이는 되돌릴 수 없는 절차이며 서버를 복제본으로 다시 만들 수 없습니다. 이 프로세스로 인해 데이터가 손실됩니다. 이 작업의 의미에 대한 자세한 내용은 복제 중지를 참조하세요.
    2. 새 기본 인스턴스를 사용하도록 애플리케이션을 다시 구성합니다.

    자세한 내용은 장애 조치(failover)를 참조하세요.

  • Notification: Microsoft는 지역이 다운되더라도 자동으로 알림을 보내지 않습니다. 그러나 Azure Service Health 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악하고 Service Health 경고를 설정하여 문제를 알릴 수 있습니다.

  • 활성 요청: 원본 서버를 사용할 수 없는 경우 원본 지역에 대한 모든 활성 연결이 삭제됩니다. 애플리케이션은 장애 조치(failover) 프로세스가 완료된 후 새 주 서버에 대한 연결을 다시 시도해야 합니다.

  • 예상 데이터 손실: 지역 중단 중에 복제를 중지하는 장애 조치(failover)를 수행해야 합니다. 이 프로세스로 인해 복제되지 않은 데이터가 영구적으로 손실됩니다.

    데이터 손실의 양은 중단 시의 복제 지연에 따라 달라집니다. 복제 지연 시간은 일반적으로 몇 분 이상이지만 훨씬 더 길어질 수 있습니다. 자세한 내용은 복제 모니터링을 참조하세요.

  • 예상 가동 중지 시간: 복제 중지는 일반적으로 트리거된 후 2분 이내에 완료됩니다. 새 주 서버에 연결하도록 애플리케이션을 다시 구성해야 하며, 재구성을 수행하는 데 걸리는 시간도 전체 가동 중지 시간에 영향을 줍니다.

  • 트래픽 경로 변경: 새 주 서버에 연결하도록 애플리케이션을 다시 구성할 책임이 있습니다.

    메모

    읽기 복제본을 주 서버로 전환한 후, 그 서버에는 고가용성이 활성화되지 않습니다. 고가용성을 수동으로 사용하도록 설정하거나 자동화에 포함해야 합니다.

지역 복구

지역이 복구되면, 귀하는 주 지역에서의 작업 재개를 위한 장애 복구 활동을 책임집니다. Microsoft 주 서버를 자동으로 이동하지 않습니다. 주 지역에 새 읽기 복제본을 만든 다음 다른 장애 조치(failover) 프로세스를 수행하여 주 지역에서 작업을 복원할 수 있습니다. 애플리케이션이 가동 중지 시간 또는 데이터 손실을 허용할 수 있는지 여부에 따라 다음 방법 중 하나를 고려합니다.

  • 애플리케이션을 오프라인으로 전환하고 복제가 모든 변경 내용을 따라잡을 때까지 기다립니다. 이 방법을 사용하려면 복제 지연 시간과 거의 같은 애플리케이션 가동 중지 시간이 필요합니다.
  • 장애 조치 전환을 수행하고 복제되지 않은 데이터의 손실을 허용합니다.

필요에 따라 새 주 서버에 연결하도록 애플리케이션을 다시 구성해야 합니다.

지역 오류 테스트

읽기 복제본 장애 조치(failover) 절차를 주기적으로 테스트하여, 그 절차가 유효한지와 기능이 RTO 및 RPO 요구 사항을 충족하는지를 확인합니다.

모든 지역이 정상인 경우에도 언제든지 읽기 복제본을 장애 조치하여 주 서버가 될 수 있습니다. 비프로덕션 환경에서 이러한 테스트를 수행하는 것이 좋습니다. 데이터 손실이 발생할 수 있고 수동 장애 복구(failback)가 필요할 수 있습니다.

재해 복구 전략의 일환으로 정기적으로 전체 복구 훈련을 실행합니다. 이러한 훈련에는 데이터 유효성 검사, 애플리케이션 기능 테스트, 문서화된 롤백 절차가 포함되어야 합니다.

백업 및 복원

Azure Database for MySQL 지정 시간 복구 기능을 제공하는 백업을 자동으로 수행하며 실수로 인한 손상 및 데이터 삭제로부터 사용자를 보호합니다. 백업을 완전히 관리하는 Microsoft 서버의 가용성을 중단하지 말고 전체 백업 및 트랜잭션 로그 백업을 모두 포함합니다.

  • 백업 스토리지: 서버가 영역 중복 고가용성으로 구성된 경우 백업은 ZRS(영역 중복 스토리지)에 저장됩니다. 고가용성 없이 구성된 서버나 로컬 중복 고가용성으로 구성된 서버의 경우, 백업은 LRS(로컬 중복 스토리지)에 저장됩니다.

    쌍이 있는 Azure 지역에서는 서버 생성 시 GRS(지역 중복) 백업 스토리지를 구성하여 지역 오류에 대한 추가 보호를 위해 Azure 쌍을 이루는 지역에 백업을 복제할 수 있습니다. 백업은 비동기적으로 복제됩니다.

    기본 백업 보존 기간은 7일이며 보존 기간을 최대 35일로 연장할 수 있습니다. 모든 백업이 암호화됩니다.

  • 복원: 지정 시간 복구를 사용하면 백업 보존 기간 내에 언제든지 데이터베이스를 복원할 수 있습니다. 복원 프로세스는 사용자가 제공한 새 서버 이름을 사용하여 새 데이터베이스 서버를 만든 다음, as-is 사용하거나 데이터를 복사할 수 있습니다.

    지역 중복 백업을 복원하는 경우 쌍을 이루는 지역에 새 서버를 만듭니다. 일부 지역에서는 유니버설 Geo-Restore를 사용하여 주 지역과 짝을 이루지 않은 다른 지역에 지리적 중복 백업을 복원할 수 있습니다.

    이 기능은 실수로 인한 데이터 수정, 애플리케이션 오류 또는 테스트 시나리오에서 복구하는 데 유용합니다.

대부분의 솔루션의 경우 백업에만 의존해서는 안 됩니다. 대신 이 가이드에 설명된 다른 기능을 사용하여 복원력 요구 사항을 지원합니다. 그러나 백업은 다른 방법이 사용하지 않는 일부 위험으로부터 보호합니다. 자세한 내용은 중복도, 복제 및 백업이란?을 참조하세요.

자세한 내용은 Azure Database for MySQL 참조하세요.

서비스 유지 관리에 대한 복원력

Azure Database for MySQL 기본 하드웨어, 운영 체제 및 데이터베이스 엔진의 패치를 포함하여 중요한 서비스 작업을 자동으로 처리합니다. 이 서비스에는 계획된 유지 관리의 일부로 보안 업데이트, 소프트웨어 업데이트 및 부 버전 업그레이드가 포함됩니다. 자세한 내용은 Azure Database for MySQL에서의 예약된 유지 관리를 참조하십시오.

유지 관리 기간 동안 서버를 계속 사용할 수 있도록 하려면 다음 권장 사항을 따르세요.

  • 유지 관리 기간 동안 관리 작업을 사용하지 마세요. 유지 관리가 진행되는 동안에는 서버 관리 작업을 수행하지 마세요. 이러한 작업은 서버의 안정성에 영향을 줄 수 있기 때문입니다.

  • 가동 중지 시간이 거의 0에 가까운 유지 관리를 사용합니다. 서버에 고가용성이 사용하도록 설정되어 있고 다른 자격 기준을 충족하는 경우 유지 관리 작업이 10-30초 이내에 완료되는 경우가 많습니다. 고가용성을 사용하는 경우 유지 관리 작업은 일반적으로 롤링 업데이트를 사용하여 가동 중지 시간을 최소화합니다. 부 버전 업그레이드와 같은 정기적인 유지 관리 작업은 먼저 대기 복제본에서 발생합니다. 가동 중지 시간을 줄이기 위해 유지 관리 작업이 나머지 노드에 적용되는 동안 워크로드가 계속 작동할 수 있도록 대기 상태가 기본으로 승격됩니다. 이 시퀀싱은 서버에서 영역 중복 또는 로컬 중복 고가용성을 사용하는지 여부에 관계없이 적용됩니다. 자세한 내용은 가동 중지 시간이 거의 없는 유지 관리를 참조하세요.

  • 사용자 지정 유지 관리 기간 구성: 유지 관리 일정을 시스템 관리로 구성하거나 사용자 지정 유지 관리 기간을 정의하여 비즈니스 운영에 미치는 영향을 최소화할 수 있습니다. 계획된 유지 관리 작업 일정을 다시 예약할 수도 있습니다. 낮은 작업 기간 동안 유지 관리를 예약하여 비즈니스 영향을 최소화합니다. 자세한 내용은 Azure Database for MySQL 참조하세요.

  • 재시도 논리 구현: 애플리케이션이 유지 관리 다시 시작 중에 발생할 수 있는 간단한 연결 중단을 처리할 수 있는지 확인합니다. 이러한 유형의 문제에 대해 애플리케이션을 복원할 수 있도록 하려면 일시적인 오류에 대한 복원력 지침을 참조하세요.

  • 개발 및 테스트 서버에서 Virtual Canary 유지 관리를 사용하도록 설정합니다 . 가상 카나리아 유지 관리는 업데이트에 대한 초기 액세스를 제공합니다. 개발 및 테스트 서버에서 사용하도록 설정하면 워크로드가 프로덕션 서버에 도달하기 전에 예정된 업데이트의 영향을 받지 않는지 확인할 수 있습니다. 자세한 내용은 Virtual Canary 유지 관리를 참조하세요.

서비스 수준 약정

Azure 서비스에 대한 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 솔루션이 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 자세한 내용은 SLA for 온라인 서비스 참조하세요.

Azure Database for MySQL 서버의 구성에 따라 다른 가용성 SLA를 제공합니다.

  • 영역 중복 고가용성으로 구성된 서버.
  • 로컬 중복 고가용성으로 구성된 서버.
  • 고가용성 없이 구성된 서버.

관련 콘텐츠

  • Last updated on