활성 지리적 복제

  • 아티클

적용 대상:Azure SQL Database

활성 지역 복제는 주 데이터베이스에 대해 지속적으로 동기화되는 읽기 가능한 보조 데이터베이스를 만들 수 있는 기능입니다. 읽기 가능한 보조 데이터베이스는 주 데이터베이스와 같은 Azure 지역에 있을 수 있지만 일반적으로는 다른 지역에 있습니다. 이러한 종류의 읽기 가능한 보조 데이터베이스를 지역 보조 또는 지역 복제본이라고도 합니다.

활성 지역 복제는 데이터베이스별로 구성되며 수동 장애 조치(failover)만 지원합니다. 데이터베이스 그룹을 장애 조치(failover)하거나 애플리케이션에 안정적인 연결 엔드포인트가 필요한 경우 장애 조치(failover) 그룹을 대신 사용하는 것을 고려해 보세요.

활성 지역 복제를 사용하여 SQL Database 마이그레이션을 사용할 수도 있습니다.

개요

활성 지역 복제는 비즈니스 연속성 솔루션으로 설계되었습니다. 활성 지역 복제는 지역 재해 또는 대규모 중단이 발생한 경우 개별 데이터베이스의 빠른 재해 복구를 수행할 수 있는 비즈니스 연속성 솔루션으로 설계되었습니다. 지역 복제를 설정하면 다른 Azure 지역의 지역 보조로 지역 장애 조치(failover)를 시작할 수 있습니다. 지역 장애 조치(failover)는 애플리케이션에 의해 프로그래밍식으로 시작되거나 사용자가 수동으로 시작합니다.

다음 다이어그램은 활성 지역 복제를 사용하는 지역 중복 클라우드 애플리케이션의 일반적인 구성을 보여 줍니다.

active geo-replication

어떤 이유로 주 데이터베이스에서 오류가 발생하면 보조 데이터베이스로 지역 장애 조치(failover)를 시작할 수 있습니다. 보조 역할이 주 역할로 승격되면 다른 모든 보조 역할은 자동으로 새로운 주 역할에 연결됩니다.

다음을 사용하여 지역 복제를 관리하고 지역 장애 조치(failover)를 시작할 수 있습니다.

활성 지역 복제는 Always On 가용성 그룹 기술을 활용하여 주 복제본에 생성된 트랜잭션 로그를 모든 지역 복제본에 비동기적으로 복제합니다. 특정 시점에 보조 데이터베이스가 주 데이터베이스보다 약간 뒤에 있을 수 있지만, 보조 데이터베이스의 데이터는 트랜잭션 측면에서 일관성이 보장됩니다. 즉, 커밋되지 않은 트랜잭션의 변경 내용은 표시되지 않습니다.

참고 항목

활성 지역 복제는 주 복제본에서 보조 복제본으로 데이터베이스 트랜잭션 로그를 스트리밍하여 변경 내용을 복제합니다. 구독에서 DML(INSERT, UPDATE, DELETE) 명령을 실행하여 변경 내용을 복제하는 트랜잭션 복제와는 관련이 없습니다.

지역 복제는 지역 중복성을 제공합니다. 지역 중복성을 사용하면 자연 재해, 사람의 치명적인 실수 또는 악의적 행위로 인해 Azure 지역 전체 또는 일부가 영구적으로 손실되더라도 애플리케이션을 빠르게 복구할 수 있습니다. 지역 복제 RPO는 비즈니스 연속성 개요에서 찾을 수 있습니다.

다음 그림은 미국 중북부 지역에 주 데이터베이스, 미국 중남부 지역에 지역 보조 데이터베이스가 구성된 활성 지역 복제의 예입니다.

geo-replication relationship

활성 지역 복제는 재해 복구 외에도 다음과 같은 시나리오에서 사용할 수 있습니다.

  • 데이터베이스 마이그레이션: 활성 지역 복제를 사용하여 최소 가동 중지 시간으로 하나의 서버에서 다른 데이터베이스를 마이그레이션할 수 있습니다.
  • 애플리케이션 업그레이드: 애플리케이션을 업그레이드하는 동안 추가 보조 데이터베이스를 장애 복구 복사본으로 만들 수 있습니다.

