Always On 가용성 그룹의 가용성 모드 간 차이점

  • 아티클

적용 대상:SQL Server

Always On 가용성 그룹에서 가용성 모드는 지정된 가용성 복제본(replica) 동기 커밋 모드에서 실행할 수 있는지 여부를 결정하는 복제본(replica)의 속성입니다. 각 가용성 복제본에 대해 가용성 모드를 동기 커밋 모드나 비동기 커밋 또는 구성 전용 모드로 구성해야 합니다. 주 복제본이 비동기 커밋 모드로 구성된 경우 주 복제본에서는 보조 복제본이 들어오는 트랜잭션 로그 레코드를 디스크에 기록(로그를 강화하기 위해서)할 때까지 기다리지 않습니다. 주 복제본이 비동기 커밋 모드로 구성된 경우 주 복제본에서는 보조 복제본이 들어오는 트랜잭션 로그 레코드를 디스크에 기록( 로그 확정)할 때까지 기다리지 않습니다. 주 복제본과 특정 보조 복제본이 모두 동기 커밋 모드로 구성된 경우에는 보조 복제본이 주 복제본의 세션 제한 시간내에 주 복제본을 ping하는 데 실패하지 않은 한 주 복제본은 보조 복제본이 로그를 확정했음을 확인할 때까지 기다립니다.

참고 항목

보조 복제본이 주 복제본의 세션 제한 시간을 초과할 경우 주 복제본은 일시적으로 해당 보조 복제본에 대해 비동기 커밋 모드로 전환합니다. 보조 복제본이 주 복제본에 다시 연결할 때는 동기 커밋 모드가 다시 시작됩니다.

지원되는 가용성 모드

Always On 가용성 그룹은 다음과 같이 비동기-커밋 모드, 동기-커밋 모드 및 구성 전용 모드라는 세 가지 가용성 모드를 지원합니다:

  • 비동기-커밋 모드는 여러 가용성 복제본이 상당한 거리를 두고 분산되어 있는 경우에 적합한 재해 복구 솔루션입니다. 모든 보조 복제본이 비동기-커밋 모드로 실행될 경우 주 복제본은 보조 복제본이 로그를 확정할 때까지 기다리지 않습니다. 대신 주 복제본은 로그 레코드를 로컬 로그 파일에 쓴 후 곧바로 트랜잭션 확인을 클라이언트로 보냅니다. 주 복제본은 비동기-커밋 모드로 구성된 보조 복제본에 비해 최소한의 트랜잭션 대기 시간으로 실행됩니다. 현재 주 복제본이 비동기 커밋 가용성 모드로 구성되어 있는 경우 주 복제본은 보조 복제본 각각의 가용성 모드 설정에 관계없이 모든 보조 복제본에 대해 비동기로 트랜잭션을 커밋합니다.

    자세한 정보는 항목의 뒷부분에 나오는 비동기-커밋 가용성 모드를 참조해 주세요.

  • 동기-커밋 모드 는 트랜잭션 대기 시간이 늘어나면 성능보다는 고가용성을 강조합니다. 동기-커밋 모드에서는 보조 복제본이 로그를 디스크에 확정할 때까지 트랜잭션이 트랜잭션 확정을 클라이언트에 보내기를 기다립니다. 보조 데이터베이스에서 데이터 동기화가 시작되면 보조 복제본은 해당 주 데이터베이스로부터 들어오는 로그 레코드를 적용하기 시작합니다. 모든 로그 레코드가 확정되면 보조 데이터베이스가 곧바로 SYNCHRONIZED 상태로 전환됩니다. 이후에는 로그 레코드가 로컬 로그 파일에 기록되기 이전에 보조 복제본(replica) 의해 모든 새 트랜잭션이 보조 복제본으로 인하여 강화됩니다. 지정된 보조 복제본의 모든 보조 데이터베이스가 동기화된 경우 동기-커밋 모드에서는 수동 장애 조치(Failover)와 필요한 경우 자동 장애 조치를 지원합니다.

    자세한 내용은 이 항목의 뒷부분에 나오는 동기-커밋 가용성 모드를 참조하세요.

  • 구성 전용 모드 는 Windows Server 장애 조치(failover) 클러스터에 없는 가용성 그룹에 적용됩니다. 구성 전용 모드의 복제본(replica)에는 사용자 데이터를 포함하지 않습니다. 구성 전용 모드에서 복제본(replica) master 데이터베이스는 가용성 그룹 구성 메타데이터를 저장합니다. 자세한 정보는 구성 복제본이 있는 가용성 그룹을 참조해 주세요.

