다음을 통해 공유

고가용성 및 재해 복구 체크리스트 - Azure SQL 데이터베이스

  • 아티클

적용 대상: Azure SQL Database

Azure SQL 데이터베이스 서비스는 모든 데이터베이스가 온라인 상태이고 정상이며 게시된 SLA를 지원하기 위해 지속적인 노력을 자동 보장합니다.

이 가이드에서는 가용성을 극대화하고, 복구를 보장하고, Azure 중단에 대비하기 위해 수행할 수 있는 사전 대응 단계에 대한 자세한 검토를 제공합니다. 이 지침은 Azure SQL Database의 모든 구매 모델 및 서비스 계층에 적용됩니다.

가용성 검사 목록

가용성을 최대화하기 위한 권장 구성은 다음과 같습니다.

  • 일시적 오류를 처리하도록 애플리케이션에 재시도 논리를 통합합니다.
  • 유지 관리 기간을 사용하여 중요한 유지 관리 이벤트를 예측할 수 있고 업무 중단을 줄일 수 있습니다.
  • 수동으로 장애 조치(failover)를 트리거하여 응용 프로그램 장애 복원력을 테스트하여 복원력이 실제로 작동하는지 확인하세요.

고가용성 검사 목록

다음은 고가용성을 달성하기 위한 권장 구성입니다.

  • 영역 장애에 대한 복원력을 보장하기 위해 데이터베이스 또는 탄력적 풀에 사용할 수 있는 영역 중복을 사용하도록 설정합니다.

재해 복구 체크리스트

Azure SQL Database는 가용성을 자동으로 기본 있지만, 영향을 주는 중단이 전체 지역에 걸쳐 있기 때문에 고가용성(영역 중복성)이 있어도 복원력을 보장하지 않을 수 있는 인스턴스가 있습니다. Azure SQL 데이터베이스의 지역 중단이 발생하면 재해 복구를 시작해야 할 수 있습니다.

재해 복구를 가장 잘 준비하려면 다음 권장 사항을 따르세요.

  • 데이터베이스 그룹에 대해 장애 조치(failover) 그룹을 사용하도록 설정합니다.
    • 애플리케이션이 현재 주 서버 및 데이터베이스에 자동으로 연결되도록 애플리케이션 연결 문자열 읽기/쓰기 및 읽기 전용 수신기 엔드포인트를 사용합니다.
    • 장애 조치(failover) 정책을 고객 관리형으로 설정합니다.
  • 장애 조치(failover) 그룹 대신 활성 지역 복제를 사용하도록 설정하여 다른 Azure 지역에서 읽기 가능한 보조 데이터베이스를 가질 수 있습니다.
  • 지역 보조 데이터베이스가 주 데이터베이스와 동일한 서비스 계층, 컴퓨팅 계층 (프로비전 또는 서버리스) 및 컴퓨팅 크기(DTU 또는 vCore)를 사용하여 생성되었는지 확인합니다.
  • 스케일 업할 때에는 지역 보조 데이터베이스부터 스케일 업한 다음, 주 데이터베이스를 스케일 업해야 합니다.
  • 스케일 다운할 때에는 역순으로 합니다. 주 데이터베이스부터 스케일 다운한 다음, 보조 데이터베이스를 스케일 다운합니다.
  • 재해 복구는 본질적으로 기본 지역과 보조 지역 간에 데이터의 비동기 복제를 사용하도록 설계되어 있습니다. 커밋 대기 시간보다 높게 데이터 가용성의 우선순위를 지정하려면 트랜잭션을 커밋한 직후 sp_wait_for_database_copy_sync 저장 프로시저를 호출하는 방법을 고려합니다. sp_wait_for_database_copy_sync를 호출하면 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그로 전송되어 강화될 때까지 호출 스레드가 차단됩니다.
  • 기본 데이터베이스의 sys.dm_geo_replication_link_status 동적 관리 뷰(DMV)의 replication_lag_sec 열을 사용하여 복구 지점 목표(RPO)와 관련된 지연을 모니터링합니다. 이 DMV는 주 데이터베이스에서 커밋된 후 보조 데이터베이스에서 트랜잭션 로그에 강화되는 트랜잭션 간의 지연 시간(초)을 보여 줍니다. 예를 들어 지연 시간이 1초라고 가정할 때, 주 서버가 정전의 영향을 받고 해당 시점에 지역 장애 조치(failover)가 시작되면 마지막 1초 동안 커밋된 트랜잭션이 손실됩니다.
  • 장애 조치(failover) 그룹 또는 활성 지역 복제를 사용할 수 없는 경우에는 백업 스토리지 중복도 옵션을 지역 중복 백업 스토리지로 설정하여 지역 복원 기능을 사용하는 것이 좋습니다.
  • 재해 복구 훈련을 자주 계획하고 실행하므로 실제 중단 시 더 잘 준비할 수 있습니다.

중단에 대한 보조 준비

활성 지역 복제, 장애 조치(failover) 그룹 또는 지역 복원을 사용하여 다른 데이터 영역으로 성공적으로 복구하려면 다른 지역에서 보조 Azure SQL 데이터베이스 논리 서버를 준비해야 합니다. 필요한 경우 이 보조 서버가 새 주 서버가 될 수 있습니다. 또한 원활한 복구를 위해 잘 정의된 단계를 문서화하고 테스트해야 합니다. 이러한 준비 단계는 다음과 같습니다.

  • 지역 복원의 경우 새 주 서버가 될 수 있는 다른 지역의 서버를 식별합니다. 주 지역에 쌍을 이루는 지역이 있는 경우 쌍을 이루는 지역을 보조 지역으로 사용하는 것이 일반적입니다. 이렇게 하면 일반적으로 복제 및 지역 복원 작업의 대기 시간을 줄일 수 있습니다.
  • 사용자를 새 주 서버로 리디렉션하는 방법을 결정합니다. 애플리케이션 연결 문자열 또는 DNS 항목을 수동으로 변경하여 사용자를 리디렉션할 수 있습니다. 장애 조치(failover) 그룹을 구성하고 애플리케이션 연결 문자열 읽기/쓰기 및 읽기 전용 수신기를 사용하는 경우 추가 작업이 필요하지 않습니다. 장애 조치(failover) 후 연결은 새 주 항목으로 자동 지정됩니다.
  • 사용자가 새 주 데이터베이스에 액세스하는 데 필요한 방화벽 규칙을 식별하고 선택적으로 이를 정의합니다.
  • 새로운 주 서버의 master 데이터베이스에 있어야 하는 로그인을 식별하고 필요에 따라 만든 후, 이러한 로그인(있는 경우)이 master 데이터베이스에서 적절한 권한이 있는지 확인합니다. 자세한 내용은 재해 복구 후의 Azure SQL Database 보안을 참조하세요.
  • 새로운 주 데이터베이스에 매핑하기 위해 업데이트해야 하는 경고 규칙을 식별합니다.
  • 현재 주 서버의 감사 구성을 문서화하고 보조 서버에서 동일하게 만듭니다.

관련 콘텐츠