완전한 비즈니스 연속성을 달성하기 위해 데이터베이스 지역 중복성을 추가하는 것은 솔루션의 일부일 뿐입니다. 치명적인 오류 후 애플리케이션(서비스) 엔드투엔드 복구에는 서비스 및 모든 종속성 서비스를 구성하는 모든 구성 요소의 복구가 필요합니다. 이러한 구성 요소의 예에는 클라이언트 소프트웨어(예: 사용자 지정 JavaScript를 사용한 브라우저), 웹 프런트 엔드, 스토리지 및 DNS가 포함됩니다. 모든 구성 요소는 동일한 오류에 탄력적이며 애플리케이션의 RTO(복구 시간 목표) 내에서 사용할 수 있는 것이 중요합니다. 따라서 모든 종속성 서비스를 확인하고 제고하는 보장 사항 및 기능을 이해해야 합니다. 그런 다음 의존하는 서비스 장애 조치 중 서비스 기능을 확인하도록 적절한 단계를 수행해야 합니다. 재해 복구를 위한 솔루션 설계에 대한 자세한 내용은 활성 지역 복제를 사용하여 재해 복구를 위한 클라우드 솔루션 설계를 참조하세요.

활성 지역 복제 용어 및 기능

  • 자동 비동기 복제

    기존 데이터베이스의 지역 보조만 만들 수 있습니다. 지역 보조는 주 데이터베이스가 있는 서버를 제외한 모든 논리 서버에 만들 수 있습니다. 지역 보조를 만들면 지역 보조 복제본이 주 데이터베이스의 데이터로 채워집니다. 이 프로세스를 시드라고 합니다. 지역 보조가 만들어지고 시딩되면 주 데이터베이스에 대한 업데이트가 지역 보조 복제본에 자동으로 비동기적으로 복제됩니다. 비동기 복제란 트랜잭션이 주 데이터베이스에 복제 전에 커밋된다는 뜻입니다.

  • 읽기 가능한 지역 보조 복제본

    애플리케이션은 지역 보조 복제본에 액세스하고 주 데이터베이스 액세스에 사용된 것과 동일한 또는 다른 보안 주체를 사용하여 읽기 전용 쿼리를 실행할 수 있습니다. 자세한 내용은 읽기 전용 복제본을 사용하여 읽기 전용 쿼리 워크로드 오프로드를 참조하세요.

    중요

    지역 복제를 사용하여 주 데이터베이스와 동일한 지역에 보조 복제본을 만들 수 있습니다. 이 보조 복제본을 사용하여 동일한 지역에서 읽기 확장 시나리오를 충족할 수 있습니다. 그러나 동일한 지역의 보조 복제본은 재앙적인 오류 또는 대규모 중단에 대비한 추가 복원력을 제공하지 않으므로 재해 복구를 위한 적절한 장애 조치(failover) 대상이 아닙니다. 또한 가용성 영역 격리도 보장하지 않습니다. 중요 비즈니스용 또는 프리미엄 서비스 계층 영역 중복 구성 또는 범용 서비스 계층 영역 중복 구성을 사용하여 가용성 영역 격리를 달성할 수 있습니다.

  • 장애 조치(failover)(데이터 손실 없음)

    지역 장애 조치(failover)는 전체 데이터 동기화를 완료한 후 주 지역 및 보조 지역 데이터베이스의 역할을 전환합니다. 장애 조치(failover)에 소요되는 시간은 지역 보조 데이터베이스에 동기화해야 하는 주 데이터베이스의 트랜잭션 로그 크기에 따라 달라집니다. 장애 조치(failover)는 다음 시나리오를 위해 설계되었습니다.

    • 데이터 손실이 허용되지 않을 경우 프로덕션에서 DR(재해 복구) 드릴을 수행합니다.
    • 데이터베이스 다른 지역에 재배치하기
    • 중단이 완화된 후 데이터베이스를 주 지역으로 되돌리기(이것을 장애 복구(failback)라고 함)

  • 강제 장애 조치(failover)(데이터 손실 가능성 있음)

    강제 장애 조치(failover)는 주 데이터베이스와의 동기화 없이 보조 지역을 주 역할로 즉시 전환합니다. 주 데이터베이스에서 커밋되었지만 보조 데이터베이스에 복제되지 않은 트랜잭션은 모두 손실됩니다. 이 작업은 주 데이터베이스에 액세스할 수 없지만 데이터베이스 가용성을 신속하게 복원해야 하는 중단 발생 시 복구 방법으로 설계되었습니다. 기존 주 데이터베이스가 다시 온라인으로 복구되면 자동으로 다시 연결되고, 현재 주 데이터를 사용하여 다시 시딩되고, 새로운 지역 보조가 됩니다.

    Important

    장애 조치(failover) 또는 강제 장애 조치(failover) 후에는 주 데이터베이스가 다른 논리 서버에 있기 때문에 새로운 주 데이터베이스의 연결 엔드포인트가 변경됩니다.

  • 여러 읽기 가능 지역 보조 데이터베이스

    주 지역에 대한 지역 보조를 네 개까지 만들 수 있습니다. 보조 데이터베이스가 하나밖에 없는 경우 새 보조 데이터베이스를 만들 때까지 애플리케이션이 더 높은 위험에 노출됩니다. 보조 데이터베이스가 여러 개 있는 경우 그 중 하나가 실패하더라도 애플리케이션이 계속해서 보호됩니다. 추가 보조 데이터베이스를 사용하여 읽기 전용 워크로드를 스케일 아웃할 수도 있습니다.

    팁

    활성 지역 복제를 사용하여 전역으로 분산된 애플리케이션을 빌드하고 다섯 개 이상의 지역에 있는 데이터에 대한 읽기 전용 액세스를 제공해야 하는 경우 보조 데이터베이스의 보조 데이터베이스를 만들어(체이닝으로 알려진 프로세스) 추가 지역 복제본을 만들면 됩니다. 연결된 지역 복제본의 복제 지연이 주 복제본에 직접 연결된 지역 복제본의 지연보다 오래 걸릴 수 있습니다. 체이닝된 지역 복제 설정 토폴로지는 프로그래밍 방식으로만 지원되고 Azure Portal에서는 지원되지 않습니다.

  • 탄력적 풀에서 데이터베이스 지역 복제

    각 지역 보조 데이터베이스는 단일 데이터베이스일 수도 있고 탄력적 풀에 있는 데이터베이스일 수도 있습니다. 각 지역 보조 데이터베이스에 대한 Elastic Pool 선택은 별개이며 토폴로지의 다른 복제본 구성(주 또는 보조)에 따라 달라지지 않습니다. 각 탄력적 풀은 단일 논리 서버 내에 포함됩니다. 논리 서버의 데이터베이스 이름은 고유해야 하기 때문에 동일한 주 지역의 여러 지역 보조가 탄력적 풀을 공유할 수 없습니다.

  • 사용자 제어 지역 장애 조치(failover) 및 장애 복구(failback)

    초기 시딩을 완료한 지역 보조는 언제든지 애플리케이션 또는 사용자가 명시적으로 주 역할로 전환(장애 조치(failover))할 수 있습니다. 주 복제본에 액세스할 수 없는 중단 중에는 강제 장애 조치(failover)만 사용할 수 있으며, 이는 지역 보조 데이터베이스를 새 주 복제본으로 즉시 승격합니다. 중단이 완화되면 자동으로 시스템은 복구된 주 데이터베이스를 지역 보조 데이터베이스로 만들고, 새로운 주 데이터베이스로 업데이트합니다. 지역 복제의 비동기 특성으로 인해 이러한 트랜잭션이 지역 보조로 복제되기 전에 주 지역에서 오류가 발생하면 계획되지 않은 지역 장애 조치(failover) 중에 최근 트랜잭션이 손실될 수 있습니다. 지역 보조가 여러 개 있는 주 지역이 장애 조치(failover)되면 사용자의 개입 없이 시스템이 자동으로 복제 관계를 다시 구성하고 남아 있는 보조 데이터베이스를 새로 승격되는 주 데이터베이스에 연결합니다. 장애 조치(failover)를 일으킨 중단 상황이 완화된 후에는 주 지역을 원래 지역으로 되돌리는 것이 바람직할 수 있습니다. 그렇게 하려면 수동 장애 조치(failover)를 수행하세요.

  • 대기 복제본(replica)

    보조 복제본(replica) DR(재해 복구)에만 사용되고 읽기 또는 쓰기 워크로드가 없는 경우 복제본(replica)을 대기로 지정하여 라이선스 비용을 절감할 수 있습니다.

