Azure Database for MySQL - 유연한 서버에서 비즈니스 연속성 개요

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

Azure Database for MySQL 유연한 서버는 계획된 및 계획되지 않은 중단이 발생했을 때 데이터베이스를 보호하는 비즈니스 연속성 기능을 지원합니다. 자동화된 백업 및 고가용성과 같은 기능은 서로 다른 복구 시간 및 데이터 손실 노출을 통해 다양한 수준의 장애 보호 기능을 지원합니다. 장애로부터 시스템을 보호하도록 애플리케이션을 설계할 때는 각 애플리케이션에 대해 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)를 고려해야 합니다. RTO는 데이터베이스 서비스가 중단된 이후의 가동 중지 시간에 개한 내결함성을 나타내고 RPO는 데이터 손실에 대한 내결함성을 나타냅니다.

다음 표에서는 Azure Database for MySQL 유연한 서버에서 제공하는 기능을 보여 줍니다.

기능	설명	제한 사항
백업 및 복구	이 서비스는 데이터베이스 파일에 대한 일일 백업을 자동으로 수행하고 트랜잭션 로그를 지속적으로 백업합니다. 백업은 1~35일까지 보존될 수 있습니다. 백업 보존 기간 내의 어느 시점으로도 데이터베이스 서버를 복원할 수 있습니다. 복구 시간은 복원해야 할 데이터의 크기와 로그 복구를 수행하는 데 걸리는 시간에 따라 달라집니다. 자세한 내용은 개념 - 백업 및 복원을 참조하세요.	백업 데이터가 지역 내에 유지됨
로컬 중복 백업	서비스 백업은 한 지역 내 그리고 동일한 가용성 영역에서 로컬 중복 스토리지에 자동으로 안전하게 저장됩니다. 로컬로 중복된 백업을 사용해서 기본 지역에 있는 단일 물리적 위치 내에서 서버 백업 데이터 파일을 3회 복제합니다. 로컬 중복 백업 스토리지는 1년 동안 개체에 대해 최소 99.999999999%(11개 9) 내구성을 제공합니다. 자세한 내용은 개념 - 백업 및 복원을 참조하세요.	모든 지역에서 적용 가능
지역 중복 백업	서비스 백업을 만들 때 지역 중복으로 구성할 수 있습니다. 지역 중복을 사용하면 지역 복원력이 제공되도록 주 지역의 연결된 지역에 서버 백업 데이터 파일이 복제됩니다. 지역 중복 백업 스토리지는 1년 동안 개체에 대해 최소 99.99999999999999%(9 16개) 이상의 내구성을 제공합니다. 자세한 내용은 개념 - 백업 및 복원을 참조하세요.	모든 Azure 연결 지역에서 사용 가능
영역 중복 고가용성	이 서비스는 고가용성 모드로 배포될 수 있습니다. 이 모드에서는 지역 내 2개의 서로 다른 가용성 영역에 주 서버와 대기 서버를 배포합니다. 영역 중복 고가용성은 영역 수준의 오류로부터 데이터를 보호하고, 계획된 및 계획되지 않은 가동 중지 시간 이벤트 중 애플리케이션 가동 중지 시간을 줄이는 데에도 도움이 됩니다. 주 서버의 데이터는 대기 복제본에 동기적으로 복제됩니다. 가동 중지 시간 이벤트 중 데이터베이스 서버가 대기 복제본으로 자동으로 장애 조치(failover)됩니다. 자세한 내용은 개념 - 고가용성을 참조하세요.	범용 및 중요 비즈니스용 컴퓨팅 계층에서 지원됩니다. 여러 영역을 사용할 수 있는 지역에서만 제공됩니다.
프리미엄 파일 공유	데이터베이스 파일은 자동 데이터 복구 기능으로 가용성 영역 내에 저장되는 3개의 복사본으로 데이터 중복성을 제공하는 내구성과 신뢰성이 뛰어난 Azure 프리미엄 파일 공유에 저장됩니다. 자세한 내용은 프리미엄 파일 공유를 참조하세요.	가용성 영역 내에 저장된 데이터

계획된 가동 중지 시간 완화

계획된 유지 관리 시나리오에 따라 가동 중지 시간이 발생할 수 있습니다.

