SQL Server Always On 문제 해결
이 문서는 SQL Server Always On 구성에 대한 일반적인 문제를 resolve 데 도움이 됩니다.
참고
이 문서의 자세한 내용은 SQL Server Always On 문제 해결을 참조하세요.
원래 제품 버전: SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
원본 KB 번호: 10179
중요 참고 사항
Microsoft CSS 데이터는 고객 문제의 상당수가 이전에 릴리스된 CU에서 해결되었지만 사전에 적용되지 않았기 때문에 사용 가능해질 때 CU의 지속적인 사전 설치를 권장한다는 것을 나타냅니다. 자세한 내용은 SQL Server ISM(증분 서비스 모델)에 대한 업데이트 발표를 참조하세요.
버전에 사용할 수 있는 최신 CPU를 검사 SQL Server 및 해당 구성 요소의 버전, 버전 및 업데이트 수준을 확인하는 방법을 참조하세요.
다양한 유형의 문제를 진단하고가용성 그룹을 모니터링하는 데 사용할 수 있는 도구에 대해 자세히 알아보려면 Always On 가용성 그룹 문제 해결 및 모니터링 가이드에서 가용성 그룹 Always On 문제 해결 및 모니터링을 위한 유용한 도구를 참조하세요. 가이드에는 이 단계별 연습에서 다루지 않을 수 있는 추가 시나리오도 있습니다.
Always On 가용성 그룹에 대한 부모 노드 설명서와 다양한 질문에 대한 원스톱 참조를 제공합니다. Always On 가용성 그룹(SQL Server)을 참조하세요.
Always On 가용성 그룹 설정 및 구성에 대한 포인터가 필요합니다.
Always On 구성 설정에 대한 설명서를 찾으려면 다음 문서를 참조하세요.
Always On 가용성 그룹(SQL Server)을 사용하는 시작 - 이 문서에서는 가용성 그룹 및 설정에 대한 다양한 질문에 대한 답변을 제공합니다. 이 문서의 모든 단계를 수행하고 Always On 가용성 그룹(SQL Server)에 대한 필수 구성 요소, 제한 사항 및 권장 사항을 검토하면 사용자 환경에서 가용성 그룹을 설정하고 유지 관리하는 데 발생할 수 있는 많은 문제를 방지하는 데 도움이 됩니다.
추가 리소스
이 정보가 도움이 되지 않는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
Always On 가용성 그룹을 구성하는 데 문제가 있습니다.
일반적인 구성 문제는 Always On 가용성 그룹이 사용하지 않도록 설정되고, 계정이 잘못 구성되고, 데이터베이스 미러링 엔드포인트가 존재하지 않으며, 엔드포인트에 액세스할 수 없음(SQL Server 오류 1418), 네트워크 액세스가 존재하지 않으며, 데이터베이스 조인 명령이 실패(오류 35250 SQL Server)입니다. 이러한 문제 해결에 대한 도움말은 다음 문서를 검토하세요.
Always On 가용성 그룹 구성 문제 해결(SQL Server)
추가 링크: 수정: 여러 가용성 그룹을 만들려고 할 때 오류 41009
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
수신기 구성에 문제가 있습니다(19471, 19476 및 기타 오류).
고객이 직면하는 가장 일반적인 구성 문제 중 하나는 가용성 그룹 수신기 만들기입니다. 오류는 다음과 유사합니다.
-
Msg 19471, Level 16, State 0, Line 2 WSFC 클러스터에서 DNS 이름이 ''인 네트워크 이름 리소스를 온라인 상태로 가져올 수 없습니다. DNS 이름이 수행되었거나 기존 이름 서비스와 충돌하거나 WSFC 클러스터 서비스가 실행되지 않거나 액세스할 수 없을 수 있습니다. 다른 DNS 이름을 사용하여 이름 충돌을 resolve 자세한 내용은 WSFC 클러스터 로그를 검사.
-
Msg 19476, 수준 16, 상태 4, 줄 2 수신기에 대한 네트워크 이름 및 IP 주소를 만들려는 시도가 실패했습니다. WSFC 서비스가 실행되고 있지 않거나 현재 상태에서 액세스할 수 없거나 네트워크 이름 및 IP 주소에 제공된 값이 올바르지 않을 수 있습니다. WSFC 클러스터의 상태를 확인하고 네트워크 관리자에게 네트워크 이름 및 IP 주소의 유효성을 검사합니다.
대부분의 경우 이전 메시지로 인한 수신기 만들기 실패는 Active Directory에서 수신기 컴퓨터 개체를 만들고 읽을 수 있는 CNO(클러스터 이름 개체)에 대한 권한이 부족하기 때문입니다. 이 문제를 해결하려면 다음 문서를 검토하세요.
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
자동 장애 조치(failover)가 예상대로 작동하지 않음
테스트 중 또는 프로덕션 환경에서 자동 장애 조치(failover)가 예상대로 작동하지 않는 경우 SQL Server 2012 Always On 환경에서 자동 장애 조치(failover) 문제 해결을 참조하세요.
지정된 기간 동안 최대 오류의 부적절한 구성은 주 복제본이 보조로 자동으로 장애 조치(failover)되지 않는 주요 원인 중 하나입니다. 이 설정의 기본값은 N-1이며 여기서 N은 복제본 수입니다. 자세한 내용은 장애 조치(failover) 클러스터(그룹) 최대 오류 제한을 참조하세요.
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
Always On 가용성 그룹에 연결하는 데 문제가 있습니다.
SQL Server 2012에서 Always On 가용성 그룹에 대한 가용성 그룹 수신기를 구성한 후에는 수신기를 ping하거나 애플리케이션에서 연결할 수 없습니다. 다음과 유사한 오류가 발생할 수 있습니다.
Sqlcmd: 오류: Microsoft SQL Native Client: 로그인 시간 제한이 만료되었습니다.
이 오류와 유사한 오류를 해결하려면 다음을 검토합니다.
추가 정보 링크:
- 업데이트는 SQL Server 2012 이상 버전의 Always On 기능에 대한 지원을 the.NET Framework 3.5 SP1에 도입되었습니다.
- SQL Server 다중 서브넷 클러스터링(SQL Server)
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
내 Azure VM(IaaS)에서 Always On 가용성 그룹을 구성하는 데 문제가 있습니다.
Always On 관련된 많은 문제는 수신기의 부적절한 구성으로 인해 발생합니다. 수신기에 연결 문제가 있는 경우
ILB 수신기의 모든 제한 사항을 읽고 다음 문서에 설명된 모든 단계를 수행하여 PowerShell 스크립트의 종속성 구성, IP 주소 및 기타 다양한 매개 변수에 특히 주의해야 합니다.
확실하지 않은 경우 위의 문서에 따라 수신기를 삭제하고 다시 만들 수 있습니다.
최근에 VM을 다른 서비스로 이동했거나 IP 주소가 변경된 경우 새 주소를 반영하도록 IP 주소 리소스의 값을 업데이트해야 하며 AG에 대한 부하 분산 엔드포인트를 다시 만들어야 합니다. 다음과 같이 또는
Set명령을 사용하여GetIP 주소를 업데이트할 수 있습니다.Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"
권장 문서:
Azure Virtual Machines SQL Server Always On 가용성 그룹에 대한 부하 분산 장치 구성
Microsoft Azure(IaaS)에서 SQL Server Always On 가용성 그룹을 배포할 때 권장 사항 및 모범 사례
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
기본에서 보조로 장애 조치(failover)하는 데 시간이 오래 걸리거나 그 반대의 경우도 마찬가지입니다.
가용성 그룹에 대한 데이터 손실 없이 자동 장애 조치(failover) 또는 계획된 수동 장애 조치(failover) 후 장애 조치(failover) 시간이 RTO(복구 시간 목표)를 초과할 수 있습니다. 원인 및 잠재적 해결 방법을 해결하려면 문제 해결: 가용성 그룹 초과 RTO를 참조하세요.
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
주 복제본의 변경 내용이 반영되지 않거나 보조 복제본에 복제 속도가 느려짐
주 복제본(replica) 변경 내용이 적시에 보조 데이터베이스로 전파되지 않는 것을 알 수 있습니다. 이러한 문제를 해결하고 resolve 다음을 시도합니다.
SQL Server 2012 및 SQL Server 2014 환경의 경우 수정: 디스크가 SQL SERVER AG 및 Logshipping 환경에서 기본 및 보조 복제본(replica) 로그 파일에 대한 섹터 크기가 서로 다른 경우의 느린 동기화를 참조하세요.
보조 노드가 클러스터 관리자의 일시 중지됨 상태인지 확인합니다.
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
AG 데이터베이스의 트랜잭션 로그 크기를 관리하는 방법
기본 또는 보조 서버에서 일반 백업을 구성하여 트랜잭션 로그 크기를 줄일 수 있습니다.
자세한 내용은 다음 topics 검토하세요.
이 정보가 도움이 되지 않는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
주 또는 보조 서버가 해결 중이거나 예기치 않은 장애 조치(failover)가 발생합니다.
시스템 및 애플리케이션 이벤트 로그에서 하드웨어 문제 및 기타 오류를 확인하고 공급업체와 협력하여 문제를 해결합니다.
가상 머신을 사용하는 경우 해당 기술 자료 검사 문제에 기여할 수 있는 최근에 보고된 문제가 있는지 확인합니다. 예를 들어 ESXi(2039495)의 VMXNET3 vNIC에서 게스트 운영 체제 수준에서 큰 패킷 손실 이 발생하여 AG 구성에 문제가 발생하는 경우도 있습니다.
추가 정보:
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
리소스를 온라인 상태로 가져올 수 없음
SQL ErrorLog의 메시지를 검토하여 데이터베이스가 복구하는 데 시간이 오래 걸리는지 확인합니다.
문제가 여전히 존재하는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조하세요.
질문과 대답
하나의 가용성 그룹에 대해 두 개의 수신기를 가질 수 있나요?
예, 동일한 가용성 그룹에 대해 여러 수신기를 설정할 수 있습니다. 동일한 가용성 그룹에 대해 여러 수신기를 만드는 방법(Goden Yao)을 참조하세요.
항상 트래픽 및 클라이언트 연결에 대해 별도의 NIC 카드 가질 수 있나요?
예, Always On 트래픽에 대한 전용 NIC 카드 가질 수 있습니다. 전용 네트워크에서 통신하도록 가용성 그룹 구성을 참조하세요.
장애 조치(failover) 클러스터 인스턴스에 Always On 지원하는 버전은 무엇인가요?
SQL Server 온라인 설명서의 이 항목에는 SQL Server 2016용 버전 및 지원되는 기능과 같은 자세한 정보가 있습니다.
클러스터의 모든 노드에서 오류가 발생한 경우 복구하는 방법
강제 쿼럼(SQL Server)을 통한 WSFC 재해 복구를 참조하세요.
AG 구성에서 분산 트랜잭션 지원에 대한 정보는 어디에서 찾을 수 있나요?
Always On 구성을 업데이트하는 방법
AG 구성에 TDE(투명한 데이터 암호화) 사용 데이터베이스를 추가하는 방법
AG에 TDE 사용 DB를 추가하려면 TDE 데이터베이스에 대한 Always On 구성하는 방법을 참조하세요.
보조 데이터베이스가 주 복제본보다 뒤쳐지는지 확인하기 위해 경고를 구성하는 방법
다음 스크립트를 사용할 수 있습니다.
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id AS database_id, is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END, ag_replica_role = CASE WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED' ELSE ar_state.role_desc END, dr_state.last_hardened_lsn, dr_state.last_hardened_time, datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary' FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id) JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id) JOIN sys.dm_hadr_database_replica_states dr_state ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id데이터베이스 상태가 동기화되지 않은 경우 경고를 받는 방법
다음 스크립트를 사용할 수 있습니다.
SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server, dr_state.database_id AS database_id, is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END, ag_replica_role = CASE WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED' ELSE ar_state.role_desc END, ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc FROM (( sys.availability_groups AS ag JOIN sys.availability_replicas AS ar ON ag.group_id = ar.group_id ) JOIN sys.dm_hadr_availability_replica_states AS ar_state ON ar.replica_id = ar_state.replica_id) JOIN sys.dm_hadr_database_replica_states dr_state ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_idAlways On 그룹을 모니터링하는 추가 방법은 다음 링크를 검토할 수도 있습니다.