지역 장애 조치(failover) 준비

장애 조치(failover) 후 애플리케이션이 새로운 주 데이터베이스에 즉시 액세스할 수 있도록 하려면 보조 서버에 대한 인증 및 네트워크 액세스가 올바르게 구성되어야 합니다. 자세한 내용은 재해 복구 후의 SQL Database 보안을 참조하세요. 또한 보조 데이터베이스의 백업 보존 정책이 주 데이터베이스의 백업 보존 정책과 일치하는지 유효성을 검사합니다. 이 설정은 데이터베이스의 일부가 아니며 주 데이터베이스에서 복제되지 않습니다. 기본적으로 지역 보조 데이터베이스는 7일의 기본 PITR 보존 기간으로 구성됩니다. 자세한 내용은 SQL Database 자동화된 백업을 참조하세요.

중요

데이터베이스가 장애 조치(failover) 그룹의 멤버인 경우 지역 복제 장애 조치(failover) 명령을 사용하여 장애 조치(failover)를 시작할 수 없습니다. 그룹에 대해 장애 조치(failover) 명령을 사용합니다. 개별 데이터베이스를 장애 조치(failover)해야 하는 경우 먼저 해당 데이터베이스를 장애 조치(failover) 그룹에서 제거해야 합니다. 자세한 내용은 장애 조치(failover) 그룹을 참조하세요.

