Azure Database for MySQL - 유연한 서버의 백업 및 복원
적용 대상: 
Azure Database for MySQL - 유연한 서버
Azure Database for MySQL 유연한 서버는 자동으로 서버 백업을 만들고 지역 내 로컬 중복 스토리지에 안전하게 저장합니다. 백업을 사용하여 특정 시점의 서버를 복원할 수 있습니다. 백업 및 복원은 실수로 인한 손상이나 삭제로부터 데이터를 보호하므로 비즈니스 연속성 전략의 필수적인 부분입니다.
Backup 개요
Azure Database for MySQL 유연한 서버는 두 가지 유형의 백업을 지원하여 중요 비즈니스용 데이터의 백업을 유지 관리하기 위한 향상된 유연성을 제공합니다.
자동화된 백업
Azure Database for MySQL 유연한 서버는 데이터 파일의 스냅샷 백업을 사용하여 로컬 중복 스토리지에 저장합니다. 또한 서버는 트랜잭션 로그 백업을 수행하고 로컬 중복 스토리지에도 저장합니다. 이러한 백업을 사용하면 서버를 구성된 백업 보존 기간 내의 특정 시점으로 복원할 수 있습니다. 기본 백업 보존 기간은 7일입니다. 필요에 따라 데이터베이스 백업을 1-35일로 구성할 수 있습니다. 모든 백업은 저장된 미사용 데이터에 대한 AES 256비트 암호화를 사용하여 암호화됩니다.
주문형 백업
또한 Azure Database for MySQL 유연한 서버를 사용하면 서비스에서 수행한 자동화된 백업 외에도 프로덕션 워크로드의 주문형 백업을 트리거하고 서버의 백업 보존 정책에 따라 저장할 수 있습니다. 이러한 백업을 가장 빠른 복원 지점으로 사용하여 특정 시점 복원을 수행하여 복원 시간을 최대 90%까지 줄일 수 있습니다. 기본 백업 보존 기간은 7일입니다. 필요에 따라 데이터베이스 백업을 1-35일로 구성할 수 있습니다. 포털에서 총 50개의 주문형 백업을 트리거할 수 있습니다. 모든 백업은 저장된 미사용 데이터에 대한 AES 256비트 암호화를 사용하여 암호화됩니다.
이러한 백업 파일은 내보낼 수 없습니다. 백업은 Azure Database for MySQL 유연한 서버의 복원 작업에만 사용할 수 있습니다. MySQL 클라이언트에서 mysqldump를 사용하여 데이터베이스를 복사할 수도 있습니다.
Backup 주기
유연한 서버의 백업은 스냅샷 기반입니다. 첫 번째 전체 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 스냅샷 백업은 매일 한 번 수행됩니다. 트랜잭션 로그 백업은 5분마다 발생합니다. 예약된 백업이 실패하면 백업 서비스는 성공적인 백업이 수행될 때까지 20분마다 백업을 시도합니다. 이러한 백업 실패는 서버 인스턴스의 과도한 트랜잭션 프로덕션 로드로 인해 발생할 수 있습니다.
참고 항목
- 서버에서 트랜잭션 부하가 높아 더 크고 빠르게 증가하는 binlog 파일이 발생하는 경우 백업 서비스는 이러한 백업을 사용하여 안정적이고 빠르게 복원할 수 있도록 하루에 여러 백업을 수행합니다.
- 5.7 서버의 경우 장기 실행/대규모 트랜잭션은 성공적인 일일 백업에 필요한 전역 인스턴스 수준 잠금 획득을 방지할 수 있습니다. 이러한 시나리오에서는 매일 백업이 실패할 수 있습니다. 이 문제를 해결하려면 장기 실행 트랜잭션을 종료하거나 서버를 다시 시작합니다. 보다 원활한 작업을 위해 주 버전 업그레이드를 사용하여 MySQL 5.7 서버를 버전 8.0으로 업그레이드하는 것이 좋습니다.
백업 중복 옵션
Azure Database for MySQL 유연한 서버는 일시적인 하드웨어 오류, 네트워크 또는 정전, 대규모 자연 재해를 포함하여 계획되거나 계획되지 않은 이벤트로부터 데이터를 보호할 수 있도록 백업의 여러 복사본을 저장합니다. Azure Database for MySQL 유연한 서버는 기본, 범용 및 중요 비즈니스용 계층에서 로컬 중복, 영역 중복 또는 지역 중복 백업 스토리지 중에서 선택할 수 있는 유연성을 제공합니다. 기본적으로 Azure Database for MySQL 유연한 서버 백업 스토리지는 동일한 영역 HA(고가용성)가 있거나 고가용성 구성이 없는 서버에 대해 로컬로 중복되고 영역 중복 HA 구성이 있는 서버에 대해 영역 중복입니다.
백업 중복성은 장애가 발생하더라도 데이터베이스가 가용성 및 내구성 대상을 충족하도록 보장하고 Azure Database for MySQL 유연한 서버는 사용자에게 세 가지 옵션을 확장합니다.
로컬 중복 백업 스토리지: 백업이 로컬 중복 백업 스토리지에 저장되면 여러 백업 복사본이 동일한 데이터 센터에 저장됩니다. 이 옵션은 서버 랙 및 드라이브 오류로부터 데이터를 보호합니다. 또한 이는 지정된 연도 동안 백업 개체의 최소 99.999999999%(11개의 9) 내구성을 제공합니다. 기본적으로 동일한 영역 HA(고가용성)가 있거나 고가용성 구성이 없는 서버의 백업 스토리지는 로컬 중복으로 설정됩니다.
영역 중복 백업 스토리지 : 백업이 영역 중복 백업 스토리지에 저장되면 서버가 호스트되는 가용성 영역 내에 여러 복사본이 저장되고 동일한 지역의 다른 가용성 영역으로 복제됩니다. 이 옵션은 고가용성이 필요한 시나리오 또는 데이터 보존 요구 사항을 충족하기 위해 국가/지역 내로 데이터 복제를 제한하는 데 활용할 수 있습니다. 또한 이는 지정된 연도 동안 백업 개체의 최소 99.9999999999%(12개의 9) 내구성을 제공합니다. 영역 중복 백업 스토리지를 보장하기 위해 서버를 만들 때 영역 중복 고가용성 옵션을 선택할 수 있습니다. 서버에 대한 고가용성은 만들기 후 사용하지 않도록 설정할 수 있지만 백업 스토리지는 영역 중복으로 유지됩니다.
지역 중복 백업 스토리지: 백업이 지역 중복 백업 스토리지에 저장되면 여러 복사본이 서버가 호스팅되는 지역 내에 저장될 뿐만 아니라 지리적 쌍을 이루는 지역에도 복제됩니다. 이렇게 하면 재해 발생 시 다른 지역에서 서버를 복원하는 데 더 효율적인 보호와 기능을 제공합니다. 또한 이는 지정된 연도 동안 백업 개체의 최소 99.99999999999999%(16개의 9) 내구성을 제공합니다. 지역 중복 백업 스토리지를 보장하기 위해 서버를 만들 때 지역 중복 옵션을 사용하도록 설정할 수 있습니다. 또한 서버 만들기 후 로컬 중복 스토리지에서 지역 중복 스토리지로 이동할 수 있습니다. 지리적 중복성은 Azure 쌍을 이루는 지역에서 호스팅되는 서버에 대해 지원됩니다.
참고 항목
영역 중복성을 지원하는 영역 중복 고가용성은 현재 시간 만들기 작업으로만 제공됩니다. 현재 영역 중복 고가용성 서버의 경우 지역 중복은 서버 만들기 시에만 사용/사용하지 않도록 설정할 수 있습니다.
다른 백업 스토리지 옵션에서 지역 중복 백업 스토리지로 이동
다음 제안된 방법을 사용하여 기존 백업 스토리지를 지역 중복 스토리지로 이동할 수 있습니다.
로컬 중복에서 지역 중복 백업 스토리지로 이동 - 로컬 중복 스토리지에서 지역 중복 스토리지로 백업 스토리지를 이동하기 위해 Azure Portal에서 컴퓨팅 + 스토리지 서버 구성을 변경하여 로컬 중복 원본 서버에 대해 지역 중복을 사용하도록 설정할 수 있습니다. 동일한 영역 중복 HA 서버는 기본 백업 스토리지가 로컬 중복 서버로 동일한 방식으로 지역 중복 서버로 복원될 수도 있습니다.
영역 중복에서 지역 중복 백업 스토리지로 이동 - Azure Database for MySQL 유연한 서버는 서버 프로비전 이후의 컴퓨팅 + 스토리지 설정 변경을 통한 영역 중복 스토리지에서 지역 중복 스토리지로의 변환을 지원하지 않습니다. 영역 중복 스토리지에서 지역 중복 스토리지로 백업 스토리지를 이동하는 데에는 두 가지 옵션이 있으며, a) PITR(지정 시간 복구)을 사용하면 원하는 구성으로 서버를 복원합니다. b) 새로 서버를 만들어 원하는 대로 구성한 다음 덤프 및 복원을 사용해 데이터를 마이그레이션합니다.
백업 보존
백업은 서버의 백업 보존 기간에 따라 보존됩니다. 1-35일의 보존 기간을 선택할 수 있고 기본 보존 기간은 7일입니다. 서버 생성 도중이나 Azure Portal을 사용하여 나중에 백업 구성을 업데이트하여 보존 기간을 설정할 수 있습니다.
백업 보존 기간은 사용 가능한 백업을 기반으로 하기 때문에 특정 시점 복원 작업을 수행할 수 있는 시간을 제어합니다. 백업 보존 기간은 복원 관점에서 복구 기간으로 취급될 수도 있습니다. 백업 보존 기간 내에 특정 시점 복원을 수행하기 위해 필요한 모든 백업이 백업 스토리지에 보존됩니다. 예를 들어 백업 보존 기간이 7일로 설정되었으면 복구 기간은 최근 7일로 간주됩니다. 이 시나리오에서는 최근 7일 동안 서버 복원에 필요한 모든 백업이 보존됩니다. 7일의 백업 보존 기간을 사용하는 경우 데이터베이스 스냅샷 및 트랜잭션 로그 백업은 마지막 8일 동안(기간 1일 전) 저장됩니다.
백업 스토리지 비용
Azure Database for MySQL 유연한 서버는 추가 비용 없이 최대 100%의 프로비전된 서버 스토리지를 백업 스토리지로 제공합니다. 사용되는 모든 추가 백업 스토리지는 매월 GB 단위로 청구됩니다. 예를 들어 250GB 스토리지 서버를 프로비전한 경우 서버 백업에 250GB의 스토리지를 추가 비용 없이 이용할 수 있습니다. 매일 백업 사용량이 25GB이면 최대 10일 동안 체험용 백업 스토리지를 사용할 수 있습니다. 250GB를 초과하여 백업에 소비된 스토리지는 가격 책정 모델에 따라 비용이 청구됩니다.
Azure Portal에서 제공되는 Azure Monitor의 사용된 백업 스토리지 메트릭을 사용하여 서버에서 사용된 백업 스토리지를 모니터링할 수 있습니다. 사용된 백업 스토리지 메트릭은 서버에 대해 설정된 백업 보존 기간에 따라 유지되는 모든 데이터베이스 백업 및 로그 백업에서 사용하는 스토리지의 합계를 나타냅니다. 서버에서 과도한 트랜잭션 작업을 수행하면 전체 데이터베이스 크기에 관계없이 백업 스토리지 사용량이 증가할 수 있습니다. 지역 중복 서버에 사용되는 백업 스토리지는 로컬 중복 서버의 두 배입니다.
백업 스토리지 비용을 제어하는 기본적인 방법은 적절한 백업 보존 기간을 설정하는 것입니다. 1-35일 사이의 보존 기간을 선택할 수 있습니다.
Important
영역 중복 고가용성 구성으로 구성된 데이터베이스 서버에서의 백업은 스냅샷 백업의 경우 오버헤드가 최소한이므로 주 데이터베이스 서버에서 수행됩니다.
사용 가능한 전체 백업 보기
Azure Portal의 백업 및 복원 블레이드는 특정 시점에 사용할 수 있는 전체 백업의 전체 목록을 제공합니다. 여기에는 자동화된 백업과 주문형 백업이 포함됩니다. 이 블레이드를 사용하여 서버의 보존 기간 내에 사용 가능한 모든 전체 백업의 완료 타임스탬프를 보고 이러한 전체 백업을 사용하여 복원 작업을 수행할 수 있습니다. 사용 가능한 백업 목록에는 보존 기간 내의 모든 완전 백업, 성공적인 완료를 나타내는 타임스탬프, 백업이 보존되는 기간을 나타내는 타임스탬프 및 복원 작업이 포함됩니다.
복원
Azure Database for MySQL 유연한 서버에서 복원을 수행하면 원래 서버의 백업에서 새 서버가 만들어집니다. 사용할 수 있는 두 가지 유형의 복원이 있습니다.
- 특정 시점 복원: 백업 중복 옵션을 통해 사용할 수 있으며, 새 서버를 원본 서버와 동일한 지역에 만듭니다.
- 지역 복원: 지역 중복 스토리지용으로 서버를 구성한 경우에만 사용할 수 있으며, 지역 쌍을 이루는 지역 또는 유연한 서버를 사용할 수 있는 다른 Azure 지원 지역으로 서버를 복원할 수 있습니다.
서버 복구의 예상 시간은 여러 요인에 따라 달라집니다.
- 데이터베이스의 크기
- 관련된 트랜잭션 로그의 수
- 복원 지점으로 복구하기 위해 재생해야 하는 작업의 양
- 다른 지역으로 복원되는 경우의 네트워크 대역폭
- 대상 지역에서 처리되는 동시 복원 요청 개수
- 데이터베이스에 있는 테이블에 기본 키가 있는지 여부입니다. 빠른 복구를 위해서는 데이터베이스에서 모든 테이블에 기본 키를 추가하는 것이 좋습니다.
참고 항목
고가용성 사용 서버는 특정 시점 복원 및 지역 복원 모두에 대한 복원 후에 비HA(고가용성 사용 안 함)가 됩니다.
특정 시점 복원
Azure Database for MySQL 유연한 서버에서 특정 시점 복원을 수행하면 원본 서버와 동일한 지역에 있는 유연한 서버의 백업에서 새 서버가 만들어집니다. 이 경우 컴퓨팅 계층, vCore 수, 스토리지 크기, 백업 보존 기간 및 백업 중복 옵션에 대한 원래 서버의 구성으로 만들어집니다. 또한 가상 네트워크 및 방화벽과 같은 태그와 설정은 원본 서버에서 상속됩니다. 복원이 완료된 후 복원된 서버의 컴퓨팅 및 스토리지 계층, 구성 및 보안 설정을 변경할 수 있습니다.
참고 항목
복원 작업 후 기본값으로 재설정되는(그리고 주 서버에서 복사되지 않는) 두 개의 서버 매개변수가 있습니다.
- time_zone - 이 값은 기본값 SYSTEM으로 설정됩니다.
- event_scheduler - MySQL 버전 5.7 서버의 경우 백업이 시작될 때 서버 매개 변수
event_scheduler가 자동으로 'OFF'로 설정되고 백업이 성공적으로 완료된 후 서버 매개 변수event_scheduler가 'ON'으로 돌아갑니다. Azure Database for MySQL - 유연한 서버용 MySQL 버전 8.0에서는 백업 중에 event_scheduler 영향을 받지 않습니다. 보다 원활한 작업을 위해 주 버전 업그레이드를 사용하여 MySQL 5.7 서버를 버전 8.0으로 업그레이드하는 것이 좋습니다.
특정 시점 복원은 여러 시나리오에서 유용합니다. 몇 가지 일반적인 사용 사례는 다음과 같습니다.
- 사용자가 데이터베이스의 데이터를 실수로 삭제하는 경우
- 사용자가 중요한 테이블 또는 데이터베이스를 삭제
- 사용자 애플리케이션 결함으로 인해 실수로 적절한 데이터를 잘못된 데이터로 덮어쓸 수도 있습니다.
Azure Portal을 통해 최신 복원 지점, 사용자 지정 복원 지점 및 가장 빠른 복원 지점(전체 백업을 사용한 복원) 중에서 선택할 수 있습니다.
- 최신 복원 지점: 최신 복원 지점 옵션을 사용하면 복원 작업이 트리거되었을 때의 타임스탬프로 서버를 복원할 수 있습니다. 이 옵션은 서버를 가장 많이 업데이트된 상태로 신속하게 복원하는 데 유용합니다.
- 사용자 지정 복원 지점:이 옵션을 사용하면 서버에 대해 정의된 보존 기간 내의 시점을 선택할 수 있습니다. 이 옵션은 사용자 오류로부터 복구하기 위해 정확한 시점에 서버를 복원하는 데 유용합니다.
- 가장 빠른 복원 지점: 이 옵션을 사용하면 서버에 대해 정의된 보존 기간 내에서 지정된 날짜에 가능한 가장 빠른 시간에 서버를 복원할 수 있습니다. 전체 백업이 완료된 복원 지점을 선택하면 가장 빠른 복원이 가능합니다. 이 복원 작업은 전체 스냅샷 백업을 복원할 뿐이며 로그 복원 또는 복구를 보증하지 않으므로 속도가 빠릅니다. 성공적인 복원 작업을 위해 가장 이른 복원 지점보다 큰 전체 백업 타임스탬프를 선택하는 것이 좋습니다.
예상 복구 시간은 데이터베이스 크기, 트랜잭션 로그 백업 크기, SKU의 컴퓨팅 크기, 복원 시간까지 포함하여 여러 가지 요인에 따라 달라집니다. 트랜잭션 로그 복구는 복원 프로세스에서 가장 시간이 많이 소요되는 부분입니다. 복원 시간이 스냅샷 백업 일정에 더 가깝게 선택된 경우 트랜잭션 로그 애플리케이션이 최소한이므로 복원 작업이 더 빠릅니다. 서버에 대한 정확한 복구 시간을 추정하려면 환경별 변수가 너무 많기 때문에 사용자의 환경에서 테스트하는 것이 좋습니다.
Important
영역 중복 고가용성을 사용하여 구성된 Azure Database for MySQL 유연한 서버 인스턴스를 복원하는 경우 복원된 서버는 주 서버와 동일한 지역 및 영역에 구성되고 비 HA 모드에서 단일 서버로 배포됩니다. 유연한 서버에 대해서는 영역 중복 고가용성을 참조하세요.
Important
삭제된 Azure Database for MySQL 유연한 서버 리소스는 서버 삭제 시점으로부터 5일 이내에 복구할 수 있습니다. 삭제된 서버를 복원하는 방법에 대한 자세한 안내는 문서화된 단계를 참조합니다. 배포 후에 실수로 인한 삭제 또는 예기치 않은 변경에서 서버 리소스를 보호하려면 관리자는 관리 잠금을 활용할 수 있습니다.
지역 복원
지역 중복 백업용 서버를 구성했거나 기타 Azure Database for MySQL 유연한 서버를 사용할 수 있는 Azure 지원 지역용 서버를 구성한 경우, 서버의 지역 쌍을 이루는 곳으로서 서비스를 사용할 수 있는 곳에 서버를 복원할 수 있습니다. Brazil South, USGov Virginia, West US 3)을 제외한, 쌍을 이루지 않는 Azure 지원 지역에 복원하는 기능은 ‘유니버설 지역 복원’으로 알려져 있습니다.
지역 복원은 서버가 호스팅되는 지역에 사고가 발생하여 서버를 사용할 수 없는 경우에 대비한 기본 복구 옵션입니다. 지역에서 발생한 대규모 사고로 인해 데이터베이스 애플리케이션을 사용할 수 없는 경우 지역 중복 백업에서 다른 지역에 있는 서버로 서버를 복원할 수 있습니다. 지리적 복원에는 서버의 최신 백업이 활용됩니다. 백업이 수행되는 시점과 다른 지역에 복제하는 시점 사이에는 지연이 있습니다. 이렇게 지원되는 경우는 최대 1시간이므로 재해가 발생한 경우 데이터 손실은 최대 1시간 동안 일어날 수 있습니다.
Azure CLI를 활용하여 중지된 서버에서 지역 복원을 수행할 수도 있습니다. Azure CLI를 사용하여 서버를 지리적으로 복원하는 방법에 대해 자세히 알아보려면 Azure CLI로 Azure Database for MySQL 유연한 서버 복원을 참조하세요.
예상 복구 시간은 데이터베이스 크기, 트랜잭션 로그 크기, 네트워크 대역폭 및 동일한 지역에서 동시에 복구되는 데이터베이스의 총 수를 포함한 여러 요소에 따라 달라집니다.
참고 항목
영역 중복 고가용성을 사용하여 구성된 Azure Database for MySQL 유연한 서버 인스턴스를 지역 복원하는 경우 복원된 서버는 주 서버와 지역 쌍이 되는 지역 및 동일 영역에 구성되고 비 HA 모드에서 단일 Azure Database for MySQL 서버 인스턴스로 배포됩니다. Azure Database for MySQL 유연한 서버의 영역 중복 고가용성을 참조합니다.
Important
주 지역이 다운되면 주 지역에서 스토리지를 프로비전할 수 없기 때문에 각 지역 쌍을 이루는 지역에서 지역 중복 서버를 만들 수 없습니다. 주 지역이 지역 쌍 지역에서 지역 중복 서버를 프로비전할 때까지 기다려야 합니다. 주 지역이 다운된 상태에서도 복원 포털 환경의 컴퓨팅 + 스토리지 서버 구성 설정에서 지역 중복 옵션을 사용하지 않도록 설정하여 원본 서버를 지역 쌍 지역으로 지역 복원하고 비즈니스 연속성을 보장하기 위해 로컬 중복 서버로 복원할 수 있습니다.
복원 후 작업 수행
최신 복원 지점 또는 사용자 지정 복원 지점 복구 메커니즘에서 복원한 후에 다음 작업을 수행하여 사용자 및 애플리케이션이 다시 백업 및 실행되도록 해야 합니다.
- 새 서버가 원래 서버를 교체하기 위한 것이라면 클라이언트와 클라이언트 애플리케이션을 새 서버로 리디렉션합니다.
- 사용자가 연결할 수 있도록 적절한 서버 수준 방화벽 및 가상 네트워크 규칙이 설정되어 있는지 확인합니다.
- 적절한 로그인 및 데이터베이스 수준 권한이 있는지 확인합니다.
- 필요에 따라 경고를 구성합니다.
장기 보존(미리 보기)
Azure Backup 및 Azure Database for MySQL 유연한 서버 서비스는 최대 10년 동안 백업을 보존하는 Azure Database for MySQL 유연한 서버 인스턴스를 위한 엔터프라이즈급 장기 백업 솔루션을 빌드했습니다. 장기 보존은 독립적으로 사용하거나 최대 35일 보존을 제공하는 Azure Database for MySQL 유연한 서버에서 제공하는 자동화된 백업 솔루션과 함께 사용할 수 있습니다. 자동 백업은 특히 최신 백업에서 복원하려는 경우 작업 복원에 적합한 스냅샷 백업입니다. 장기 백업은 준수 요구 사항 및 감사 요구 사항을 충족하는 데 도움이 됩니다. 이 솔루션은 장기 보존 외에도 다음과 같은 기능을 제공합니다.
- 고객이 제어하는 예약 및 주문형 백업
- 백업 센터라는 단일 창에서 서버, 리소스 그룹, 위치, 구독 및 테넌트 전반에 걸쳐 모든 백업 관련 작업 및 작업을 관리하고 모니터링합니다.
- 별도의 보안 및 장애 도메인에 백업이 저장됩니다. 원본 서버 또는 구독이 손상된 경우 백업은 Backup 자격 증명 모음(Azure Backup 관리형 스토리지 계정)에서 안전하게 유지됩니다.
제한 사항 및 고려 사항
- 미리 보기에서 LTR 복원은 현재 스토리지 계정에 RestoreasFiles로 제공됩니다. RestoreasServer 기능은 향후 추가될 예정입니다.
- Azure CLI를 통한 LTR 만들기 및 관리 지원은 현재 지원되지 않습니다.
장기 백업 수행에 대한 자세한 내용을 보려면 방법 가이드를 참조하세요.
주문형 백업 및 내보내기(미리 보기)
Azure Database for MySQL 유연한 서버는 이제 서버의 주문형 실시간 실제 백업을 트리거하고 이를 Azure Storage 계정(Azure Blob Storage)으로 내보내는 기능을 제공합니다. 내보낸 백업은 데이터 복구, 마이그레이션 및 중복성에 사용될 수 있습니다. 이렇게 내보낸 실제 백업 파일을 사용하면 온-프레미스 MySQL 서버로 다시 복원하여 조직의 감사/준수/보관 요구 사항을 충족할 수 있습니다. 이 기능은 현재 공개 미리 보기 상태이며 퍼블릭 클라우드 지역에서만 사용할 수 있습니다.
내보내기 백업에 대한 자세한 내용은 방법 가이드를 참조하세요.
FAQ(질문과 대답)
백업 관련 질문
서버 백업 방법은 무엇인가요?
기본적으로 Azure Database for MySQL 유연한 서버에서는 기본 7일 보존 기간으로 전체 서버(생성된 모든 데이터베이스 포함)의 자동화된 백업을 사용하도록 설정합니다. 주문형 백업 기능을 사용하여 수동 백업을 트리거할 수도 있습니다. 수동으로 백업을 수행하는 다른 방법은 여기에 설명된 mysqldump 또는 여기에 설명된 mydumper와 같은 커뮤니티 도구를 사용하는 것입니다. Azure Database for MySQL 유연한 서버 인스턴스를 Blob Storage에 백업하려면 기술 커뮤니티 블로그 Blob Storage에 Azure Database for MySQL 유연한 서버 백업을 참조하세요.
장기간 보존되도록 자동 백업을 구성할 수 있나요?
아니요, 현재 자동 백업 보존 기간은 최대 35일까지만 지원됩니다. 수동 백업을 수행하고 장기 보존 요구 사항에 사용할 수 있습니다.
내 서버의 백업 창은 무엇인가요? 사용자 지정할 수 있나요?
첫 번째 전체 스냅샷 백업은 서버를 만든 직후에 예약됩니다. 스냅샷 백업은 매일 한 번 수행됩니다. 트랜잭션 로그 백업은 5분마다 발생합니다. 백업 기간은 기본적으로 Azure에서 관리하며 사용자 지정할 수 없습니다.
내 백업이 암호화되나요?
쿼리 실행 중에 생성된 모든 Azure Database for MySQL 유연한 서버 데이터, 백업, 임시 파일은 AES 256비트 암호화를 사용하여 암호화됩니다. 스토리지 암호화는 항상 켜져 있고 해제할 수 없습니다.
단일/일부 데이터베이스를 복원할 수 있나요?
단일/일부 데이터베이스 또는 테이블 복원은 지원되지 않습니다. 특정 데이터베이스를 복원하려는 경우 특정 시점 복원을 수행한 다음 필요한 테이블 또는 데이터베이스를 추출합니다.
백업 기간 동안 내 서버를 사용할 수 있나요?
예. 백업은 온라인 작업이며 스냅샷 기반입니다. 스냅샷 작업은 몇 초밖에 걸리지 않으며 프로덕션 워크로드를 방해하지 않아 서버의 고가용성을 보장합니다.
서버의 유지 관리 기간을 설정할 때 백업 기간을 고려해야 하나요?
아니요, 백업은 관리되는 서비스의 일부로 내부적으로 트리거되며 관리되는 유지 관리 기간과 관련이 없습니다.
자동 백업은 어디에 저장되며 보존은 어떻게 관리하나요?
Azure Database for MySQL 유연한 서버는 자동으로 서버 백업을 만들어 사용자가 구성한 로컬 중복 스토리지 또는 지역 중복 스토리지에 저장합니다. 이러한 백업 파일을 내보낼 수 없습니다. 기본 백업 보존 기간은 7일입니다. 필요에 따라 데이터베이스 백업을 1-35일로 구성할 수 있습니다.
내 백업의 유효성을 검사하려면 어떻게 해야 하나요?
성공적으로 완료된 백업의 가용성에 대한 유효성을 검사하는 가장 좋은 방법은 백업 및 복원 블레이드에서 보존 기간 내에 수행된 완전 자동화된 백업을 보는 것입니다. 백업이 실패하면 사용 가능한 백업 목록에 표시되지 않으며 백업 서비스는 백업이 제대로 수행될 때까지 20분마다 백업을 시도합니다. 이러한 백업 실패는 서버의 과도한 트랜잭션 프로덕션 로드로 인해 발생합니다.
백업 사용량은 어디에서 확인할 수 있나요?
Azure Portal의 모니터링 탭 - 메트릭 섹션에서 총 백업 사용량을 모니터링하는 데 도움이 되는 사용된 백업 스토리지 메트릭을 찾을 수 있습니다.
서버를 삭제하면 백업은 어떻게 되나요?
서버를 삭제하면 해당 서버에 속한 모든 백업도 삭제되고 복구할 수 없습니다. 실수로 삭제되거나 예기치 않은 변경으로부터 배포 후 서버 리소스를 보호하기 위해 관리자는 관리 잠금을 사용할 수 있습니다.
서버를 복원하면 백업은 어떻게 되나요?
서버를 복원하는 경우 항상 원본 서버의 백업을 사용하여 복원된 완전히 새로운 서버가 생성됩니다. 원래 서버의 기존 백업은 새로 복원된 서버로 복사되지 않으며 원래 서버에 유지됩니다. 그러나 새로 만든 서버의 경우 첫 번째 스냅샷 백업이 서버 생성 직후에 예약되며, 서비스는 구성된 서버 보존 기간에 따라 매일 자동화된 백업을 만들고 저장합니다.
백업 사용 요금은 어떻게 청구되나요?
Azure Database for MySQL 유연한 서버는 추가 비용 없이 최대 100%의 프로비전된 서버 스토리지를 백업 스토리지로 제공합니다. 사용된 추가 백업 스토리지는 가격 책정 모델에 따라 매월 GB 단위로 청구됩니다. 백업 스토리지 청구는 또한 선택한 백업 보존 기간과 직접 사용되는 총 백업 스토리지에 영향을 미치는 서버의 트랜잭션 작업과는 별도로 선택된 백업 중복성 옵션에 의해 결정됩니다.
중지된 서버의 백업은 어떻게 보존되나요?
중지된 서버에 대해 새 백업은 수행되지 않습니다. 서버를 중지할 때의 모든 이전 백업(보존 기간 내)은 활성 서버에 대한 백업 보존이 백업 보존 기간에 의해 관리되는 이후 서버가 다시 시작될 때까지 보존됩니다.
중지된 서버의 백업 비용은 어떻게 청구되나요?
서버 인스턴스가 중지되는 동안 프로비저닝된 스토리지(프로비저닝된 IOPS 포함) 및 백업 스토리지(지정된 보존 기간 내에 저장된 백업)에 대해 요금이 부과됩니다. 무료 백업 스토리지는 프로비저닝된 데이터베이스의 크기로 제한되며 활성 서버에만 적용됩니다.
내 백업 데이터는 어떻게 보호하나요?
Azure Database for MySQL 유연한 서버는 구성된 보존 기간 동안 복구 지점 손실로 이어질 가능성이 있는 작업을 차단하여 백업 데이터를 보호합니다. 보존 기간 동안 수행된 백업은 복원을 위해서만 읽을 수 있으며 보존 기간이 지나면 삭제됩니다. 또한 Azure Database for MySQL 유연한 서버의 모든 백업은 미사용 저장 데이터에 AES 256비트 암호화를 사용하여 암호화됩니다.
PITR(지정 시간 복구) 작업은 IOPS 사용량에 어떤 영향을 주나요?
Azure Database for MySQL - 유연한 서버에서 PITR 작업을 수행하는 동안에는 서버가 새로 생성되고 데이터는 원본 서버의 스토리지에서 새 서버의 스토리지로 복사됩니다. 이 프로세스를 수행하면 원본 서버에서 IOPS 사용량이 증가합니다. 이러한 IOPS 사용량 증가는 일반적인 상황이며 원본 서버 또는 PITR 작업과 관련된 문제를 의미하지 않습니다. PITR 작업이 완료되면 원본 서버의 IOPS 사용량이 일반적인 수준으로 돌아갑니다.
복원 관련 질문
서버를 복원하려면 어떻게 해야 하나요? Azure Portal은 사용자가 최신 또는 사용자 지정 복원 지점으로 복원할 수 있도록 모든 서버에 대해 특정 시점 복원을 지원합니다. mysqldump/myDumper가 수행한 백업에서 서버를 수동으로 복원하려면 myLoader를 사용하여 데이터베이스 복원을 참조하세요.
복원에 시간이 오래 걸리는 이유는 무엇인가요?
서버 복구의 예상 시간은 여러 요인에 따라 달라집니다.
- 데이터베이스의 크기. 복구 프로세스의 일부로 데이터베이스는 마지막 물리적 백업에서 하이드레이션되어야 하므로 복구하는 데 걸리는 시간은 데이터베이스 크기에 비례합니다.
- 복구를 위해 다시 재생해야 하는 트랜잭션 활동의 활성 부분입니다. 마지막으로 성공한 검사점의 추가 트랜잭션 활동에 따라 복구 시간이 더 오래 걸릴 수 있습니다.
- 다른 지역으로 복원되는 경우의 네트워크 대역폭
- 대상 지역에서 처리되는 동시 복원 요청의 수
- 데이터베이스에 있는 테이블에 기본 키가 있는지 여부입니다. 빠른 복구를 위해서는 데이터베이스에서 모든 테이블에 기본 키를 추가하는 것이 좋습니다.
세션 수준 데이터베이스 변수를 수정하면 복원에 영향을 주나요?
MySQL 클라이언트 세션에서 세션 수준 변수를 수정하고 DML 문을 실행하면 이러한 수정 내용이 백업 및 복원 작업에 사용되는 이진 로그에 기록되지 않으므로 PITR(특정 시점 복원) 작업에 영향을 줄 수 있습니다. 예를 들어 foreign_key_checks는 외래 키 제약 조건을 위반하는 DML 문을 실행하기 위해 사용하지 않도록 설정하면 PITR(특정 시점 복원) 오류가 발생하는 세션 수준 변수 중 하나입니다. 이러한 시나리오를 해결하는 유일한 방법은 설정된 시간보다 이전인 PITR 시간을 선택하여 foreign_key_checks를 사용하지 않도록 하는 것입니다. 성공적인 PITR 작업을 위해 세션 변수를 수정하지 않는 것이 좋습니다.
다음 단계
- 비즈니스 연속성에 대해 알아보기
- 영역 중복 고가용성에 대한 자세한 정보
- 백업 및 복구에 대한 자세한 정보