다음을 통해 공유

Azure Database for MariaDB의 비즈니스 연속성 개요

  • 아티클

Important

Azure Database for MariaDB는 사용 중지될 예정입니다. Azure Database for MySQL로 마이그레이션하는 것이 좋습니다. Azure Database for MySQL로 마이그레이션하는 방법에 대한 자세한 내용은 Azure Database for MariaDB에 대한 새로운 소식을 참조하세요.

이 문서에서는 Azure Database for MariaDB가 비즈니스 연속성 및 재해 복구를 위해 제공하는 기능에 대해 설명합니다. 데이터 손실을 유발하거나 데이터베이스 및 애플리케이션을 사용할 수 없게 될 수 있는 중단 이벤트로부터 복구하는 옵션에 대해 알아봅니다. 사용자 오류 또는 애플리케이션 오류가 데이터 무결성에 영향을 미치거나, Azure 지역에 중단이 발생하거나, 애플리케이션에 유지 관리가 필요한 경우 수행할 작업을 알아봅니다.

비즈니스 연속성을 위한 기능

비즈니스 연속성 계획을 개발할 때 다음 사항을 이해해야 합니다.

  • RTO(복구 시간 목표): 중단 이벤트 후 애플리케이션이 완전히 복구되기까지 허용되는 최대 시간입니다.
  • RPO(복구 지점 목표): 중단 이벤트 후 복구 중 애플리케이션이 손실을 허용할 수 있는 최대 최근 데이터 업데이트 양(시간 간격)입니다.

Azure Database for MariaDB는 지역 복원을 시작할 수 있는 지역 중복 백업, 다른 지역에 읽기 복제본 배포 등의 비즈니스 연속성 및 재해 복구기능을 제공합니다. 각각에 복구 시간과 잠재적 데이터 손실에 대한 각기 다른 특성이 있습니다.

geo-restore를 사용하면 Azure Database for MariaDB는 다른 지역에서 복제된 백업 데이터를 사용하여 새 서버를 만듭니다. 복원 및 복구에 소요되는 전체 시간은 데이터베이스 크기와 복구할 로그 데이터의 양에 따라 달라집니다. 서버를 설정하는 전체 시간은 몇 분에서 몇 시간까지 다릅니다.

읽기 복제본을 사용하면 주 데이터베이스의 트랜잭션 로그가 비동기적으로 복제본으로 스트리밍됩니다. 영역 수준 또는 지역 수준 오류로 인해 주 데이터베이스가 중단되는 경우 복제본에 대한 장애 조치(failover)는 더 짧은 RTO를 제공하고 데이터 손실을 줄입니다.

참고 항목

주 데이터베이스와 복제본 간의 대기 시간은 사이트 간의 대기 시간, 전송될 데이터의 양,(가장 중요한) 주 서버의 쓰기 워크로드에 따라 달라집니다. 쓰기 워크로드가 많으면 상당한 지연이 발생할 수 있습니다.

읽기 복제본에 사용되는 복제의 비동기적 특성으로 인해 읽기 복제본을 고가용성 솔루션으로 간주하지 마세요. 지연이 높을수록 RTO 및 RPO가 높아질 수 있습니다. 읽기 복제본은 최대치 시간과 최대치가 아닌 시간 동안 지연이 더 작게 유지되는 워크로드에 대해서만 고가용성 대안으로 작동할 수 있습니다. 그렇지 않은 경우 읽기 복제본은 읽기 작업이 많은 워크로드 및 재해 복구 시나리오에 대한 실제 읽기 규모를 위한 것입니다.

다음 표에서는 일반적인 워크로드 시나리오에서 RTO 및 RPO를 비교합니다.

기능 Basic 범용 가상 컴퓨터 메모리에 최적화
백업에서 특정 시점 복원 보존 기간 내 모든 복원 지점
RTO 다양함
RPO는 15분 미만입니다.		 보존 기간 내 모든 복원 지점
RTO 다양함
RPO는 15분 미만입니다.		 보존 기간 내 모든 복원 지점
RTO 다양함
RPO는 15분 미만입니다.
지리적으로 복제된 백업에서 지역 복원 지원되지 않음 RTO 다양함
RPO는 24시간보다 큽니다.		 RTO 다양함
RPO는 24시간보다 큽니다.
읽기 복제본 RPO는 분입니다.
RPO는 5분 미만입니다.		 RPO는 분입니다.
RPO는 5분 미만입니다.		 RPO는 분입니다.
RPO는 5분 미만입니다.