지역 보조 구성

주 데이터베이스와 보조 지역 데이터베이스는 모두 동일한 서비스 계층이어야 합니다. 또한 지역 보조 데이터베이스를 주 데이터베이스와 동일한 백업 스토리지 중복성, 컴퓨팅 계층 및 컴퓨팅 크기(DTU 또는 vCore 수)로 구성할 것을 강력히 권장합니다. 주 데이터베이스에서 많은 쓰기 워크로드가 발생하면 컴퓨팅 크기가 더 작은 지역 보조 데이터베이스를 사용하지 못하게 될 수 있습니다. 이로 인해 지역 보조에서 복제 지연이 발생하고 결국에는 지역 보조를 사용할 수 없게 될 수 있습니다. 이러한 위험을 완화하기 위해 활성 지역 복제는 필요한 경우 보조 데이터베이스에서 지연이 발생하지 않도록 주 데이터베이스의 트랜잭션 로그 속도를 줄입니다(제한합니다).

불균형한 지역 보조 구성의 또 다른 결과는 장애 조치(failover) 후 새로운 주 데이터베이스의 컴퓨팅 용량이 부족하기 때문에 애플리케이션 성능이 저하될 수 있다는 것입니다. 이 경우 리소스가 충분하도록 데이터베이스를 스케일 업해야 하며, 이때 상당한 시간이 걸릴 수 있습니다. 또한 스케일 업 프로세스가 끝나면 고가용성 장애 조치(failover)가 필요하며, 이때 애플리케이션 워크로드가 중단될 수 있습니다.

