SQL Server Always On: DBA를 위한 완벽 가이드 [2026]

SQL Server Always On은 마이크로소프트가 2015년에 출시한 포괄적인 고가용성 및 재해 복구 솔루션입니다. SQL Server 2012년에 개발된 이 기술은 데이터베이스 미러링 및 로그 전송과 같은 기존 기술에 비해 상당한 발전을 이루었으며, 가동 중지 시간과 데이터 손실을 최소화하면서 데이터에 대한 지속적인 접근을 보장합니다.

1.2 기업에 상시 접속 솔루션이 필요한 이유

오늘날의 디지털 경제에서 데이터베이스 다운타임은 곧 손실로 직결됩니다.ost 매출 감소, 평판 손상, 규정 준수 문제 등 다양한 문제를 야기할 수 있습니다. 조직은 다양한 장애 시나리오로부터 보호하면서 거의 지속적인 가동 시간을 보장할 수 있는 고가용성 솔루션이 필요합니다.

기존의 백업 및 복구 절차는 현대 비즈니스 요구 사항을 충족하기에 충분하지 않습니다. 중요한 데이터베이스에 장애가 발생했을 때, 기업은 백업에서 복구하는 데 필요한 몇 시간을 기다릴 여유가 없습니다. Always On 솔루션은 자동화된 장애 조치 기능을 제공하여 몇 시간이 아닌 몇 초 또는 몇 분 만에 서비스를 복구할 수 있도록 함으로써 시스템 장애의 영향을 획기적으로 줄입니다.

기업은 기본적인 가용성 확보 외에도 프로덕션 데이터베이스에서 읽기 작업이 많은 워크로드를 분산시키고, 다운타임 없이 유지 보수를 수행하며, 사이트 수준의 재해로부터 보호해야 합니다. SQL Server Always On은 소규모 배포부터 전 세계적으로 분산된 시스템에 이르기까지 확장 가능한 통합 아키텍처를 통해 이러한 모든 요구 사항을 해결합니다.

1.3 핵심 개념: RTO, RPO, HA 및 DR

RTO (복구 시간 목표) 장애 발생 후 허용 가능한 최대 다운타임 시간, 즉 데이터베이스가 얼마나 빨리 다시 온라인 상태로 복구되어야 하는지를 정의합니다.

RPO (복구 지점 목표) 시간 경과에 따른 최대 허용 데이터 손실량을 정의합니다. 즉, 기업이 최근에 저장된 데이터의 손실을 얼마나 감당할 수 있는지를 나타냅니다.

고가용성(HA) 동일한 데이터 센터 내에서 하드웨어 오작동이나 소프트웨어 충돌과 같은 일상적인 오류로 인한 다운타임을 최소화하는 데 중점을 둡니다.

재해 복구(DR) 고가용성(HA)은 전체 사이트에 영향을 미치는 재해를 해결하고 지리적으로 분산된 위치에 데이터 복사본을 유지합니다. 재해 복구(DR)는 다운타임을 최소화하는 데 중점을 두는 반면, 주요 사고 발생 시 데이터 보호 및 비즈니스 연속성을 보장하는 데 중점을 둡니다.

SQL Server Always On은 단일 통합 아키텍처 내에서 고가용성(HA)과 재해 복구(DR)를 모두 지원합니다. 동기식 커밋 모드는 자동 페일오버를 통해 거의 제로에 가까운 RTO를 달성하여 RPO(복구 목표 시점)를 0으로 제공합니다. 비동기식 커밋 모드는 원거리 사이트 간 지연 시간을 줄이는 대신 데이터 손실 가능성을 감수합니다.

1.4 상시 가동 솔루션

SQL Server Always On은 가용성 및 인프라 요구 사항이 서로 다른 세 가지 배포 옵션을 제공합니다. 이 가이드에서는 세 가지 옵션 모두를 다룹니다.

상시 가동 가능 그룹(AG): 공유 스토리지 없이 데이터베이스 수준의 고가용성 및 재해 복구를 제공합니다.
상시 작동 장애 조치 클러스터 인스턴스(FCI): 공유 스토리지를 사용한 인스턴스 수준의 고가용성.
AG + FCI 합산: 인스턴스 수준 및 데이터베이스 수준 장애 조치를 결합한 2단계 보호 기능으로 최대의 복원력을 제공합니다.

2. 상시 접속 가능 그룹

상시 가동 가능 그룹(AG) 이 솔루션은 데이터베이스 수준의 고가용성 및 재해 복구 솔루션으로, 지속적인 트랜잭션 로그 전송을 통해 사용자 데이터베이스 세트를 최대 8개의 보조 복제본으로 복제합니다.

2.1 주요 기능

데이터베이스 수준 장애 조치: 개별 데이터베이스 또는 그룹은 전체 시스템 전체와 독립적으로 장애 조치를 수행할 수 있습니다. SQL Server 사례;
엔터프라이즈 에디션에서는 최대 9개의 복제본(기본 1개, 보조 8개)을 생성할 수 있습니다.
데이터 손실이 없는 동기식 커밋 모드; 원격 재해 복구 복제본을 위한 비동기식 커밋 모드;
기본 복제본을 사용할 수 없게 될 경우 동기 복제본에 대한 자동 페일오버 기능;
보고 및 백업 워크로드를 분산 처리하기 위한 읽기 가능한 보조 복제본;
가용성 그룹 리스너는 현재 기본 서버로 자동 연결되는 단일 연결 엔드포인트를 제공합니다.

2.2 구현 단계

Active Directory 서비스 계정을 준비하고 모든 노드에 권한을 구성합니다.
참여하는 모든 서버에 Windows Server 장애 조치 클러스터링을 설치하고 유효성을 검사합니다.
설치 SQL Server 각 노드에서 일관된 경로 및 설정을 사용하여 독립 실행형 인스턴스로 운영됩니다.
Always On 가용성 그룹 기능을 활성화하려면 다음을 통해 진행하세요. SQL Server Configuration Manager 또는 PowerShell;
데이터베이스를 전체 복구 모델로 설정하고 전체 백업 및 로그 백업을 수행합니다.
가용성 그룹을 생성하고, 복제본을 추가하고, 가용성 및 장애 조치 모드를 구성합니다.
자동 시딩 또는 수동 백업 및 복원을 사용하여 보조 복제본을 시딩합니다.
가용성 그룹 리스너를 생성하고 클라이언트 연결을 확인합니다.

자세한 단계별 안내는 다음을 참조하세요. 상시 접속 가능 그룹 완벽 가이드.

2.3 가장 적합

데이터 손실 제로 및 자동 장애 조치가 요구되는 핵심 업무용 데이터베이스;
보고 또는 백업 오프로딩을 위해 읽기 가능한 보조 스토리지가 필요한 워크로드;
재해 복구를 위해 여러 사이트에 걸쳐 배포;
기존에 공유 스토리지 인프라가 없는 환경.

2.4 전문가

공유 스토리지가 필요하지 않습니다. 각 복제본은 독립적인 로컬 스토리지를 사용합니다.
단일 구성으로 고가용성(HA)과 재해 복구(DR)를 모두 지원합니다.
읽기 쉬운 보조 데이터는 기본 작업 부하를 줄여줍니다.
데이터베이스 수준의 세분성을 통해 데이터베이스 그룹별로 서로 다른 장애 조치 정책을 적용할 수 있습니다.

2.5 단점

모든 기능을 사용하려면 엔터프라이즈 에디션이 필요합니다(스탠다드 에디션은 상당한 제한 사항이 있는 기본 AG만 지원합니다).
동기식 커밋 모드는 네트워크 왕복 시간에 비례하는 쓰기 지연 시간을 추가합니다.
로그인, SQL Agent 작업 및 연결된 서버는 수동 동기화가 필요합니다. SQL Server 2019년 이전;
모든 복제본은 동일한 Windows Server 장애 조치 클러스터의 노드에 있어야 합니다.

2.6 참고 문헌

마이크로소프트 공식 문서: Always On 가용성 그룹이란 무엇입니까?
마이크로소프트 공식 문서: S를 얻는다tarAlways On Availability Groups를 사용하여 테드(Ted)

3. 상시 가동 장애 조치 클러스터 인스턴스

