SQL Server Always On 문제 해결
이 문서는 SQL Server의 Always On 구성에 대한 일반적인 문제를 해결하는 데 도움이 됩니다.
참고 항목
이 문서의 안내된 연습은 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) - 이 문서에서는 가용성 그룹 및 설정에 대한 다양한 질문에 대한 답변을 제공합니다. 이 문서의 모든 단계를 수행하고 SQL Server(Always On 가용성 그룹에 대한 필수 구성 요소, 제한 사항 및 권장 사항)를 검토하면 환경에서 가용성 그룹을 설정하고 유지 관리하는 데 발생할 수 있는 많은 문제를 방지하는 데 도움이 됩니다.
추가 리소스
이 정보가 도움이 되지 않는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조 하세요.
Always On 가용성 그룹을 구성하는 데 문제가 있습니다.
일반적인 구성 문제로는 Always On 가용성 그룹이 비활성화되고, 계정이 잘못 구성되고, 데이터베이스 미러링 엔드포인트가 존재하지 않으며, 엔드포인트에 액세스할 수 없음(SQL Server 오류 1418), 네트워크 액세스가 없고, 데이터베이스 조인 명령이 실패합니다(SQL Server 오류 35250). 이러한 문제 해결에 대한 도움말은 다음 문서를 검토하세요.
Always On 가용성 그룹 구성 문제 해결(SQL Server)
추가 링크: 수정: 여러 가용성 그룹을 만들려고 할 때 오류 41009
여전히 문제가 있는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조 하세요.
수신기 구성에 문제가 있음(19471, 19476 및 기타 오류)
고객에게 발생하는 가장 일반적인 구성 문제 중 하나는 가용성 그룹 수신기 만들기입니다. 오류는 다음과 유사합니다.
-
Msg 19471, Level 16, State 0, Line 2The WSFC 클러스터는 DNS 이름이 ''인 네트워크 이름 리소스를 온라인 상태로 가져올 수 없습니다. DNS 이름이 사용되었거나 기존 이름 서비스와 충돌하거나 WSFC 클러스터 서비스가 실행되지 않거나 액세스할 수 없을 수 있습니다. 다른 DNS 이름을 사용하여 이름 충돌을 해결하거나 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
명령을 사용하여Get
IP 주소를 업데이트할 수 있습니다.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 가용성 그룹에 대한 자세한 내용을 참조 하세요.
주 복제본의 변경 내용이 반영되지 않거나 보조 복제본에 복제하는 속도가 느림
주 복제본의 변경 내용이 적시에 보조 복제본으로 전파되지 않는 것을 알 수 있습니다. 이러한 문제를 해결하고 해결하려면 다음을 시도합니다.
SQL Server 2012 및 SQL Server 2014 환경의 경우 SQL Server AG 및 Logshipping 환경에서 디스크의 기본 및 보조 복제본 로그 파일에 대한 섹터 크기가 서로 다른 경우 수정: 느린 동기화를 참조 하세요.
보조 노드가 클러스터 관리자에서 일시 중지된 상태인지 확인합니다.
문제 해결: 주 복제본의 변경 내용이 보조 복제본에 반영되지 않습니다.
여전히 문제가 있는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조 하세요.
AG 데이터베이스의 트랜잭션 로그 크기를 관리하는 방법
기본 또는 보조 서버에서 일반 백업을 구성하여 트랜잭션 로그 크기를 줄일 수 있습니다.
추가 정보는 다음 항목을 검토하세요.
이 정보가 도움이 되지 않는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조 하세요.
주 또는 보조 서버가 해결 중이거나 예기치 않은 장애 조치(failover)가 발생합니다.
시스템 및 애플리케이션 이벤트 로그에서 하드웨어 문제 및 기타 오류를 확인하고 공급업체와 협력하여 문제를 해결합니다.
가상 머신을 사용하는 경우 해당 기술 자료 확인하여 문제에 기여할 수 있는 최근에 보고된 문제가 있는지 확인합니다. 예를 들어 2039495 (ESXi) 의 VMXNET3 vNIC에 대한 게스트 운영 체제 수준에서 큰 패킷 손실로 인해 AG 구성에 문제가 발생하는 경우도 있습니다.
추가 정보:
여전히 문제가 있는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조 하세요.
리소스를 온라인 상태로 가져올 수 없음
SQL ErrorLog의 메시지를 검토하여 데이터베이스가 복구하는 데 시간이 오래 걸리는지 확인합니다.
여전히 문제가 있는 경우 Always On 가용성 그룹에 대한 자세한 내용을 참조 하세요.
자주 묻는 질문
하나의 가용성 그룹에 대해 두 개의 수신기를 가질 수 있나요?
예, 동일한 가용성 그룹에 대해 여러 수신기를 설정할 수 있습니다. 동일한 가용성 그룹에 대해 여러 수신기를 만드는 방법(Goden Yao)을 참조하세요.
항상 트래픽 및 클라이언트 연결을 위해 별도의 NIC 카드를 사용할 수 있나요?
예, Always On 트래픽에 대한 전용 NIC 카드를 사용할 수 있습니다. 전용 네트워크에서 통신하도록 가용성 그룹 구성을 참조하세요.
Always On 장애 조치(failover) 클러스터 인스턴스를 지원하는 버전은 무엇인가요?
SQL Server 온라인 설명서의 이 항목에는 SQL Server 2016용 버전 및 지원되는 기능과 같은 추가 정보가 있습니다.
클러스터의 모든 노드에서 오류가 발생할 경우 복구하는 방법
강제 쿼럼을 통한 WSFC 재해 복구(SQL Server)를 참조하세요.
AG 구성에서 분산 트랜잭션 지원에 대한 정보는 어디에서 찾을 수 있나요?
Always On 구성을 업데이트하는 방법
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_id
Always On 그룹을 모니터링하는 추가 방법은 다음 링크를 검토할 수도 있습니다.