컴퓨팅 크기가 더 작은 지역 보조를 만들기로 결정하는 경우 주 데이터베이스의 시간에 따른 로그 IO 속도를 모니터링해야 합니다. 이를 통해 복제 부하를 지속하는 데 필요한 지역 보조의 최소 컴퓨팅 크기를 추정할 수 있습니다. 예를 들어 주 데이터베이스가 P6(1000DTU)이면 해당 로그 IO는 50%에서 유지되고, 지역 보조 데이터베이스는 P4(500DTU) 이상이어야 합니다. 기록 로그 IO 데이터를 검색하려면 sys.resource_stats 뷰를 사용합니다. 세분성이 높아서 단기 스파이크를 보다 잘 반영하는 최근 로그 IO 데이터를 검색하려면 sys.dm_db_resource_stats 뷰를 사용합니다.

팁

지역 보조 데이터베이스의 컴퓨팅 크기가 더 작기 때문에 주 데이터베이스에서 발생하는 트랜잭션 로그 IO 제한은 sys.dm_exec_requests 및 sys.dm_os_wait_stats 데이터베이스 뷰에 표시되는 HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 대기 유형을 사용하여 보고됩니다.

주 데이터베이스의 트랜잭션 로그 IO는 지역 보조 데이터베이스의 컴퓨팅 크기가 더 작은 것과는 무관한 이유로 제한될 수 있습니다. 이러한 유형의 제한은 지역 보조 데이터베이스의 컴퓨팅 크기가 주 데이터베이스와 같거나 더 큰 경우에도 발생할 수 있습니다. 대기 유형을 포함하여 다양한 유형의 로그 IO 제한에 대한 자세한 내용은 트랜잭션 로그 속도 거버넌스를 참조하세요.

기본적으로 지역 보조 데이터베이스의 백업 스토리지 중복성은 주 데이터베이스와 동일합니다. 다른 백업 스토리지 중복성을 사용하여 지역 보조 데이터베이스를 구성하도록 선택할 수 있습니다. 백업은 항상 주 데이터베이스에서 수행됩니다. 보조 데이터베이스가 다른 백업 스토리지 중복성으로 구성된 경우 장애 조치(failover) 후 지역 보조 데이터베이스가 주 데이터베이스로 승격되면 새로운 주 데이터베이스(이전에는 보조 데이터베이스)에서 선택한 스토리지 유형(RA-GRS, ZRS, LRS)에 따라 새로운 백업이 저장되고 요금이 청구됩니다.

대기 복제본(replica) 사용하여 비용 절감

보조 복제본(replica) DR(재해 복구)에만 사용되고 읽기 또는 쓰기 워크로드가 없는 경우, 새 활성 지역 복제 관계를 구성할 때 데이터베이스를 대기로 지정하여 라이선스 비용을 절감할 수 있습니다.

자세한 내용은 라이선스가 필요 없는 대기 복제본(replica)을 검토하세요.

구독 간 지역 복제

Transact-SQL(T-SQL)을 사용하여 기본 구독과 다른 구독에서 지역 보조를 만듭니다(Microsoft Entra ID(이전의 Azure Active Directory)의 동일한 테넌트 아래에 있는지 여부). 자세한 내용은 활성 지역 복제 구성을 검토합니다.

자격 증명 및 방화벽 규칙의 동기화 유지

데이터베이스에 연결하기 위해 공용 네트워크 액세스를 사용하는 경우 지역 복제 데이터베이스에 데이터베이스 수준 IP 방화벽 규칙을 사용하는 것이 좋습니다. 이러한 규칙은 데이터베이스와 함께 복제되므로, 모든 지역 보조 데이터베이스는 주 데이터베이스와 동일한 IP 방화벽 규칙을 갖습니다. 이렇게 하면 고객이 주 데이터베이스 및 보조 데이터베이스를 호스팅하는 서버에서 수동으로 방화벽 규칙을 구성하고 유지 관리할 필요가 없습니다. 마찬가지로, 포함된 데이터베이스 사용자를 데이터 액세스에 사용하면 주 데이터베이스와 보조 데이터베이스가 항상 동일한 인증 자격 증명을 갖게 됩니다. 이렇게 하면 지역 장애 조치(failover) 후에 인증 자격 증명 불일치로 인한 중단이 없습니다. 포함된 사용자가 아닌 로그인과 사용자를 사용하는 경우 보조 데이터베이스에 대한 동일한 로그인이 있는지 확인하는 추가 단계를 수행해야 합니다. 자세한 구성 정보는 로그인 및 사용자를 구성하는 방법을 참조하세요.

