다음을 통해 공유

활성 지리적 복제

  • 아티클

적용 대상: Azure SQL Database

이 문서에서는 주 데이터베이스에서 읽을 수 있는 보조 데이터베이스로 데이터를 지속적으로 복제할 수 있는 Azure SQL Database에 대한 활성 지역 복제 기능에 대한 개요를 제공합니다. 읽기 가능한 보조 데이터베이스는 주 데이터베이스와 같은 Azure 지역에 있을 수 있지만 일반적으로는 다른 지역에 있습니다. 이러한 종류의 읽기 가능한 보조 데이터베이스를 지역 보조 또는 지역 복제본이라고도 합니다.

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

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

개요

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

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

활성 지역 복제 다이어그램.

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

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

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

참고 항목

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

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

다음 그림은 미국 서부 2 지역에 주 데이터베이스 및 미국 동부 지역에 지역 보조 데이터베이스가 구성된 활성 지역 복제의 예를 보여줍니다.

SQL DB 지리적 복제 관계를 보여주는 Azure 포털의 스크린샷.

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

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

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

용어 및 기능

  • 자동 비동기 복제

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

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

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

    중요

    지역 복제를 사용하여 주 데이터베이스와 동일한 지역에 보조 복제본을 만들 수 있습니다. 이 보조 복제본을 사용하여 동일한 지역에서 읽기 확장 시나리오를 충족할 수 있습니다. 그러나 동일한 지역의 보조 복제본은 재앙적인 오류 또는 대규모 중단에 대비한 추가 복원력을 제공하지 않으므로 재해 복구를 위한 적절한 장애 조치(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) 후 애플리케이션이 새로운 주 데이터베이스에 즉시 액세스할 수 있도록 하려면 보조 서버에 대한 인증 및 네트워크 액세스가 올바르게 구성되어야 합니다. 자세한 내용은 지역 복원 또는 장애 조치(failover)를 위해 Azure SQL Database 보안 구성 및 관리를 참조하세요. 또한 보조 데이터베이스의 백업 보존 정책이 주 데이터베이스의 백업 보존 정책과 일치하는지 유효성을 검사합니다. 이 설정은 데이터베이스의 일부가 아니며 주 데이터베이스에서 복제되지 않습니다. 기본적으로 지역 보조 데이터베이스는 7일의 기본 PITR 보존 기간으로 구성됩니다. 자세한 내용은 Azure SQL Database의 자동화된 백업을 참조하세요.

Important

데이터베이스가 장애 조치(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 제한에 대한 자세한 내용은 트랜잭션 로그 속도 거버넌스를 참조하세요.

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

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

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

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

구독 간 지역 복제

  • 두 구독이 동일한 Microsoft Entra 테넌트에 있는 한 Azure Portal을 사용하여 구독 간에 활성 지역 복제를 설정할 수 있습니다.

  • 기본 또는 보조 논리 서버에서 Microsoft Entra 전용 인증이 활성화되어 있고 Microsoft Entra ID 사용자를 사용하여 만들려고 하는 경우, 동일하거나 다른 Microsoft Entra 테넌트의 논리 서버에서 교차 구독 지리적 보조를 만드는 것은 지원되지 않습니다.

메서드 및 단계별 지침은 자습서: 활성 지역 복제 및 장애 조치(failover) 구성(Azure SQL Database)을 참조하세요.

프라이빗 엔드포인트

주 서버를 프라이빗 엔드포인트에 연결할 때 T-SQL 사용하여 지역 보조를 추가할 수 없습니다.

  • 프라이빗 엔드포인트가 구성되었지만 공용 네트워크 액세스가 허용되는 경우 공용 IP 주소에서 주 서버에 연결할 때 지역 보조를 추가할 수 있습니다.
  • 지역 보조가 추가된 후에는 공용 네트워크 액세스를 거부할 수 있습니다.

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

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

주 데이터베이스 스케일링

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

장애 조치(failover) 그룹에 대한 자세한 내용은 장애 조치(failover) 그룹의 복제본 크기 조정을 검토합니다.

중요한 데이터 손실 방지

광역 네트워크의 높은 대기 시간으로 인해 지역 복제에는 비동기 복제 메커니즘이 사용됩니다. 비동기 복제를 사용하면 주 데이터베이스에서 오류가 발생할 때 데이터가 손실될 가능성이 있습니다. 중요한 트랜잭션을 데이터 손실로부터 보호하려면 애플리케이션 개발자는 트랜잭션을 커밋한 후 즉시 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 데이터베이스 REST API 및 Azure PowerShell cmdlet을 비롯한 Azure Resource Manager API 세트를 포함합니다. 이러한 API는 Azure RBAC(Azure 역할 기반 액세스 제어)를 지원합니다. 액세스 역할을 구현하는 방법에 관한 자세한 내용은 Azure RBAC(Azure 역할 기반 액세스 제어)를 참조하세요.

Important

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

명령 설명
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 커밋된 모든 트랜잭션이 지역 보조 데이터베이스의 트랜잭션 로그에 강화될 때까지 애플리케이션이 대기합니다.

관련 콘텐츠

활성 지역 복제 구성:

기타 비즈니스 연속성 콘텐츠: