다음을 통해 공유


상태를 되돌리는 가용성 그룹 데이터베이스 문제 해결

이 문서는 상태를 되돌리는 가용성 그룹 데이터베이스의 문제를 해결하는 데 도움이 됩니다.

되돌리기 상태는 무엇인가요?

주 서버와 동기화를 다시 진행하기 위해 보조 서버가 이미 적용한 변경 내용을 실행 취소해야 하는 경우 상태 되돌리기가 발생합니다.

주 복제본의 변경 내용이 보조 복제본과 적극적으로 동기화되도록 가용성 그룹 주 복제본 및 보조 복제본은 정상 작업 중에 연결된 상태로 유지됩니다.

장애 조치(failover) 중에 이 연결된 상태가 끊어집니다. 새 주 복제본이 온라인 상태가 되면 주 복제본과 보조 복제본 간에 연결이 다시 설정됩니다. 이 초기 연결 상태 중에는 새 보조 복제본이 주 복제본과 동기화되도록 복구를 시작해야 하는 공통 복구 지점이 협상됩니다.

장애 조치(failover) 시 큰 트랜잭션이 실행 중인 경우 새 보조 데이터베이스 로그가 주 복제본 데이터베이스보다 앞서 있습니다. 협상된 새 공통 복구 지점은 보조 복제본이 동기화를 다시 시작할 수 있는 상태에 있도록 주 복제본에서 페이지를 수신해야 합니다. 되돌리기 프로세스를 "다시 실행 취소"라고도 합니다.

되돌리기 프로세스는 본질적으로 느리고, 자주 발생하며, 일반적으로 되돌리기 상태를 트리거하는 작은 트랜잭션은 거의 눈에 띄지 않습니다. 장애 조치(failover)가 대용량 트랜잭션을 방해할 때 상태를 되돌리는 것이 종종 발견되어 주 복제본 데이터베이스를 복구 가능한 상태로 되돌리기 위해 주 데이터베이스에서 보조 페이지로 많은 페이지를 보냅니다.

상태 되돌리기에서 가용성 그룹 데이터베이스의 증상 및 효과

데이터베이스가 보조 복제본에서 되돌리기 상태인 경우 데이터베이스는 동기화되지 않으므로 주 복제본에서 변경 내용을 수신하지 않습니다. 주 복제본에서 데이터베이스가 갑자기 손실되면 데이터가 손실될 수 있습니다.

Always On 대시보드 보고서 기본에서 동기화되지 않음

가용성 그룹을 장애 조치(failover)한 후 장애 조치(failover)가 성공한 동안 보조 복제본이 동기화되지 않는 것으로 보고되는 것을 확인할 수 있습니다. Always On 대시보드는 주 대시보드에서 동기화되지 않고 보조 데이터베이스에서 되돌리기를 보고합니다.

Always On 대시보드 보고서 기본에서 동기화되지 않음 보조 데이터베이스에서 되돌리는 Always On 대시보드 보고서
주 데이터베이스에서 동기화되지 않음을 보고하는 Always On 대시보드의 스크린샷 보조 데이터베이스에서 되돌리기를 보고하는 Always On 대시보드의 스크린샷

Always On DMV는 주 데이터베이스에서 동기화되지 않음을 보고합니다.

주 데이터베이스에서 다음 Ag(Always On 가용성 그룹) DMV(동적 관리 뷰)를 쿼리하면 데이터베이스가 NOT SYNCHRONIZING 상태에 있습니다.

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

주 데이터베이스에서 동기화되지 않음을 보고하는 Always On DMV의 스크린샷

보조 데이터베이스에서 DMV를 쿼리하면 가용성 그룹 데이터베이스가 되돌리기 상태입니다.

보조 데이터베이스에서 되돌리기를 보고하는 Always On DMV의 스크린샷

읽기 전용 및 보고 워크로드가 보조 데이터베이스에 액세스하지 못

보조 데이터베이스가 되돌리는 동안에는 액세스하거나 쿼리할 수 없습니다. 이러한 읽기 전용 워크로드는 오프라인이며 중단됩니다. 데이터베이스가 상태를 되돌리는 기간에 따라 이러한 워크로드가 중요 비즈니스용인 경우 해당 워크로드를 다른 보조 복제본 또는 주 복제본으로 다시 라우팅해야 할 수 있습니다.

보조 복제본으로 라우팅되는 보고 워크로드와 같은 읽기 전용 워크로드가 있는 경우 메시지 922와 함께 이러한 일괄 처리가 실패할 수 있습니다.

Msg 922, Level 14, State 1, Line 2 데이터베이스 'agdb'가 복구되고 있습니다. 복구가 완료될 때까지 대기합니다.

스크린샷은 읽기 전용 및 보고 워크로드가 오류 922로 보조 데이터베이스에 액세스하지 못하는 것을 보여줍니다.

되돌리기 상태에서 보조 복제본 데이터베이스에 로그인하려는 애플리케이션이 연결에 실패하고 오류 18456을 발생합니다.

2023-01-26 13:01:13.100 로그온 오류: 18456, 심각도: 14, 상태: 38. 2023-01-26 13:01:13.100 사용자 'UserName>'<에 대한 로그온 로그인이 실패했습니다. 이유: 명시적으로 지정된 데이터베이스 'agdb'를 열지 못했습니다. [클라이언트: <로컬 컴퓨터>]