다음 그림에서는 5개의 가용성 복제본(replica)을 가진 가용성 그룹을 보여주고 있습니다. 주 복제본 및 하나의 보조 복제본이 자동 장애 조치를 사용하여 동기-커밋 모드에 대해 구성됩니다. 또한 다른 보조 복제본이 계획된 수동 장애 조치만 사용하여 동기-커밋 모드에 대해 구성되고, 두 개의 보조 복제본이 비동기-커밋 모드에 대해 구성됩니다(강제 수동 장애 조치만 지원함, 일반적으로 강제 장애 조치 작업이라고 함).

Availability and failover modes of replicas

두 가용성 복제본 간의 동기화와 장애 조치(failover) 동작은 두 복제본의 가용성 모드에 따라 다릅니다. 예를 들어 동기 커밋이 발생하기 위해서는 현재 주 복제본(replica) 및 해당 보조 복제본(replica)이 모두 동기 커밋으로 구성되어야 합니다. 이와 마찬가지로 발생할 자동 장애 조치(Failover)의 경우 자동 장애 조치(Failover)에 대해 두 복제본을 모두 구성해야 합니다. 따라서 위에서 설명된 배포 시나리오에 대한 동작은 각 잠재적인 주 복제본의 동작을 알아보는 다음 표에서 요약될 수 있습니다:

현재 주 복제본 자동 장애 조치 대상 동기-커밋 모드 다음에 대한 동작 비동기-커밋 모드 다음에 대한 동작 자동 장애 조치 정책 가능 여부
01 02 02 및 03 04 예
02 01 01 및 03 04 예
03 01 및 02 04 아니요
04 01, 02 및 03 아니요

일반적으로 노드 04는 비동기 커밋 복제본으로서 재해 복구 사이트에 배포됩니다. 노드 04에 대한 장애 조치(Failover)를 수행한 후 노드 01, 02, 03은 비동기 커밋 모드로 유지된다는 점에서 두 사이트 간의 긴 네트워크 지연 시간으로 인해 가용성 그룹의 잠재적 성능이 저하되는 것을 방지할 수 있습니다.

Asynchronous-Commit Availability Mode

비동기 커밋 모드에서는 보조 복제본(replica)이 기본 복제본(replica)과 동기화되지 않습니다. 지정된 보조 데이터베이스가 해당 주 데이터베이스를 따라 잡더라도 보조 데이터베이스는 언제든지 뒤쳐질 수 있습니다. 비동기 커밋 모드는 주 복제본과 보조 복제본이 상당한 거리를 두고 떨어져 있으며 사소한 오류로 인해 주 복제본이 영향을 받지 않도록 하려는 경우나 동기화된 데이터 보호보다 성능을 중요시하는 경우의 재해 복구 시나리오에서 유용합니다. 또한 기본 복제본(replica) 보조 복제본(replica) 승인을 기다리지 않기 때문에 보조 복제본(replica) 문제는 기본 복제본(replica)에 영향을 주지 않습니다.

비동기 커밋 보조 복제본(replica)은 주 복제본(replica)으로부터 받은 로그 레코드를 따라잡으려고 시도합니다. 그러나 비동기 커밋 보조 데이터베이스는 항상 다시 동기화되지 않은 상태로 있으며 해당 주 데이터베이스보다 다소 뒤쳐질 수 있습니다. 일반적으로 비동기 커밋 보조 데이터베이스와 해당 주 데이터베이스 간의 시간차는 작은 편입니다. 그러나 보조 복제본(replica)을 호스팅하는 서버가 과부하되거나 네트워크가 속도가 느려지면 이 시간차가 커질 수 있습니다.