주 데이터베이스 스케일링

지역 보조 데이터베이스와의 연결을 끊지 않고도 주 데이터베이스를 다른 컴퓨팅 크기(동일한 서비스 계층 내의)로 스케일 업 또는 스케일 다운할 수 있습니다. 스케일 업할 때에는 지역 보조 데이터베이스부터 스케일 업한 다음, 주 데이터베이스를 스케일 업하는 것이 좋습니다. 스케일 다운할 때에는 역순으로 합니다. 주 데이터베이스부터 스케일 다운한 다음, 보조 데이터베이스를 스케일 다운합니다.

참고

장애 조치(failover) 그룹 구성의 일부로 지역 보조 데이터베이스를 만든 경우 지역 보조 데이터베이스를 스케일 다운하지 않는 것이 좋습니다. 이렇게 하면 지역 장애 조치(failover) 후 데이터 계층에 일반 워크로드를 처리할 수 있을 만큼 충분한 용량이 생깁니다.

중요

장애 조치(failover) 그룹의 주 데이터베이스는 보조 데이터베이스가 상위 계층으로 먼저 확장되지 않는 한 더 높은 서비스 계층(버전)으로 확장할 수 없습니다. 예를 들어 주 데이터베이스를 범용에서 중요 비즈니스용으로 스케일 업하려면 먼저 지역 보조 데이터베이스를 중요 비즈니스용으로 스케일 업해야 합니다. 이 규칙을 위반하는 방식으로 주 또는 지역 보조 데이터베이스를 스케일 업하려고 시도하면 다음 오류가 발생합니다.

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

중요한 데이터 손실 방지

광역 네트워크의 높은 대기 시간으로 인해 지역 복제에는 비동기 복제 메커니즘이 사용됩니다. 비동기 복제를 사용하면 주 데이터베이스에서 오류가 발생할 때 데이터가 손실될 가능성이 있습니다. 중요한 트랜잭션을 데이터 손실로부터 보호하려면 애플리케이션 개발자는 트랜잭션을 커밋한 후 즉시 sp_wait_for_database_copy_sync 시스템 프로시저를 호출하면 됩니다. sp_wait_for_database_copy_sync를 호출하면 마지막으로 커밋된 트랜잭션이 보조 데이터베이스의 트랜잭션 로그로 전송되어 강화될 때까지 호출 스레드가 차단됩니다. 그러나 전송된 트랜잭션이 보조 데이터베이스에서 재생(다시 실행)될 때까지 기다리지는 않습니다. sp_wait_for_database_copy_sync의 범위는 특정 지역 복제 링크로 한정됩니다. 주 데이터베이스에 대한 연결 권한이 있는 모든 사용자는 이 프로시저를 호출할 수 있습니다.

참고

sp_wait_for_database_copy_sync는 특정 트랜잭션의 지역 장애 조치(failover) 후 데이터 손실을 방지하지만, 읽기 액세스에 대한 전체 동기화를 보장하지는 않습니다. sp_wait_for_database_copy_sync 프로시저를 호출하면 상당한 지연이 발생할 수 있으며, 호출 당시 주 데이터베이스에서 아직 전송되지 않은 트랜잭션 로그의 크기에 따라 지연 시간이 달라집니다.

지역 복제 지연 모니터링