실패한 로그인이 감사되는 경우 SQL Server 오류 로그에서도 이 오류를 보고할 수 있습니다.

되돌리기 상태의 남은 시간 예측

다음 방법 중 하나를 사용하여 되돌리기 상태에서 남은 시간을 예측합니다.

AlwaysOn_health XEvent 세션 사용

AlwaysOn_health 확장 이벤트 진단 로그에는 5분마다 상태 되돌리기 진행률을 보고하는 hadr_trace_message 이벤트가 있습니다.

SSMS(SQL Server Management Studio) 개체 탐색기 사용하여 보조 복제본에 연결하고 관리, 확장 이벤트세션을 드릴합니다. AlwaysOn_health 이벤트를 마우스 오른쪽 단추로 클릭하고 라이브 데이터 감시를 선택합니다. 되돌리기 작업의 현재 상태를 보고하는 새 탭 창이 표시됩니다. 상태는 이벤트를 통해 hadr_trace_message 5분마다 보고되며, 되돌리기 작업의 완료 비율은 보고됩니다.

참고 항목

확장 이벤트는 hadr_trace_message SQL Server 2019 이상에서 최신 누적 업데이트에 추가되었습니다. 확장 이벤트 세션에서 이 확장 이벤트를 AlwaysOn_health 관찰하려면 최신 누적 업데이트를 실행해야 합니다.

AlwaysOn_health 확장 이벤트 진단 로그의 스크린샷

보조 복제본의 SQL Server 오류 로그는 되돌리기 완료를 예상할 때 큰 도움이 되지 않습니다. 다음 이미지에서 상태를 되돌리는 동안 10:08에서 11:03까지 관찰할 수 있지만 거의 보고되지 않습니다. 보조 복제본이 주 복제본에서 모든 페이지를 받으면 이제 되돌리기 상태를 트리거한 원래 주 복제본에서 실행 중인 트랜잭션을 롤백할 수 있습니다. 복구는 11:03부터 11:05까지 실행됩니다. 복구가 완료된 직후 데이터베이스는 주 복제본과 동기화를 시작하고 보조 데이터베이스가 되돌리기 상태인 동안 주 복제본에서 수행된 모든 변경 내용을 따라잡아야 합니다.

되돌리기 및 복구 단계에 대한 SQL Server 오류 로그의 스크린샷.

성능 모니터 사용하여 완료 시간 되돌리기 모니터링

성능 카운터 SQL Server:데이터베이스 복제본:실행 취소가 필요한 총 로그 및 SQL Server:데이터베이스 복제본:실행 취소에 대한 로그 잔여를 사용하여 상태 되돌리기 진행률을 모니터링하고 인스턴스에 대한 가용성 그룹 데이터베이스를 선택합니다. 다음 스크린샷의 예제에서 실행 취소가 필요한 총 로그는 56.3mb보고되고 실행 취소에 대한 남은 로그는 진행률을 되돌리는 것을 보고하는 0으로 서서히 삭제됩니다.

실행 취소가 필요한 총 로그의 성능 카운터 및 실행 취소에 대한 남은 로그 스크린샷

대기 이외의 다른 옵션은 무엇인가요?

되돌리기 상태 완료 시간을 예상하는 것이 좋습니다.

가용성 그룹에 보조 복제본 추가

가용성 그룹에 복제본이 두 개만 있는 경우 가능한 경우 다른 보조 복제본이 되돌리기를 완료하는 동안 고가용성 및 중복성을 제공하고 주 복제본과 적극적으로 동기화할 수 있는 다른 보조 복제본을 추가합니다.

Important

데이터베이스가 되돌리고 있는 복제본으로 장애 조치하지 마세요. 이로 인해 백업에서 복원해야 하는 사용할 수 없는 데이터베이스가 발생할 수 있습니다. 보조 복제본 인스턴스를 다시 시작하지 마세요. 이 프로세스는 가속화되지 않으며 되돌리기 상태인 보조 복제본 데이터베이스의 상태가 손상될 수 있습니다.

실패한 읽기 전용 워크로드를 해결하는 방법

되돌리는 보조 복제본 데이터베이스에 액세스할 수 없으므로 읽기 전용 워크로드가 실패합니다. 영향을 받는 보조 복제본 데이터베이스가 되돌리기 프로세스를 완료할 때까지 트래픽을 주 복제본 또는 다른 보조 복제본으로 다시 라우팅하도록 읽기 의도 라우팅 테이블을 업데이트합니다.

상태 되돌리기 방지 - 대용량 트랜잭션 모니터링

계획된 장애조치 중에 이 상태를 자주 관찰하는 경우 장애 조치(failover) 전에 큰 트랜잭션을 확인하는 절차를 구현합니다. 다음 쿼리는 시스템에서 열려 있는 트랜잭션의 트랜잭션 시작 시간과 현재 시간을 보고하고 트랜잭션의 입력 버퍼를 제공합니다.

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC

스크린샷은 열려 있는 트랜잭션의 시작 시간과 현재 시간을 보여줍니다.