상시 작동 장애 조치 클러스터 인스턴스(FCI) 단일 인스턴스를 실행하여 인스턴스 수준의 고가용성을 제공합니다. SQL Server 동일한 스토리지를 공유하는 여러 물리적 노드에 걸쳐 인스턴스가 실행됩니다. 활성 노드에 장애가 발생하면, SQL Server 대기 노드의 인스턴스는 자동으로 재설설정됩니다.tar테드는 클라이언트 애플리케이션에 전환 과정이 투명하게 이루어지도록 합니다.

3.1 주요 기능

인스턴스 수준 장애 조치: 인스턴스의 모든 데이터베이스가 단일 단위로 함께 장애 조치됩니다.
모든 노드에서 액세스 가능한 공유 스토리지(SAN(Storage Area Network), iSCSI, Storage Spaces Direct 또는 SMB)
가상 네트워크 이름과 가상 IP 주소는 어떤 노드가 활성화되어 있든 안정적인 연결 종단점을 제공합니다.
Windows Server 장애 조치 클러스터링은 노드 상태 모니터링, 쿼럼 및 장애 조치 오케스트레이션을 관리합니다.
액티브/스탠바이, 액티브/액티브, N+1 및 N+M 노드 구성 유형을 지원합니다.

3.2 구현 단계

클러스터의 모든 노드에 공유 스토리지를 프로비저닝하고 연결합니다.
장애 조치 클러스터링 기능을 설치하고 클러스터 구성을 검증합니다.
Windows Server 장애 조치 클러스터를 생성하고 쿼럼을 구성합니다.
실행하다 SQL Server 장애 조치 클러스터 옵션을 선택하고 가상 네트워크 이름과 공유 스토리지 경로를 지정하여 설치합니다.
노드를 추가하세요 SQL Server 장애 조치 클러스터 인스턴스;
노드 간 수동 페일오버를 테스트하여 페일오버 동작을 검증하십시오.

자세한 단계별 안내는 다음을 참조하세요. SQL Server 장애 조치 클러스터 완벽 가이드.

3.3 가장 적합

기존 공유 스토리지 인프라(SAN 또는 iSCSI)가 구축된 환경;
모든 데이터베이스가 동시에 장애 조치를 받아야 하는 인스턴스 수준의 장애 조치가 필요한 애플리케이션;
고객 투명성이 매우 중요하고 애플리케이션 측 변경이 허용되지 않는 시나리오;
단일 인스턴스 장애 조치 모델의 단순성을 우선시하는 조직.

3.4 전문가

클라이언트 재구성 없이 인스턴스 수준에서 자동 장애 조치가 가능합니다.
데이터 복제 오버헤드가 없습니다. 모든 노드가 동일한 스토리지에 액세스합니다.
모든 데이터베이스에 대해 동시에 예측 가능한 장애 조치 동작을 제공합니다.
하드웨어 활용도를 최적화하기 위해 유연한 노드 구성(액티브/액티브, N+1, N+M)을 지원합니다.

3.5 단점

공유 스토리지는 스토리지 자체에 이중화가 되어 있지 않으면 잠재적인 단일 장애 지점이 될 수 있습니다.
하나의 노드만 실행됩니다. SQL Server 한 번에 하나씩 - 보조 노드에서 읽기 로드 밸런싱 없음;
가용성 그룹과 연동하지 않으면 내장된 재해 복구 기능이 없습니다.
공유 스토리지 인프라가 추가됩니다.ost AG에 비해 복잡성이 더 높습니다.

3.6 참고 문헌

마이크로소프트 공식 문서: 상시 작동 장애 조치 클러스터 인스턴스(SQL Server)

4. 가용성 그룹을 장애 조치 클러스터 인스턴스와 결합

인스턴스 수준 및 데이터베이스 수준 보호가 모두 필요한 조직의 경우, SQL Server h를 지원합니다ost장애 조치 클러스터 인스턴스(FCI)에 가용성 그룹 복제본을 배치합니다. 이 구성에서 각 FCI 노드는 단일 가용성 복제본 역할을 하므로 FCI 장애 조치는 가용성 그룹에 투명하게 처리되는 반면, AG 장애 조치는 사이트 전체에 걸쳐 데이터베이스 수준의 보호 기능을 제공합니다. 이러한 조합은 최상의 성능을 제공합니다.ost 포괄적인 고가용성 및 재해 복구 서비스가 제공됩니다. SQL Server.

