Always On 가용성 그룹에서 로그 송신 큐 문제 해결
이 문서에서는 로그 송신 큐와 관련된 문제에 대한 해결 방법을 제공합니다.
로그 송신 큐란?
주 복제본(예: INSERTUPDATE, 및DELETE)의 가용성 그룹 데이터베이스에 대한 변경 내용은 트랜잭션 로그에 기록되고 가용성 그룹 보조 복제본으로 전송됩니다. 로그 보내기 큐는 보조 복제본으로 전송되지 않은 주 데이터베이스의 로그 파일에 있는 로그 레코드 수를 정의합니다.
로그 송신 큐의 증상 및 효과
로그 송신 큐는 모든 취약한 데이터를 저장합니다.
갑작스런 재해로 주 복제본이 손실되고 이러한 변경 내용이 아직 도착하지 않은 보조 복제본으로 장애 조치하는 경우 해당 변경 내용은 데이터베이스의 새 주 복제본 복사본에 표시되지 않습니다. 전체 데이터베이스 및 로그 백업이 실행될 때 저장되는 변경 내용은 제외됩니다.
로그 송신 큐가 증가하면 트랜잭션 로그 파일 증가가 발생합니다.
가용성 그룹에 정의된 데이터베이스의 경우 Microsoft SQL Server는 보조 복제본에 아직 배달되지 않은 트랜잭션 로그의 모든 트랜잭션을 주 복제본에 유지해야 합니다. 로그 보내기 큐는 일반 로그 잘림 이벤트(예: 데이터베이스 로그 백업 중)에서 잘리지 못하는 주 복제본의 기록된 변경 수량을 나타냅니다. 점점 커지는 로그 송신 큐는 데이터베이스 로그 파일을 호스트하는 드라이브에서 사용 가능한 공간을 소진하거나 구성된 최대 트랜잭션 로그 파일 크기를 초과할 수 있습니다. 자세한 내용은 트랜잭션 로그가 큰 경우 오류 9002를 참조하세요.
다양한 진단 기능 보고서 가용성 그룹 로그 송신 큐
SQL Server Management Studio의 Always On 대시보드는 로그 보내기 큐에 대해 보고합니다. 가용성 그룹이 비정상이라고 보고할 수 있습니다.
로그 송신 큐를 확인하는 방법
로그 송신 큐는 데이터베이스별 측정값입니다. 주 복제본에서 Always On 대시보드를 사용하거나 주 복제본 또는 보조 복제본에서 sys.dm_hadr_database_replica_states DMV(동적 관리 뷰)를 사용하여 이 값을 확인할 수 있습니다. 성능 모니터 카운터는 보조 복제본에 대한 로그 송신 큐를 확인하는 데 사용됩니다.
다음 몇 가지 섹션에서는 가용성 그룹 데이터베이스 로그 송신 큐를 적극적으로 모니터링하는 방법을 제공합니다.
쿼리 sys.dm_hadr_database_replica_state
DMV는 sys.dm_hadr_database_replica_states 각 가용성 그룹 데이터베이스에 대한 행을 보고합니다. 해당 보고서의 한 열은 .입니다 log_send_queue_size. 이 값은 로그 송신 큐 크기(KB)입니다. 다음 쿼리와 같은 쿼리를 설정하여 로그 송신 큐 크기의 추세를 모니터링할 수 있습니다. 쿼리는 주 복제본에서 실행됩니다. 조건자를 is_local=0 사용하여 보조 복제본에 대한 데이터를 보고합니다. 여기서는 log_send_rate 관련이 log_send_queue_size 있습니다.
WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.log_send_queue_size, drs.log_send_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
waitfor delay '00:00:30'
END
출력은 다음과 같습니다.
Always On 대시보드에서 로그 보내기 큐 검토
로그 보내기 큐를 검토하려면 다음 단계를 수행합니다.
SSMS 개체 탐색기 가용성 그룹을 마우스 오른쪽 단추로 클릭하여 SSMS(SQL Server Management Studio)에서 Always On 대시보드를 엽니다.
대시보드 표시를 선택합니다.
가용성 그룹 데이터베이스는 마지막으로 나열되며 데이터베이스에 보고된 일부 데이터가 있습니다. 로그 송신 큐 크기(KB) 및 로그 송신 속도(KB/초)는 기본적으로 나열되지 않지만 다음 단계의 스크린샷과 같이 이 보기에 추가할 수 있습니다.
이러한 열을 추가하려면 가용성 그룹 데이터베이스 열 머리글을 마우스 오른쪽 단추로 클릭하고 사용 가능한 열 목록에서 선택합니다.
로그 보내기 큐 크기를 추가하려면 다음 스크린샷에서 빨간색으로 강조 표시된 헤더를 마우스 오른쪽 단추로 클릭합니다.
기본적으로 Always On 대시보드는 60초마다 이 데이터를 자동으로 새로 고칩니다.
성능 모니터 로그 보내기 큐 검토
로그 송신 큐는 각 보조 복제본 데이터베이스와 관련이 있습니다. 따라서 가용성 그룹 데이터베이스의 로그 송신 큐를 검토하려면 다음 단계를 수행합니다.
보조 복제본에서 성능 모니터 엽니다.
추가(카운터) 단추를 선택합니다.
사용 가능한 카운터에서 SQLServer:Database 복제본 및 로그 송신 큐 카운터를 선택합니다.
인스턴스 목록 상자에서 로그 송신 큐를 확인하려는 가용성 그룹 데이터베이스를 선택합니다.
추가 및 확인을 선택합니다.
로그 송신 큐가 증가하는 모양은 다음과 같습니다.
로그 송신 큐 값 해석
이 섹션에서는 로그 송신 큐 크기의 값을 해석하는 방법을 설명합니다.
로그 송신 큐가 나쁜 경우는 언제인가요? 얼마나 많은 로그 송신 큐를 허용해야 하나요?
로그 송신 큐가 값 0을 보고하는 경우 해당 보고서 당시 로그 송신 큐가 발생하지 않는다고 가정할 수 있습니다. 그러나 프로덕션 환경이 사용 중인 경우 로그 송신 큐가 정상 AlwaysOn 환경에서도 0이 아닌 값을 자주 보고하는 것을 관찰해야 합니다. 일반적인 프로덕션 중에는 이 값이 0과 0이 아닌 값 사이에서 변동하는 것을 관찰해야 합니다.
시간이 지남에 따라 로그 송신 큐가 증가하는 것을 관찰하는 경우 추가 조사가 보장됩니다. 이 추가 작업은 무언가가 변경되었음을 나타냅니다. 로그 송신 큐의 급격한 증가를 관찰하는 경우 다음 측정값이 문제 해결에 유용합니다.
- 로그 전송 속도(KB/초) (AlwaysOn 대시보드)
- sys.dm_hadr_database_replica_states(DMV)
- 데이터베이스 복제본::미러된 트랜잭션/초(성능 모니터)
로그 전송 속도 및 미러된 트랜잭션에 대한 기준 요금 가져오기/초
정상 AlwaysOn 성능 동안 사용 중인 가용성 그룹 데이터베이스에 대한 로그 전송 속도 및 미러된 트랜잭션/초 값을 모니터링합니다. 일반적으로 바쁜 업무 시간에는 어떤 모습일까요? 대규모 트랜잭션이 시스템에서 더 높은 트랜잭션 처리량을 유도하는 유지 관리 기간 동안의 모양은 어떻게 됩니까? 로그 송신 큐 증가를 관찰할 때 이러한 값을 비교하여 변경된 내용을 확인할 수 있습니다. 워크로드가 평소보다 클 수 있습니다. 로그 전송 속도가 평소보다 낮으면 이유를 확인하기 위해 추가 조사가 필요할 수 있습니다.
워크로드 볼륨이 중요합니다.
대규모 워크로드(예: UPDATE 100만 행에 대한 문, 1테라바이트 테이블의 인덱스 다시 작성 또는 수백만 개의 행을 삽입하는 ETL 일괄 처리)가 있는 경우 즉시 또는 시간이 지남에 따라 일부 로그 송신 큐 증가가 표시되어야 합니다. 이는 가용성 그룹 데이터베이스에서 갑자기 많은 수의 변경이 수행될 때 발생합니다.
로그 송신 큐를 진단하는 방법
특정 가용성 그룹 데이터베이스에 대한 로그 송신 큐를 식별한 후에는 다음 섹션에서 설명한 대로 문제의 여러 가지 가능한 근본 원인을 확인해야 합니다.
Important
의미 있는 대기 유형 출력의 경우 다음 조건을 모니터링할 때 이전 섹션에서 설명한 방법 중 하나를 사용하여 로그 송신 큐의 증가를 확인합니다.
시스템이 너무 바빠서
주 복제본의 워크로드가 시스템의 CPU를 오버로드하는지 확인합니다. 로그 송신 큐가 증가하는 경우 DMV를 sys.dm_os_schedulers 쿼리하고 모니터링합니다 high runnable_tasks_count. 이 개수는 해당 시간에 실행된 미해결 작업을 나타냅니다.
SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, runnable_tasks_count, current_workers_count, active_workers_count
FROM sys.dm_os_schedulers
다음 표는 결과의 샘플입니다. 값이 증가하면 runnable_tasks_count 많은 수의 작업이 CPU 시간을 기다리고 있음을 나타냅니다.
| scheduler_address | scheduler_id | cpu_id | status | current_tasks_count | runnable_tasks_count | current_workers_count | active_workers_count |
|---|---|---|---|---|---|---|---|
| 0x000002778D 200040 | 0 | 0 | 오프라인으로 표시 | 1 | 0 | 2 | 1 |
| 0x000002778D 220040 | 1 | 1 | VISIBLE ONLINE | 108 | 12 | 115 | 107 |
| 0x000002778D 240040 | 2 | 2 | VISIBLE ONLINE | 113 | 2 | 123 | 113 |
| 0x000002778D 260040 | 3 | 3 | VISIBLE ONLINE | 105 | 11 | 116 | 105 |
| 0x000002778D 480040 | 4 | 4 | VISIBLE ONLINE | 108 | 15 | 117 | 108 |
| 0x000002778D 4A0040 | 5 | 5 | VISIBLE ONLINE | 100 | 25 | 110 | 99 |
| 0x000002778D 4C0040 | 6 | 6 | VISIBLE ONLINE | 105 | 23 | 113 | 105 |
| 0x000002778D 4E0040 | 7 | 7 | 보이는 | 109 | 25 | 116 | 109 |
| 0x000002778D 700040 | 8 | 8 | VISIBLE ONLINE | 98 | 10 | 112 | 98 |
| 0x000002778D 720040 | 9 | 9 | VISIBLE ONLINE | 114 | 1 | 130 | 114 |
| 0x000002778D 740040 | 10 | 10 | VISIBLE ONLINE | 110 | 25 | 120 | 110 |
| 0x000002778D 760040 | 11 | 11 | VISIBLE ONLINE | 83 | 8 | 93 | 83 |
| 0x000002778D A00040 | 12 | 12 | VISIBLE ONLINE | 104 | 4 | 117 | 104 |
| 0x000002778D A20040 | 13 | 13 | VISIBLE ONLINE | 108 | 32 | 118 | 108 |
| 0x000002778D A40040 | 14 | 14 | VISIBLE ONLINE | 102 | 12 | 113 | 102 |
| 0x000002778D A60040 | 15 | 15 | VISIBLE ONLINE | 104 | 16 | 116 | 103 |
해결 방법: 높은 runnable_task_count것을 감지하는 경우 시스템의 워크로드를 줄이거나 시스템에서 사용할 수 있는 CPU 수를 늘입니다.
네트워크 대기 시간
이 조건은 보조 복제본이 주 복제본에서 물리적으로 원격인 경우에 특히 일반적입니다. 다중 사이트 가용성 그룹을 사용하면 고객이 재해 복구 및 보고를 위해 여러 사이트에 비즈니스 데이터 복사본을 배포할 수 있습니다. 이렇게 하면 원격 위치에서 프로덕션 데이터의 복사본에 거의 실시간으로 변경 내용을 사용할 수 있습니다.
보조 복제본이 주 복제본에서 멀리 떨어져 호스팅되는 경우 네트워크 대기 시간 및 주 복제본 데이터베이스에서 생성되는 만큼 빠르게 원격 보조 복제본에 변경 내용을 보낼 수 없기 때문에 로그 전송 큐가 발생할 수 있습니다.
Important
SQL Server는 단일 연결을 사용하여 주 복제본에서 보조 복제본으로 변경 내용을 동기화합니다. 따라서 보조 복제본이 원격인 경우 파이프 너비는 SQL Server에서 보낼 수 있는 데이터의 양에 영향을 미치지 않습니다. 대신 이 크기는 파이프의 네트워크 대기 시간(연결 속도)에 따라 달라집니다.
네트워크 대기 시간 테스트
흐름 제어 설정이 네트워크 대기 시간에 영향을 주는지 확인
Microsoft SQL Server 가용성 그룹은 흐름 제어 게이트를 사용하여 모든 가용성 복제본에서 네트워크 리소스, 메모리 및 기타 리소스의 과도한 소비를 방지합니다. 이러한 흐름 제어 게이트는 가용성 복제본의 동기화 상태에 영향을 주지 않습니다. 그러나 RPO를 포함하여 가용성 데이터베이스의 전반적인 성능에 영향을 줄 수 있습니다.
이후 버전의 SQL Server는 흐름 제어가 입력되는 임계값을 변경합니다. 이렇게 하면 흐름 제어가 로그 송신 큐와 같은 증상에 미치는 영향을 완화하는 데 도움이 될 수 있습니다. 흐름 제어 및 흐름 제어 임계값 변경 기록에 대한 자세한 내용은 흐름 제어 게이트를 참조 하세요.
성능 모니터 사용하여 주 복제본에서 데이터를 캡처하여 흐름 제어를 모니터링할 수 있습니다. 데이터베이스 흐름 제어를 모니터링하려면 SQLServer:Database Replica 카운터를 추가하고 데이터베이스 흐름 제어 지연 및 데이터베이스 흐름 제어/초 카운터를 선택합니다. 인스턴스 대화 상자에서 데이터베이스 흐름 제어를 확인하려는 가용성 그룹 데이터베이스를 선택합니다. 가용성 복제본 흐름 제어를 검색하고 모니터링하려면 SQLServer:Availability Replica 카운터를 추가하고 흐름 제어 시간(ms/초) 및 흐름 제어/초 카운터를 선택합니다.
정체 Windows 다시 시작이 네트워크 대기 시간에 영향을 주는지 확인
정체 Windows 다시 시작 TCP 설정을 True로 설정하여 로그 송신 큐를 발생시키는 네트워크 성능 문제를 트리거할 수 있습니다. Windows Server 2016의 기본 설정입니다. 로그 송신 큐가 관찰되는 가용성 그룹 복제본을 호스트하는 Windows 서버에서 정체 창 다시 시작이 False로 설정되어 있는지 확인합니다.
PS C:\WINDOWS\system32> Get-NetTCPSetting | Select SettingName, CwndRestart
TCP 정체 Windows 다시 시작 속성을 False로 설정하는 방법에 대한 자세한 내용은 Set-NetTCPSetting(NetTCPIP)을 참조하세요.
또한 동기화 프로세스에 대한 자세한 내용은 Always On 가용성 그룹의 성능 모니터링을 참조하세요. 또한 이 문서에서는 몇 가지 주요 메트릭을 계산하는 방법을 보여 줍니다. 일반적인 성능 문제 해결 시나리오에 대한 링크를 제공합니다.
ping을 사용하여 대기 시간 샘플 가져오기
node1(주 복제본)의 명령줄에서 ping node2(보조 복제본):
C:\Users\customer>ping node2 Pinging node2.customer.corp.company.com [<ip address>] with 32 bytes of data: Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=97ms Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=94ms Reply from 2001:4898:4018:3005:25f3:d931:2507:e353: time=119ms Ping statistics for 2<ip address>: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 94ms, Maximum = 119ms, Average = 101ms독립 도구를 사용하여 기본에서 보조로 네트워크 처리량 테스트
NTttcp와 같은 도구를 사용하여 단일 연결을 사용하여 주 복제본과 보조 복제본 간의 네트워크 처리량을 독립적으로 검색합니다. 네트워크 대기 시간은 로그 송신 큐에 대한 일반적인 원인입니다. 다음 단계에서는 NTttcp와 같은 독립 도구를 사용하여 네트워크 처리량을 측정하는 방법을 보여줍니다.
Important
SQL Server는 단일 연결을 사용하여 주 복제본에서 보조 복제본으로 변경 내용을 보냅니다. 다음 섹션에서는 단일 연결(SQL Server와 동일한 방식)을 사용하여 처리량을 정확하게 비교하도록 NTttcp를 구성하고 실행합니다.
Github - microsoft/ntttcp에서 NTttcp를 다운로드할 수 있습니다.
NTttcp를 실행하려면 다음 단계를 수행합니다.
도구를 다운로드하여 기본 및 보조 SQL Server 기반 서버에 복사합니다.
보조 복제본 서버에서 관리자 권한 명령 프롬프트 창을 열고 디렉터리를 NTttcp 도구 폴더로 변경한 다음 다음 명령을 실행합니다.
ntttcp.exe -r -m 1,0,<secondaryipaddress>-a 16 -t 60참고 항목
이 명령
<secondaryipaddress>에서는 보조 복제본 서버의 실제 IP 주소에 대한 자리 표시자입니다.주 복제본 서버에서 관리자 권한 명령 프롬프트 창을 열고 디렉터리를 NTttcp 도구 폴더로 변경한 다음 보조 복제본 서버의 실제 IP 주소를 다시 지정하여 다음 명령을 실행합니다.
ntttcp.exe -s -m 1,0,<secondaryipaddress>-a 16 -t 60다음 스크린샷은 보조 및 주 복제본에서 실행되는 NTttcp를 보여 줍니다. 네트워크 대기 시간으로 인해 이 도구는 739KB/초의 데이터만 보낼 수 있습니다. 이것이 SQL Server가 보낼 수 있을 것으로 예상할 수 있는 것입니다.
보조 복제본의 NTttcp
주 복제본의 NTttcp
성능 모니터 카운터 검토
NTttcp에서 보고하는 내용을 확인합니다. 큰 트랜잭션은 주 복제본의 SQL Server에서 실행됩니다. 주 복제본에서 성능 모니터 시작한 후 네트워크 인터페이스::Bytes Sent/sec 카운터를 추가합니다. 이 카운터는 주 복제본이 약 777KB/초의 데이터를 보낼 수 있음을 확인합니다. 이는 NTttcp 테스트에서 보고한 739KB/초의 값과 유사합니다.
주 복제본의 SQL Server::D atabases::Log Bytes Flushed/sec 값을 보조 복제본의 동일한 데이터베이스에 대해 SQL Server::D atabase Replica::Log Bytes Received/sec와 비교하는 것도 유용합니다. 평균적으로 "agdb" 데이터베이스에서 생성된 변경 내용이 20MB/초까지 관찰됩니다. 그러나 보조 복제본은 평균적으로 5.4MB의 변경 내용만 수신합니다. 이로 인해 아직 보조 복제본으로 전송되지 않은 데이터베이스 트랜잭션 로그의 미해결 변경 내용의 주 복제본에 로그 보내기 큐가 발생합니다.
"agdb" 데이터베이스에 대한 주 복제본 로그 바이트 Flushed/초
데이터베이스 agdb에 대한 보조 복제본 로그 바이트 수신/초