비동기 커밋 모드에서 지원하는 유일한 장애 조치(failover) 형식은 강제 장애 조치(failover)(데이터 손실될 수 있음)입니다. 강제 장애 조치(failover)는 현재 주 복제본(replica)을 상당 기간 사용할 수 없으며 데이터 손실의 위험보다는 주 데이터베이스의 가용성이 더 중요한 경우에만 최후의 수단으로서 사용해야만 합니다. 장애 조치(Failover) 대상은 역할이 SECONDARY 또는 RESOLVING 상태인 복제본이어야 합니다. 이때 장애 조치(Failover) 대상은 주 역할로 전환되며 해당 데이터베이스 복사본이 주 데이터베이스가 됩니다. 이전의 주 데이터베이스와 함께 나머지 보조 데이터베이스가 일단 사용 가능하게 된 경우사용자가 개별 데이터베이스를 수동으로 다시 시작할 때까지 일시 중지됩니다. 비동기 커밋 모드에서는 원래 주 복제본(replica)이 아직 이전 보조 복제본(replica)으호 보내지 않은 트랜잭션 로그가 손실됩니다. 즉, 최근에 커밋된 트랜잭션이 새로운 주 데이터베이스의 일부 또는 모두에 없을 수도 있습니다. 강제 장애 조치(failover) 작동 방법과 최선의 사용 방법은 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)를 참조하세요.

동기-커밋 가용성 모드

동기-커밋 가용성 모드(동기-커밋 모드)에서는 보조 데이터베이스가 가용성 그룹에 조인한 후에 해당 주 데이터베이스를 따라잡고 SYNCHRONIZED 상태로 전환됩니다. 보조 데이터베이스는 데이터 동기화가 계속되는 한 SYNCHRONIZED로 유지됩니다. 그러면 지정된 주 데이터베이스에서 커밋된 모든 트랜잭션이 해당 보조 데이터베이스에서도 커밋됩니다. 지정된 보조 복제본(replica)의 모든 보조 데이터베이스가 동기화되면 보조 복제본(replica) 전체의 동기화 상태 상태가 HEALTHY가 됩니다.

섹션 내용

데이터 동기화를 방해하는 요인

모든 데이터베이스가 동기화되면 보조 복제본(replica) HEALTHY 상태가 됩니다. 다음 중 하나가 발생하지 않는 한 동기화된 보조 복제본(replica)은 정상으로 유지가 됩니다:

  • 네트워크 또는 컴퓨터 지연 또는 결함으로 인해 보조 복제본(replica)과 주 복제본(replica) 간의 세션 시간이 초과됩니다.

    참고 항목

    가용성 복제본의 세션-시간 속성에 대한 자세한 내용은 Always On 가용성 그룹 개요(SQL Server)를 참조하세요.

  • 보조 복제본(replica)에서 보조 데이터베이스를 일시 중지합니다. 보조 복제본(replica)이 더 이상 동기화되지 않고 해당 동기화 상태 상태가 NOT_HEALTHY로 표시됩니다. 일시 중지된 보조 데이터베이스가 다시 시작되고 다시 동기화되거나 가용성 그룹에서 제거될 때까지 해당 보조 복제본은 다시 정상이 될 수 없습니다.

  • 가용성 그룹에 주 데이터베이를 추가합니다. 이전에 동기화된 보조 복제본은 NOT_HEALTHY 동기화 상태가 됩니다. 이 상태는 하나 이상의 데이터베이스가 NOT SYNCHRONIZING 동기화 상태에 있음을 나타냅니다. 지정된 보조 복제본은 복제본에서 해당 보조 데이터베이스가 준비되고, 가용성 그룹에 조인하며, 새로운 주 데이터베이스와 동기화될 때까지 다시 HEALTHY가 될 수 없습니다.

  • 주 복제본(replica) 또는 보조 복제본(replica) 비동기 커밋 가용성 모드로 변경합니다. 비동기 커밋 모드로 변경한 후에는 데이터 동기화가 계속되는 한 보조 복제본은 정상 동기화 상태로 유지됩니다. 그러나 주 복제본만 비동기-커밋 모드로 변경되는 경우에는 동기-커밋 보조 복제본이 PARTIALLY_HEALTHY 동기화 상태가 됩니다. 이 상태는 하나 이상의 데이터베이스가 SYNCHRONIZING 동기화 상태에 있지만 어떤 데이터베이스도 NOT SYNCHRONIZING 상태에 있지 않음을 나타냅니다.

  • 보조 복제본(replica)을 동기-커밋 가용성 모드로 변경합니다. 이렇게 하면 모든 데이터베이스가 SYNCHRONIZED 동기화 상태에 있을 때까지 보조 복제본이 PARTIALLY_HEALTHY 동기화 상태로 표시됩니다.