4.1 주요 기능

2계층 페일오버: FCI는 인스턴스 수준 노드 장애를 처리하고, AG는 사이트 수준 또는 복제본 수준 장애를 처리합니다.
각 FCI는 해당 FCI에 포함된 노드 수와 관계없이 가용성 그룹 내에서 단일 복제본으로 간주됩니다.
FCI-hosted 복제본은 표준 FCI 요구 사항에 따라 여전히 공유 스토리지가 필요합니다.
AG 복제본 hostFCI는 수동 페일오버만 지원하며, FCI-h에서는 자동 페일오버를 사용할 수 없습니다.osted 복제품;
독립 실행형 인스턴스는 FCI-h와 함께 동일한 가용성 그룹에 참여할 수 있습니다.osted 복제품.

4.2 구현 단계

표준 FCI 설정 절차에 따라 각 FCI를 독립적으로 배포하고 검증하십시오.
모든 FCI 노드와 독립 실행형 복제 노드가 동일한 Windows Server 장애 조치 클러스터에 속하도록 합니다.
각 FCI 인스턴스에서 Always On 가용성 그룹 기능을 활성화하십시오.
어떤 WSFC 노드도 h가 되지 않도록 확인합니다.ost FCI 장애 조치 후 동일한 가용성 그룹의 복제본 두 개;
가용성 그룹을 생성하고, FCI 인스턴스를 복제본으로 지정하며, 모든 FCI-h에 대해 수동 페일오버 모드를 구성합니다.osted 복제품;
보조 복제본을 시드하고 가용성 그룹 리스너를 구성합니다.

FCI 설정에 대한 자세한 내용은 당사 웹사이트를 참조하십시오. SQL Server 장애 조치 클러스터 완벽 가이드. AG 설정에 대한 자세한 내용은 Always On 가용성 그룹 완벽 가이드를 참조하십시오.

4.3 가장 적합

개별 노드 장애 및 사이트 수준의 재해로부터 보호가 필요한 핵심 임무 환경;
이미 FCI를 실행 중인 조직 중 사이트 간 재해 복구 기능을 추가해야 하는 조직
데이터 보호 및 가용성 SLA가 최고 수준으로 요구되는 규제 산업 분야;
인스턴스 수준 및 데이터베이스 수준 장애 조치 정책이 공존해야 하는 대규모 배포 환경.

4.4 전문가

최대 보호 기능: 노드 장애는 FCI에서 처리하고, 사이트 장애는 AG에서 처리합니다.
FCI 페일오버는 가용성 그룹에 투명하게 처리됩니다. 즉, AG는 FCI 페일오버 중에 복제본 변경 사항을 감지하지 못합니다.
유연한 토폴로지: FCI-h 혼합ost동일한 가용성 그룹에 있는 ed 및 독립 실행형 복제본.

4.5 단점

FCI-hosted 복제본은 수동 AG 페일오버만 지원하며, 이러한 복제본에서는 자동 AG 페일오버를 사용할 수 없습니다.
단일 노드가 h에 빠지는 것을 방지하려면 WSFC 노드 계획을 신중하게 세워야 합니다.ostFCI 페일오버 후 동일한 AG의 복제본 두 개를 생성합니다.
더 높은 인프라 cost 또한 AG나 FCI 단독으로 사용할 때보다 운영상의 복잡성이 더 높습니다.
FCI 구성 요소 각각에 대해 공유 스토리지가 여전히 필요합니다.

4.6 참고 문헌

마이크로소프트 공식 문서: 장애 조치 클러스터링 및 상시 가동 가용성 그룹(SQL Server)
마이크로소프트 공식 문서: Always On 가용성 그룹이란 무엇입니까?
마이크로소프트 공식 문서: S를 얻는다tarAlways On Availability Groups를 사용하여 테드(Ted)
마이크로소프트 공식 문서: 상시 작동 장애 조치 클러스터 인스턴스(SQL Server)

5. 상시 접속 솔루션 비교

5.1 기능 비교표