시나리오	처리
컴퓨팅 크기 조정(사용자)	컴퓨팅 크기 조정 작업을 수행할 때는 확장된 컴퓨팅 구성을 사용하여 새 유연한 서버가 프로비전됩니다. 기존 데이터베이스 서버에서는 활성 검사점이 완료될 수 있고 클라이언트 연결이 드레이닝되며 커밋되지 않은 트랜잭션이 취소된 다음, 종료됩니다. 그런 후 스토리지가 새 서버에 연결되고 클라이언트 연결을 수락하기 전 필요에 따라 복구를 수행하는 데이터베이스가 시작됩니다.
새 소프트웨어 배포(Azure)	서비스의 계획된 유지 관리 중에는 새로운 기능 출시 또는 버그 픽스가 자동으로 수행되며, 이러한 작업을 수행할 시간을 예약할 수 있습니다. 자세한 내용은 문서 및 해당 포털을 참조하세요.
부 버전 업그레이드(Azure)	Azure Database for MySQL 유연한 서버는 Azure에서 확인된 부 버전으로 데이터베이스 서버를 자동으로 패치합니다. 이러한 작업은 서비스의 계획된 유지 관리 중에 수행됩니다. 이러한 작업은 몇 초 이내의 짧은 가동 중지 시간 내에 발생하며, 새로운 부 버전으로 데이터베이스 서버가 자동으로 다시 시작됩니다. 자세한 내용은 문서 및 해당 포털을 참조하세요.

유연한 서버가 영역 중복성 고가용성으로 구성되었으면 유연한 서버가 대기 서버에서 먼저 작업을 수행한 후 장애 조치(failover) 없이 주 서버에서 작업을 수행합니다. 자세한 내용은 개념 - 고가용성을 참조하세요.

계획되지 않은 가동 중지 시간 완화

계획되지 않은 가동 중지 시간은 기본 하드웨어 결함, 네트워킹 문제 및 소프트웨어 버그와 같은 예상되지 않은 오류의 결과로 발생할 수 있습니다. 데이터베이스 서버가 예기치 않게 중단되면 HA(고가용성)로 구성된 경우, 대기 복제본이 활성화됩니다. 그렇지 않으면 새 데이터베이스 서버가 자동으로 프로비전됩니다. 계획되지 않은 가동 중지 시간을 방지할 수 없지만 유연한 서버는 사람이 개입하지 않고도 데이터베이스 서버와 스토리지 레이어 모두에서 복구 작업을 자동으로 수행하여 가동 중지 시간을 완화합니다.

예기치 않은 가동 중지 시간: 오류 시나리오 및 서비스 복구

계획되지 않은 오류 시나리오 및 복구 프로세스는 다음과 같습니다.