RTO와 RPO는 사이트 간 대기 시간, 전송될 데이터 양, 주 데이터베이스의 쓰기 워크로드와 같은 요인에 따라 경우에 따라 훨씬 더 높을 수 있습니다.

사용자 또는 애플리케이션 오류 후 서버 복구

서비스의 백업을 사용하여 다양한 중단 이벤트로부터 서버를 복구할 수 있습니다. 예를 들어 사용자가 실수로 데이터를 삭제할 수도 있고, 의도치 않게 중요한 테이블을 삭제할 수도 있고, 전체 데이터베이스를 삭제할 수도 있습니다. 애플리케이션 결함으로 인해 애플리케이션이 실수로 좋은 데이터를 잘못된 데이터로 덮어쓸 수도 있습니다.

특정 시점 복원을 수행하면 알려진 특정 시점에서 서버의 복사본을 만들 수 있습니다. 이 시점은 서버에 대해 구성한 백업 보존 기간 내에 있어야 합니다. 데이터가 새 서버로 복원된 후에는 원래 서버를 새로 복원된 서버로 바꾸거나 복원된 서버에서 원래 서버로 필요한 데이터를 복사할 수 있습니다.

Important

삭제된 서버는 삭제 후 5일 이내에만 복원할 수 있습니다. 5일 후에는 백업이 삭제됩니다. 서버를 호스팅하는 Azure 구독에서만 데이터베이스 백업에 액세스하고 복원할 수 있습니다. 중단된 서버를 복원하려면 문서화된 단계를 참조하세요. 배포 후 실수로 삭제되거나 예기치 않은 변경으로부터 서버 리소스를 보호하기 위해 관리자는 관리 잠금을 사용할 수 있습니다.

Azure 지역 데이터 센터 중단에서 복구

드문 경우지만 Azure 데이터 센터가 중단될 수 있습니다. 중단이 발생하면 비즈니스 중단이 몇 분만 지속될 수도 있지만 몇 시간 동안 지속될 수도 있습니다.

한 가지 옵션은 데이터 센터 중단이 끝날 때 서버가 온라인 상태가 되기까지 기다리는 것입니다. 데이터 센터에 가동 중단이 발생하면 가동 중단이 얼마나 오래 지속될지 알 수 없습니다. 따라서 이 옵션은 한동안 서버를 오프라인 상태로 둘 수 있는 애플리케이션(예: 개발 환경)에만 작동합니다.

지역 복원

지역 복원 기능은 지역 중복 백업을 사용하여 서버를 복원합니다. 백업은 서버의 페어링된 지역에서 호스팅됩니다. 서버가 호스트되는 지역이 오프라인인 경우에도 이러한 백업에 액세스할 수 있습니다. 이러한 백업에서 다른 지역으로 복원하여 서버를 다시 온라인 상태로 만들 수 있습니다. 백업 및 복원 개념에 대한 문서에서 지역 복원에 대해 자세히 알아봅니다.

Important

지역 복원은 지역 중복 백업 스토리지로 서버를 프로비전한 경우에만 가능합니다. 기존 서버에 대한 로컬 중복 백업에서 지역 중복 백업으로 전환하려면 mysqldump를 사용하여 기존 서버의 백업을 생성해야 합니다. 그런 다음 지역 중복 백업으로 구성된 새로 만들어진 서버로 복원합니다.

지역 간 읽기 복제본

지역 간 읽기 복제본을 사용하여 비즈니스 연속성 및 재해 복구 계획을 향상할 수 있습니다. 읽기 복제본은 MySQL의 이진 파일 로그 복제 기술을 통해 비동기식으로 업데이트됩니다. 읽기 복제본 개념에 대한 문서에서 읽기 복제본, 사용 가능한 지역 및 장애 조치(failover) 방법에 대해 자세히 알아봅니다.

FAQ

Azure Database for MariaDB는 어디에 고객 데이터를 저장하나요?

기본적으로 Azure Database for MariaDB는 배포된 지역 외부로 고객 데이터를 이동하거나 저장하지 않습니다. 그러나 선택적으로 지역 중복 백업을 사용하도록 설정하거나 다른 지역에 데이터를 저장하기 위해 지역 간 읽기 복제본을 만들도록 선택할 수 있습니다.

다음 단계