제품 특장점	가용성 그룹	장애 조치 클러스터 인스턴스	AG + FCI 결합
장애 조치 범위	데이터베이스 수준	인스턴스 수준	모두
공유 스토리지 필요	아니	가능	예 (FCI 구성 요소의 경우)
데이터 복제	각 복제본에 대한 로그 기반	없음(공유 저장소)	FCI 간 로그 기반
자동 장애 조치	예 (동기 복제본)	가능	FCI: 예; AG: 아니오
읽기 쉬운 보조 이미지	가능	아니	예 (AG 구성 요소)
재해 복구	내장	내장되지 않음	내장
맥스 복제품	9 (엔터프라이즈)	N/A	9 (엔터프라이즈)
인프라 복잡성	중급	중급	높음
Cost	더 낮은 수준 (SAN 불필요)	상위 (SAN 필요)	최고

5.2 상시 연결 솔루션 선택

Star스토리지 인프라와 호환성을 고려하세요. 기존에 공유 스토리지가 없다면 가용성 그룹이 가장 적합한 선택입니다.ost cost고가용성(HA)과 재해 복구(DR) 모두에 효과적인 경로입니다. 이미 SAN 환경을 운영 중이고 인스턴스 수준 페일오버가 필요한 경우 FCI가 더 간단한 옵션이지만, 향후 사이트 간 재해 복구가 필요한 경우 나중에 AG를 추가하는 것을 고려해야 합니다.

AG + FCI 조합은 두 가지 보호 계층이 모두 필요하고 증가된 복잡성을 관리할 수 있는 운영 역량이 충분할 때만 선택하십시오. 기억해야 할 핵심 제약 조건은 FCI-h가osted AG 복제본은 자동 AG 페일오버를 지원하지 않으므로 이 토폴로지에서는 가용성 그룹 수준의 페일오버를 위해 수동 개입이 필요합니다.

most 오늘날 신규 구축 환경에서는 Always On Availability Groups가 권장됩니다.tar핵심은 HA와 DR을 모두 지원하고, 공유 스토리지가 필요 없으며, 읽기 가능한 세컨더리를 지원한다는 점입니다. 이러한 기능은 FCI만으로는 따라올 수 없습니다.

6. 모범 사례 SQL Server 상시 가동 솔루션

6.1 계획 및 설계

상시 가동 솔루션을 선택하기 전에 RTO 및 RPO 요구 사항을 정의하십시오. tar이를 통해 동기식 또는 비동기식 커밋 모드가 적절한지, 그리고 자동 장애 조치가 가능한지 여부를 직접적으로 판단할 수 있습니다.
장애 조치 이벤트 발생 시, 최대 부하 시나리오를 포함하여 기본 시스템의 전체 워크로드를 처리할 수 있도록 보조 복제본의 크기를 조정하십시오.
AG 배포 시 쓰기 지연 시간 영향을 최소화하려면 동기식 복제본을 동일한 데이터 센터 또는 저지연 네트워크 내에 배치하십시오. 지리적으로 멀리 떨어진 재해 복구(DR) 복제본에는 비동기 모드를 사용하십시오.
홀수 개의 투표로 쿼럼을 구성하십시오. 2노드 클러스터의 경우, 스플릿 브레인 현상을 방지하기 위해 파일 공유 또는 클라우드 감시 서버를 세 번째 투표로 추가하십시오.
다중 서브넷 배포를 위한 네트워크 토폴로지를 신중하게 계획하십시오. 각 서브넷에는 고유한 수신 IP 주소가 필요하며, 클라이언트는 연결 문자열에 MultiSubnetFailover=True를 포함해야 합니다.

6.2 실행 지침

일관성을 사용하세요 SQL Server 모든 복제본의 버전, 에디션 및 누적 업데이트 수준을 일치시켜야 합니다. 패치 수준이 혼합되면 장애 조치 중에 예기치 않은 동작이 발생할 수 있습니다.
클러스터 하트비트 트래픽을 위한 전용 네트워크 인터페이스를 애플리케이션 트래픽과 분리하여 구성하십시오.
초기 데이터베이스 동기화를 위한 자동 시드 기능을 활성화합니다. SQL Server 2016년 이후 버전에서는 백업 파일을 보조 복제본으로 수동으로 복사할 필요가 없어집니다.ost 시나리오.
AG + FCI 토폴로지의 경우, FCI 노드 구성 변경 후 어떤 WSFC 노드도 h 상태가 되지 않도록 확인해야 합니다.ost동일한 가용성 그룹의 복제본 두 개를 생성합니다.
항상 사용 SQL Server 가용성 그룹 장애 조치를 관리하려면 Management Studio 또는 Transact-SQL을 사용하십시오. 장애 조치 클러스터 관리자는 가용성 그룹 동기화 상태를 인식하지 못하므로 직접 사용하지 마십시오. 장애 조치 클러스터 관리자는 가동 중지 시간이 길어지거나 데이터 손실이 발생할 수 있습니다.