팁

가용성 그룹, 가용성 복제본 또는 가용성 데이터베이스의 동기화 상태를 보려면 각각 sys.dm_hadr_availability_group_states , sys.dm_hadr_availability_replica_states 또는 sys.dm_hadr_database_replica_states의 synchronization_health또는 synchronization_health_desc열을 쿼리합니다.

보조 복제본에서 동기화가 작동하는 방법

동기-커밋 모드에서는 보조 복제본을 가용성 그룹에 조인하고 주 복제본과의 세션을 설정하고 나면 보조 복제본은 들어오는 로그 레코드를 디스크에 기록하고(로그 확정) 확인 메시지를 주 복제본으로 보냅니다. 보조 데이터베이스의 확정된 로그가 주 데이터베이스의 로그 끝을 따라잡으면 보조 데이터베이스의 상태가 SYNCHRONIZED로 설정됩니다. 동기화에 필요한 시간은 세션을 초기화할 때 보조 데이터베이스와 주 데이터베이스 간의 격차(처음에 주 복제본으로부터 받은 로그 레코드 수로 측정), 주 데이터베이스의 작업 로드 및 보조 복제본을 호스팅하는 서버 인스턴스 컴퓨터의 속도에 따라 달라집니다.

동기화 작업은 다음 방식으로 유지 관리됩니다.

  1. 클라이언트로부터 트랜잭션을 받자마자 주 복제본은 트랜잭션에 대한 로그를 트랜잭션 로그에 쓰고 이와 동시에 로그 레코드를 보조 복제본으로 보냅니다.

  2. 주 데이터베이스의 트랜잭션 로그에 로그 레코드가 작성되면 현재 시점에서 해당 로그를 받지 못한 보조 데이터베이스로의 장애 조치가 있을 경우에만 트랜잭션을 실행 취소할 수 있습니다. 주 복제본(replica)은 동기 커밋 보조 복제본(replica)의 확인을 기다립니다.

  3. 보조 복제본(replica) 로그를 강화하고 주 복제본(replica)의 승인을 반환합니다.

  4. 보조 복제본(replica) 확인을 받자마자 주 복제본(replica)은 커밋 처리를 완료하고 확인 메시지를 클라이언트에게 보냅니다.

    참고 항목

    동기-커밋 보조 복제본이 로그를 확정했음을 확인하지 않은 상태에서 제한 시간이 만료되면 주 복제본이 해당 보조 복제본을 실패한 것으로 표시합니다. 보조 복제본의 연결 상태가 DISCONNECTED로 변경되고, 주 복제본이 보조 복제본의 확인을 더 이상 기다리지 않습니다. 이 동작은 실패한 동기-커밋 보조 복제본으로 인해 주 복제본에서 트랜잭션 로그가 확정되지 않는 것을 방지합니다.

동기-커밋 모드에서는 트랜잭션 대기 시간이 다소 늘어나더라도 두 위치의 데이터가 동기화되도록 하여 데이터를 보호합니다.

수동 장애 조치를 사용하는 동기-커밋 모드

이들 복제본이 연결되어 있으며 데이터베이스가 동기화된 경우 수동 장애 조치가 지원됩니다. 보조 복제본의 작동이 중단된 경우 주 복제본은 영향을 받지 않습니다. SYNCHRONIZED 상태의 복제본이 없으면 주 복제본이 표시된 상태로, 즉 데이터를 보조 복제본에 보내지 않고 실행됩니다. 주 복제본이 손실되면 보조 복제본이 RESOLVING 상태에 진입한 경우 데이터베이스 소유자가 보조 복제본으로의 강제 장애 조치를 실행할 수 있고 이 경우 데이터가 손실될 수 있습니다. 자세한 내용은 장애 조치(failover) 및 장애 조치(failover) 모드(Always On 가용성 그룹)를 참조하세요.

자동 장애 조치를 사용하는 동기-커밋 모드

자동 장애 조치를 사용하면 주 복제본이 손실되어도 데이터베이스를 신속하게 다시 사용함으로써 고가용성이 보장됩니다. 자동 장애 조치에 대해 가용성 그룹을 구성하기 위해서는 현재 주 복제본과 최소 하나의 보조 복제본을 모두 자동 장애 조치를 사용하는 동기-커밋 모드로 설정해야 합니다. SQL Server 2019(15.x)는 2017년 SQL Server 3개(14.x)에서 최대 동기 복제본 수를 5개로 증가했습니다. 그룹 내에서 자동 장애 조치가 실행되도록 이 그룹을 5개 복제본으로 구성할 수 있습니다. 주 복제본(replica) 하나와 동기 보조 복제본(replica) 4개가 있습니다.

또한 특정 시점에 자동 장애 조치가 가능하려면 이 보조 복제본을 주 복제본과 동기화하고, 즉 보조 데이터베이스를 모두 동기화하고 WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터에 쿼럼이 있어야 합니다. 이러한 조건에서 주 복제본을 사용할 수 없는 경우 자동 장애 조치(failover)가 발생합니다. 보조 복제본이 주 복제본의 역할로 전환하여 해당 데이터베이스를 주 데이터베이스로 제공합니다. 자세한 내용은 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹) 항목의 "자동 장애 조치(Failover)" 섹션을 참조하세요.

참고 항목

WSFC 쿼럼 및 Always On 가용성 그룹에 대한 자세한 내용은 WSFC 쿼럼 모드 및 투표 구성(SQL Server)을 참조하세요.

보조 복제본의 데이터 대기 시간

읽기 전용 워크로드에서 일부 데이터 대기 시간을 허용할 수 있는 경우 보조 복제본(replica) 대한 읽기 전용 액세스를 구현하는 것이 좋습니다. 데이터 대기 시간이 허용 가능하지 않은 경우에는 주 복제본에 대해 읽기 전용 작업을 실행하는 것이 좋습니다.

주 복제본(replica)은 주 데이터베이스의 변경 내용에 대한 로그 레코드를를 보조 복제본(replica)으로 전송합니다. 각 보조 데이터베이스에서 전용 다시 실행 스레드가 이 로그 레코드를 적용합니다. 읽기 액세스 보조 데이터베이스에서는 변경 내용이 포함된 로그 레코드가 보조 데이터베이스에 적용되고 트랜잭션이 주 데이터베이스에서 커밋될 때까지는 쿼리 결과에 지정된 데이터 변경 내용이 나타나지 않습니다.

이로 인해 주 복제본과 보조 복제본 사이에는 대개 몇 초 내외의 대기 시간이 있습니다. 하지만 네트워크 문제로 인해 처리량이 줄어드는 경우와 같은 특수한 경우에는 대기 시간이 중요할 수 있습니다. I/O 병목 현상이 발생하고 데이터 이동이 일시 중단될 때 대기 시간이 증가합니다. 일시 중단된 데이터 이동을 모니터링하려면 Always On 대시보드 또는 sys.dm_hadr_database_복제본(replica)_states 동적 관리 뷰를 사용하시면 됩니다.

보조 복제본의 다시 실행 대기 시간을 조사하는 방법에 대한 자세한 내용은 보조 복제본에 반영되지 않은 기본 변경 내용 문제 해결을 참조하세요.

관련 작업

가용성 모드 및 장애 조치(failover) 모드를 변경하려면

쿼럼 투표를 조정하려면

수동 장애 조치(failover)를 실행하려면

가용성 그룹, 가용성 복제본(replica) 및 데이터베이스 상태를 보려면

관련 내용

참고 항목

Always On 가용성 그룹 개요(SQL Server)
장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)
SQL Server의 WSFC(Windows Server 장애 조치(Failover) 클러스터링)