RPO 측면에서 지연 시간을 모니터링하려면 주 데이터베이스에서 sys.dm_geo_replication_link_status의 replication_lag_sec 열을 사용합니다. 이 열은 주 데이터베이스에서 커밋된 후 보조 데이터베이스에서 트랜잭션 로그에 강화되는 트랜잭션 간의 지연 시간(초)을 보여줍니다. 예를 들어 지연이 1초인 경우 주 데이터베이스가 현재 중단의 영향을 받아 지역 장애 조치(failover)가 시작되면 마지막 초에 커밋된 트랜잭션이 손실됩니다.

지역 보조 데이터베이스에서 강화된 주 데이터베이스의 변경 내용과 관련된 지연 시간을 측정하려면 지역 보조 데이터베이스의 last_commit 시간을 주 데이터베이스의 동일한 값과 비교합니다.

팁

주 데이터베이스의 replication_lag_sec 값이 NULL이면 주 데이터베이스는 현재 지역 보조 데이터베이스가 얼마나 지연되는지 알 수 없습니다. 이는 일반적으로 프로세스가 다시 시작된 후에 발생하며 일시적 상태여야 합니다. replication_lag_sec가 오랫동안 NULL을 반환하면 경고를 보내는 것이 좋습니다. 연결 실패로 인해 지역 보조 데이터베이스가 주 데이터베이스와 통신할 수 없는 것일 수 있습니다.

지역 보조 데이터베이스와 주 데이터베이스 간의 last_commit 시간 차이가 점점 커질 수 있는 조건도 있습니다. 예를 들어 장시간 변경 내용이 없다가 주 복제본에서 커밋이 수행되는 경우에는 이 차이가 큰 값으로 급증했다가 빠르게 0으로 돌아갑니다. 이러한 두 값의 차이가 오랫동안 크게 유지되면 경고를 보내는 것이 좋습니다.

활성 지역 복제를 프로그래밍 방식으로 관리

앞서 설명한 것처럼 T-SQL, Azure PowerShell 및 REST API를 사용하여 활성 지역 복제를 프로그래밍 방식으로 관리할 수도 있습니다. 다음 표는 사용 가능한 명령의 집합을 보여 줍니다. 활성 지역 복제는 관리를 위해 Azure SQL Database REST API 및 Azure PowerShell cmdlet을 비롯한 Azure Resource Manager API 세트를 포함합니다. 이러한 API는 Azure RBAC(Azure 역할 기반 액세스 제어)를 지원합니다. 액세스 역할을 구현하는 방법에 관한 자세한 내용은 Azure RBAC(Azure 역할 기반 액세스 제어)를 참조하세요.

T-SQL: 단일 및 풀링된 데이터베이스의 지역 장애 조치(failover) 관리

중요

이러한 T-SQL 명령은 활성 지역 복제에만 적용되고 장애 조치(failover) 그룹에는 적용되지 않습니다. 따라서 장애 조치(failover) 그룹만 지원하는 SQL Managed Instance에는 적용되지 않습니다.

명령 설명
ALTER DATABASE 기존 데이터베이스에 대한 보조 데이터베이스를 만들고 데이터 복제를 시작하려면 ADD SECONDARY ON SERVER 인수를 사용합니다.
ALTER DATABASE 장애 조치(failover)를 시작하기 위해 보조 데이터베이스를 기본 데이터베이스로 전환하려면 FAILOVER 또는 FORCE_FAILOVER_ALLOW_DATA_LOSS를 사용합니다.
ALTER DATABASE SQL Database와 지정된 보조 데이터베이스 간의 데이터 복제를 종료하려면 REMOVE SECONDARY ON SERVER를 사용합니다.
sys.geo_replication_links 서버의 각 데이터베이스에 대한 모든 기존 복제 링크에 대한 정보를 반환합니다.
sys.dm_geo_replication_link_status 지정된 데이터베이스의 복제 링크에 대한 마지막 복제 시간, 마지막 복제 지연 및 기타 정보를 가져옵니다.
sys.dm_operation_status 복제 링크의 변경 내용을 포함하여 모든 데이터베이스 작업의 상태를 표시합니다.
sys.sp_wait_for_database_copy_sync 커밋된 모든 트랜잭션이 지역 보조 데이터베이스의 트랜잭션 로그에 강화될 때까지 애플리케이션이 대기합니다.

PowerShell: 단일 및 풀링된 데이터베이스의 지역 장애 조치(failover) 관리

참고

이 문서에서는 Azure와 상호 작용하는 데 권장되는 PowerShell 모듈인 Azure Az PowerShell 모듈을 사용합니다. Az PowerShell 모듈을 시작하려면 Azure PowerShell 설치를 참조하세요. Az PowerShell 모듈로 마이그레이션하는 방법에 대한 자세한 내용은 Azure PowerShell을 AzureRM에서 Azure로 마이그레이션을 참조하세요.

중요

PowerShell Azure Resource Manager 모듈은 여전히 Azure SQL Database에서 지원되지만 향후의 모든 개발은 Az.Sql 모듈을 위한 것입니다. 이러한 cmdlet은 AzureRM.Sql을 참조하세요. Az 모듈 및 AzureRm 모듈의 명령에 대한 인수는 실질적으로 동일합니다.

Cmdlet 설명
Get-AzSqlDatabase 하나 이상의 데이터베이스를 가져옵니다.
New-AzSqlDatabaseSecondary 기존 데이터베이스에 대한 보조 데이터베이스를 만들고 데이터 복제를 시작합니다.
Set-AzSqlDatabaseSecondary 장애 조치를 시작하기 위해 보조 데이터베이스로 전환합니다.
Remove-AzSqlDatabaseSecondary SQL Database와 지정된 보조 데이터베이스 간의 데이터 복제를 종료합니다.
Get-AzSqlDatabaseReplicationLink 데이터베이스의 지역 복제 링크를 가져옵니다.

팁

샘플 스크립트는 활성 지역 복제를 사용하여 단일 데이터베이스 구성 및 장애 조치(failover) 및 활성 지역 복제를 사용하여 풀링된 데이터베이스 구성 및 장애 조치(failover)를 참조하세요.

REST API: 단일 및 풀링된 데이터베이스의 지역 장애 조치(failover) 관리

API 설명
데이터베이스 생성 또는 업데이트(createMode=Restore) 주 보조 데이터베이스 또는 보조 데이터베이스를 만들거나, 업데이트하거나, 복원합니다.
데이터베이스 만들기 또는 업데이트 상태 가져오기 만들기 작업 동안 상태를 반환합니다.
보조 데이터베이스를 주 데이터베이스로 설정(계획된 장애 조치(failover)) 현재 주 데이터베이스에서 장애 조치(failover)를 통해 주 데이터베이스로 사용할 보조 데이터베이스를 설정합니다. 이 옵션은 SQL Managed Instance에서 지원되지 않습니다.
보조 데이터베이스를 주 데이터베이스로 설정(계획되지 않은 장애 조치(failover)) 현재 주 데이터베이스에서 장애 조치(failover)를 통해 주 데이터베이스로 사용할 보조 데이터베이스를 설정합니다. 이 작업으로 인해 데이터가 손실될 수 있습니다. 이 옵션은 SQL Managed Instance에서 지원되지 않습니다.
복제 링크 가져오기 지역 복제 파트너 관계의 지정된 데이터베이스에 대한 특정 복제 링크를 가져옵니다. sys.geo_replication_links 카탈로그 뷰에 표시되는 정보를 검색합니다. 이 옵션은 SQL Managed Instance에서 지원되지 않습니다.
복제 링크 - 데이터베이스 기준 목록 지역 복제 파트너 관계의 지정된 데이터베이스에 대한 모든 복제 링크를 가져옵니다. sys.geo_replication_links 카탈로그 뷰에 표시되는 정보를 검색합니다.
복제 링크 삭제 데이터베이스 복제 링크를 삭제합니다. 장애 조치(failover) 중에 수행할 수 없습니다.

다음 단계