6.3 모니터링 및 유지보수

가용성 그룹 대시보드를 사용하여 동기화 상태, 전송 큐 및 리두 큐를 정기적으로 모니터링하세요. SQL Server Management Studio 또는 동적 관리 뷰(DMV)에서 리두 큐가 증가하는 것은 I/O 병목 현상이 발생하여 페일오버 복구가 지연될 수 있음을 나타냅니다.
기본 복제본의 무결성 검사 부담을 줄이기 위해 보조 복제본에서 DBCC CHECKDB를 실행하십시오. 자세한 내용은 당사 웹사이트를 참조하십시오. DBCC CHECKDB 가이드 를 참조하세요
신청 SQL Server 롤링 업그레이드를 사용한 패치: 먼저 보조 복제본에 패치를 적용하고, 계획된 수동 페일오버를 통해 패치가 적용된 보조 복제본으로 전환한 다음, 이전 기본 복제본에 패치를 적용합니다. 이렇게 하면 다운타임을 단일 페일오버 시간으로 제한할 수 있습니다.
비운영 환경에서 정기적으로 페일오버를 테스트하십시오. 테스트되지 않은 자동 페일오버는 신뢰할 수 있는 복구 전략이 아닙니다.
가용성 그룹 상태 변경, 복제본 역할 전환 및 동기화 실패에 대한 알림을 구성하려면 다음을 사용하십시오. SQL Server 에이전트 또는 전용 모니터링 도구(예: ...) SQL Server Performance Monitor (성능 모니터).

7. 자주하는 질문

Q : 무엇입니까 SQL Server 항상 켜져 있나요?

A: SQL Server Always On은 마이크로소프트가 2008년에 출시한 고가용성 및 재해 복구 플랫폼입니다. SQL Server 2012년에 도입된 이 기술은 Always On Availability Groups와 Always On Failover Cluster Instances라는 두 가지 기술을 포함하며, 하드웨어, 소프트웨어 또는 사이트 장애 발생 시 자동 장애 조치, 데이터 이중화 및 데이터베이스에 대한 지속적인 액세스를 제공합니다.

Q: Always On 가용성 그룹과 장애 조치 클러스터 인스턴스의 차이점은 무엇입니까?

A: 가용성 그룹(AG)은 데이터베이스 수준에서 작동하며, 로그 전송을 통해 독립적인 보조 복제본으로 데이터를 복제하고 공유 스토리지가 필요하지 않습니다. 장애 조치 클러스터 인스턴스(FCI)는 인스턴스 수준에서 작동하며, 모든 노드에서 접근 가능한 공유 스토리지가 필요하고, 모든 데이터베이스를 하나의 단위로 장애 조치합니다. AG는 읽기 가능한 보조 복제본과 내장된 재해 복구(DR) 기능을 지원하지만, FCI는 지원하지 않습니다.

Q: Always On 가용성 그룹에 공유 스토리지가 필요한가요?

A: 아니요. 각 AG 복제본은 로컬 스토리지에 데이터베이스의 독립적인 복사본을 유지합니다. 공유 스토리지는 장애 조치 클러스터 인스턴스를 사용하는 경우에만 필요합니다.ost AG 복제품.

Q: Always On 기능을 다음 기능과 함께 사용할 수 있나요? SQL Server 일반판인가요?

A: SQL Server Standard Edition은 기본 가용성 그룹을 지원합니다.tar팅 SQL Server 2016년 버전과 유사하지만 몇 가지 중요한 제약 사항이 있습니다. AG당 데이터베이스는 하나만 사용할 수 있고, 복제본은 최대 두 개까지만 지원하며, 읽기 가능한 보조 복제본은 지원하지 않습니다. FCI는 이러한 제약이 없는 Standard Edition에서 사용할 수 있습니다. 완전한 Always On 기능을 사용하려면 Enterprise Edition이 필요합니다.

질문: 가용성 그룹에 포함될 수 있는 최대 복제본 수는 몇 개입니까?

A: SQL Server 엔터프라이즈 에디션은 기본 복제본 1개와 보조 복제본 8개를 포함하여 최대 9개의 복제본을 지원합니다. 분산 가용성 그룹을 사용하면 두 개의 별도 가용성 그룹에 걸쳐 최대 18개의 복제본까지 확장할 수 있습니다.

질문: FCI-h는 가능합니까?osted 복제본은 자동 AG 페일오버를 사용합니까?

A: 아니요. 가용성 복제본이 h인 경우.ost장애 조치 클러스터 인스턴스(FCI-h)에서 실행 중인 경우, 해당 복제본에 대해서는 자동 가용성 그룹 장애 조치가 지원되지 않습니다. FCI-h와 관련된 모든 AG 장애 조치는 자동 가용성 그룹 장애 조치를 지원합니다.osted 복제본은 수동 개입이 필요합니다.

질문: 동기식 커밋 모드와 비동기식 커밋 모드의 차이점은 무엇인가요?

A: 동기식 커밋 모드는 기본 서버가 보조 서버가 로그 레코드를 확정할 때까지 기다린 후 커밋하므로 커밋 시 데이터 손실이 전혀 발생하지 않습니다(RPO = 0).ost 쓰기 지연 시간이 추가됩니다. 비동기 커밋 모드는 기본 서버가 대기 없이 커밋할 수 있도록 하여 지연 시간을 줄이지만, 보조 서버가 모든 로그 레코드를 수신하기 전에 기본 서버에 장애가 발생하면 데이터 손실 위험이 있습니다. 로컬 고가용성(HA) 복제본에는 동기 모드를 사용하고, 원격 재해 복구(DR) 복제본에는 비동기 모드를 사용하십시오.

Q: 얼마나 오래 걸리나요? SQL Server Always On 장애 조치가 필요합니까?

A: 동기식 AG 복제본의 자동 페일오버는 일반적으로 정상적인 상황에서 30초 이내에 완료됩니다. FCI 페일오버는 데이터베이스 복구 시간에 따라 보통 20~60초가 소요됩니다. 실제 소요 시간은 워크로드, 데이터베이스 크기 및 WSFC에 구성된 상태 확인 시간 초과 설정에 따라 달라집니다.

질문: 장애 조치 중에 클라이언트 연결은 어떻게 되나요?

A: 장애 조치가 발생하면 기존 연결이 끊어집니다. 가용성 그룹 리스너를 사용하고 연결 재시도 로직을 포함하는 애플리케이션은 장애 조치가 완료된 후 새 기본 서버에 자동으로 다시 연결됩니다. 연결 문자열에 MultiSubnetFailover=True를 추가하면 다중 서브넷 배포 환경에서 재연결 속도가 향상됩니다.

Q: 어떻게 신청하나요? SQL Server 상시 가동 환경에서 다운타임을 최소화하면서 패치를 적용하는 방법은 무엇일까요?

A: 롤링 업그레이드를 사용하십시오. 먼저 보조 복제본에 패치를 적용한 다음, 계획된 수동 페일오버를 통해 패치가 적용된 보조 복제본으로 전환하고, 마지막으로 이전 기본 복제본에 패치를 적용합니다. 이렇게 하면 다운타임을 계획된 페일오버 한 번에 소요되는 시간(일반적으로 1분 미만)으로 제한할 수 있습니다.

Q: Always On 가용성 그룹과 장애 조치 클러스터 인스턴스를 결합할 수 있습니까?

A: 네. 가능합니다.ost AG 복제본은 FCI 인스턴스에 생성되어 인스턴스 수준 및 데이터베이스 수준의 장애 조치를 모두 보호합니다. 각 FCI는 하나의 AG 복제본으로 간주됩니다. 이 토폴로지는 단일 노드 장애 조치가 발생하지 않도록 WSFC 노드 계획을 신중하게 수립해야 합니다.ostFCI 페일오버 발생 후 동일한 AG의 복제본이 두 개 생성됩니다.

Q: Always On 환경에서 데이터베이스가 손상된 경우 어떻게 해야 하나요?

A: 먼저, 모든 복제본에 손상이 있는지 아니면 기본 복제본에만 손상이 있는지 확인하십시오. 정상적인 보조 복제본이 있는 경우 즉시 보조 복제본으로 페일오버하십시오. 모든 복제본에 손상이 있는 경우, 손상 초기 단계에서 복구하십시오. 보조 복제본에서 정기적으로 DBCC CHECKDB를 실행하여 손상을 조기에 발견하십시오. 백업에도 손상이 발생한 경우, 특수 백업을 실행해야 합니다. SQL Server 데이터 복구 도구 손상된 MDF 파일에서 데이터를 추출하는 것은 최후의 수단으로 시도할 수 있습니다.

Q: Always On Availability Groups는 기존 방식과 어떻게 다른가요? SQL Server HA 솔루션?

A: AG는 다음과 같은 기존 기술을 대체합니다. 통나무 운송 복제로그 전송은 수동 장애 조치가 필요하며 자동 역할 전환이 없습니다. 복제는 고가용성(HA)보다는 데이터 분산을 위해 설계되었습니다. AG는 자동 장애 조치, 동기식 커밋을 통한 데이터 손실 제로, 읽기 가능한 보조 저장소를 제공하며, 이러한 기능은 다른 기술들이 따라올 수 없습니다.

8. 결론

SQL Server Always On은 고가용성 및 재해 복구를 위한 유연한 엔터프라이즈급 플랫폼을 제공합니다. Always On Availability Groups는 다음과 같은 경우에 적합한 선택입니다.ost 최신 배포 환경에서는 공유 스토리지가 필요 없으며, 읽기 가능한 세컨더리를 지원하고, 단일 구성으로 로컬 고가용성(HA)과 사이트 간 재해 복구(DR)를 모두 처리합니다. 인스턴스 수준 페일오버와 기존 공유 스토리지 인프라가 주요 요구 사항인 경우 페일오버 클러스터 인스턴스는 여전히 안정적인 옵션입니다. 두 기술을 결합하면 최고 수준의 보호 기능을 제공합니다.ost 더 큰 규모의 인프라 투자와 운영상의 복잡성.

어떤 솔루션을 선택하든 기본 원칙은 동일합니다. 먼저 RTO 및 RPO 요구 사항을 정의하고, 그에 맞춰 토폴로지를 설계해야 합니다. tar정기적으로 장애 조치를 테스트하십시오. 철저한 테스트를 거친 잘 구현된 Always On 솔루션은 운영 장애 발생 시 예측 가능한 방식으로 복구됩니다.

저자에 관하여

위안 셩 10년 이상의 경력을 가진 선임 데이터베이스 관리자(DBA)입니다. SQL Server 환경 및 기업 데이터베이스 관리 분야에서 그는 금융 서비스, 의료, 제조 분야에서 수백 건의 데이터베이스 복구 시나리오를 성공적으로 해결했습니다.

원은 다음을 전문으로 합니다. SQL Server 데이터베이스 복구, 고가용성 솔루션, 성능 최적화 분야의 전문가입니다. 그는 수 테라바이트 규모의 데이터베이스 관리, Always On Availability Groups 구현, 미션 크리티컬 비즈니스 시스템을 위한 자동 백업 및 복구 전략 개발 등 풍부한 실무 경험을 보유하고 있습니다.

Yuan은 기술적 전문성과 실용적인 접근 방식을 통해 데이터베이스 관리자와 IT 전문가가 복잡한 문제를 해결하는 데 도움이 되는 포괄적인 가이드를 만드는 데 중점을 둡니다. SQL Server 효율적으로 도전합니다. 그는 최신 정보를 유지합니다. SQL Server Microsoft의 새로운 릴리스와 진화하는 데이터베이스 기술을 활용하고, 정기적으로 복구 시나리오를 테스트하여 권장 사항이 실제 모범 사례를 반영하는지 확인합니다.

에 대한 질문이 SQL Server 복구가 필요하거나 추가적인 데이터베이스 문제 해결 지침이 필요하신가요? Yuan이 환영합니다. 피드백과 제안 이러한 기술적 자원을 개선하기 위해.