시나리오	복구 프로세스 [비HA]	복구 프로세스 [HA]
데이터베이스 서버 오류	기본 하드웨어 결함으로 인해 데이터베이스 서버가 가동 중지되면 활성 연결이 삭제되고 모든 전송 중인 트랜잭션이 중단됩니다. Azure에서 데이터베이스 서버를 다시 시작하려고 시도합니다. 성공하면 데이터베이스 복구가 수행됩니다. 다시 시작이 실패하면 다른 실제 노드에서 데이터베이스 서버가 다시 시작되도록 시도됩니다. RTO(복구 시간 목표)는 데이터베이스 서버 시작 프로세스 중 수행해야 하는 큰 트랜잭션 및 복구 작업의 양과 같은 장애가 발생한 시점의 작업을 포함하여 여러 요소들에 따라 달라집니다. 커밋된 트랜잭션에서는 데이터 손실이 발생하지 않을 것으로 예상되므로 RPO는 0이 됩니다. MySQL 데이터베이스를 사용하는 애플리케이션은 삭제된 연결과 실패한 트랜잭션을 검색하고 다시 시도하도록 빌드되어야 합니다. 애플리케이션이 작업을 다시 시도할 때 연결은 새로 생성된 데이터베이스 서버로 전달됩니다. 사용 가능한 다른 옵션은 백업에서 복원됩니다. 연결된 지역에서 PITR 또는 지역 복원을 모두 사용할 수 있습니다. PITR: RTO: 다름, RPO=0sec 지역 복원: RTO: 다름 RPO <1시간. 읽기 복제본을 DR 솔루션으로 사용할 수도 있습니다. 읽기 복제본을 읽기-쓰기로 만드는 복제를 중지(독립 실행형으로 만든 다음 애플리케이션 트래픽을 이 데이터베이스로 리디렉션)할 수 있습니다. 대부분의 경우 RTO는 몇 분이며 RPO < 1시간입니다. RTO 및 RPO는 사이트 간의 대기 시간, 전송되는 데이터의 양, 주 데이터베이스 쓰기 워크로드에 따라 증가할 수 있습니다.	데이터베이스 서버 오류나 복구할 수 없는 오류가 감지되면 대기 데이터베이스 서버가 활성화되어 가동 중지 시간이 줄어듭니다. 자세한 내용은 HA 개념 페이지를 참조하세요. RTO는 60~120초, RPO=0으로 예상됩니다. 참고:복구 프로세스를 위한 옵션[비HA]도 여기에 해당됩니다.
스토리지 오류	디스크 오류 또는 물리적 블록 손상과 같은 스토리지 관련 문제는 애플리케이션에 영향을 주지 않습니다. 데이터가 3개 복사본에 저장되므로 남은 스토리지에서 데이터 복사본이 제공됩니다. 블록 손상은 자동으로 수정됩니다. 데이터 복사본이 손실된 경우 새로운 데이터 복사본이 자동으로 생성됩니다. 드문 경우나 최악의 시나리오에서 모든 복사본이 손상된 경우 지역 복원(연결된 지역)에서 복원을 사용하면 됩니다. RPO는 < 1시간이고 RTO는 달라집니다. 위 설명대로 읽기 복제본을 DR 솔루션으로 사용할 수도 있습니다.	이 시나리오의 경우 옵션은 복구 프로세스 [비 HA]와 동일합니다.
논리적/사용자 오류	실수로 삭제된 테이블 또는 잘못 업데이트된 데이터와 같은 사용자 오류로부터 복구하려면 오류가 발생하기 바로 전의 시간으로 데이터를 복원 및 복구하는 PITR(지정 시간 복구)가 수행됩니다. 삭제된 유연한 서버 리소스는 서버 삭제 시점으로부터 5일 이내에 복구할 수 있습니다. 삭제된 서버를 복원하는 방법에 대한 자세한 내용은 [문서화된 단계](../flexible-server/how-to-restore-dropped-server.md)를 참조하세요. 실수로 삭제되거나 예기치 않은 변경으로부터 배포 후 서버 리소스를 보호하기 위해 관리자는 관리 잠금을 사용할 수 있습니다.	이러한 사용자 오류는 모든 사용자 작업이 대기에도 복제되므로 고가용성으로 보호되지 않습니다. 이 시나리오의 경우 옵션은 복구 프로세스 [비 HA]와 동일합니다.
가용성 영역 오류	드물지만 영역 수준 오류에서 복구하려는 경우 연결된 지역에서 지역 복원을 수행할 수 있습니다. RPO는 <1시간이고 RTO는 달라집니다. 다른 가용성 영역에서 복제본을 만들어 읽기 복제본을 DR 솔루션으로 사용할 수도 있습니다. RTO\RPO는 위에서 자세히 설명한 것과 같습니다.	영역 중복 HA를 사용하면 유연한 서버에서 대기 사이트로 자동 장애 조치(failover)를 수행합니다. 자세한 내용은 HA 개념을 참조하세요. RTO는 60~120초, RPO=0으로 예상됩니다. 사용 가능한 다른 옵션은 백업에서 복원됩니다. 연결된 지역에서 PITR 또는 지역 복원을 모두 사용할 수 있습니다. PITR: RTO: 다름, RPO=0sec 지역 복원: RTO: 다름, RPO <1시간 참고:동일한 영역 HA를 사용하면 옵션은 복구 프로세스 [비 HA]의 옵션과 동일합니다.
지역 오류	드물지만 지역 수준 오류에서 복구하려는 경우 동일한 구독에서 사용할 수 있는 최신 지역 중복 백업을 사용하여 새 서버를 만들어 데이터베이스 복구를 수행하면 최신 데이터를 가져올 수 있습니다. 새로운 유연한 서버가 선택한 지역에 배포됩니다. 복원에 걸리는 시간은 이전 백업 및 복구할 트랜잭션 로그 수에 따라 달라집니다. 대부분의 경우 RPO는 <1시간이고 RTO는 달라집니다.	이 시나리오의 경우 옵션은 복구 프로세스 [비 HA]와 동일합니다.

요구 사항 및 제한 사항

지역 데이터 보존

기본적으로 Azure Database for MySQL 유연한 서버는 배포된 지역 외부로 고객 데이터를 이동하거나 저장하지 않습니다. 그러나 고객은 필요에 따라 다른 지역에 데이터를 저장하기 위해 지역 중복 백업을 사용하거나 지역 간 읽기 복제본을 설정할 수 있습니다.

다음 단계

• 영역 중복 고가용성에 대한 자세한 정보
• 백업 및 복구에 대한 자세한 정보