서버 재부팅 후 SQL Server Distributed Availability Group 데이터베이스가 동기화되지 않음

SQL Server에서 대규모 업그레이드 를 수행 할 준비가되었으며 앞으로 나아 가기 전에 해결하려는 Distributed Availability Groups의 비정상적인 동작에 주목하고 있습니다.

지난 달에 원격 보조 서버를 SQL Server 2016에서 SQL Server 2017로 업그레이드했습니다.이 서버는 여러 DAG (Distributed Availability Group) 와 별도의 AG (가용성 그룹)의 일부 입니다. 이 서버를 업그레이드 할 때 서버가 읽을 수없는 상태 가 될 것이라는 것을 알지 못했기 때문에 지난 한 달 동안 주 서버에만 의존했습니다.

다가오는 업그레이드의 일환으로 CU 4 패치를 서버에 적용하고 재부팅했습니다. 서버가 온라인 상태로 돌아 왔을 때 방금 패치 된 보조 서버는 모든 DAG / AG가 문제없이 동기화되고 있음을 보여주었습니다.

그러나 기본은 매우 다른 이야기를 보여주었습니다. 보고했다

• 별도의 AG가 문제없이 동기화되었습니다
• 그러나 DAG가 동기화되지 않음 / 건강하지 않음 상태에 있었습니다.

처음에 당황한 후 DAG에서 다시 동기화하기 위해 다음 사항을 시도했습니다.

• 기본에서 데이터 이동을 중단했다가 다시 시작했습니다. 데이터 동기화가 시작되지 않았습니다.
• 보조 (방금 패치 한 것)에서 ALTER DATABASE [<database] SET HADR RESUME;오류없이 실행되었지만 동기화를 다시 시작하지 않았습니다.

데이터를 다시 동기화하려는 마지막 시도는 보조 서버에 로그인하고 SQL Server 서비스를 수동으로 다시 시작하는 것입니다. 서버를 재부팅하면 충분할 것으로 예상되므로 수동으로 서비스를 다시 시작하는 것은 약간 극단적 인 것처럼 보입니다.

재부팅 후에 DAG가 보조 서버와 동기화를 시작하지 않는 사람이이 문제에 부딪 쳤습니까? 그렇다면 어떻게 해결 되었습니까?

SQL Server 오류 로그와 보조 서버의 이벤트 뷰어를 모두 확인했는데 평소에 아무것도 볼 수 없었습니다.

이것은 정답은 아니지만 Taryn 과 채팅 한 후 가장 좋은 답변 입니다.

그러나 기본은 매우 다른 이야기를 보여주었습니다. 별도의 AG가 아무런 문제없이 동기화되고 있지만 DAG가 동기화되지 않음 / 정상 상태가 아님을보고했습니다.

분산 된 Aggregation의 기반이되는 개별 데이터베이스와 AG가 정상 상태와 동기화 중이라고 말하면 DMV 및 / 또는 SSMS 대시 보드에서 문제가 될 가능성이 큽니다. 오류 로그에 복제본이 연결되지 않았거나 연결이 끊어진 상태임을 암시하는 것이 없기 때문에.

불행히도 문제가 해결 된 후 정확히 무엇인지 말하기는 어렵지만 앞으로 누군가에게 이런 일이 발생하면 :

• 건강하지 않은 것을 찾는 모든 클러스터에서 sys.dm_hadr_database_replica_states 를 확인하십시오 . 모든 것이 정상으로 표시되면 DMV가 아직 업데이트되지 않았을 가능성이 있습니다
• 비정상 인 경우 오류 로그 / DMV에서 연결 문제 (예 : 전달자 / 글로벌 기본에 연결할 수 없음)가 있는지 확인하십시오.
• Dan의 답변은 데이터베이스 시작으로 발생할 수있는 문제를 언급합니다.이 경우 인스턴스를 읽을 수 없어서 문제가 아니었을 수도 있지만 귀하의 경우에도 발생할 수 있습니다.
• 데이터베이스를 읽을 수있는 경우 더미 테이블 / 삽입 또는 ...
• DEBUG 채널 항목을 사용 sqlserver.hadr_dump_log_block하거나 sqlserver.hadr_apply_log_block보조 채널 이 실제로 로그 블록을 수신 / 적용하는지 확인하기 위한 확장 이벤트 세션 또는 ...
• 퍼프 먼 객체 SQLServer:Database Replica\Log Bytes Received/sec

해당 보조에 대한 데이터를 수신하고 있지만 분산 Ag가 여전히 동기화되지 않거나 정상 상태가 아닌 것으로 표시되는 경우 로그 블록을 수신하고 처리하기 때문에 DMV 값이 변경되는지 조금 살펴 보겠습니다.

그러나 그렇지 않은 경우에는 답변 범위를 벗어나는 추가 조사가 필요합니다.

프로덕션 환경에 DAG가 없다는 경고에이 모든 것을 소개합니다. 기본적으로이 조언은 AG와 DAG 모두에 적용되어야합니다.

서비스가 다시 시작된 후 동기화가 다시 시작 되었습니까? 그렇다면 원인에 대한 최선의 추측은 다시 실행 SPID를 차단하는 것입니다. 다시 시작한 후에도 여전히 동기화되지 않으면 먼저 확인해야 할 사항이 있습니다.

AG redo SPID 차단

일반적으로 읽기 가능한 보조에서만 발생합니다. 확인하려면 다음을 실행하십시오.

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

차단 SPID가 나타나면 보조 DB STARTUPSPID를 다시 시작하기 전에 SPID를 종료해야합니다 ( SPID는 리두 작업을 처리하는 것입니다). 먼저 차단 SPID를 검토하여 원인 (보통 장기 보고서)을 확인하는 것이 좋습니다.

이에 대한 추가 정보가 필요하면 여기에 훌륭한 기사 (XE를 사용하여 이러한 유형의 동작 모니터링 포함)가 있습니다 .

DMV 확인

데이터 이동이 일시 중단 된 경우 일시 중단 이유에 대한 자세한 정보를 얻기 위해 DMV를 참조 할 수 있습니다. 다음을 실행하십시오.

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

BOL 기사는 조금 더 suspend_reason에 대해 설명합니다.

DAG (Distributed Availability Group)가 다른 지역으로 분할되어 있습니까? 그렇다면 기본 SESSION_TIMEOUT 값 (10 초)이 너무 낮아질 수 있습니다. 즉, 두 지역 간의 대기 시간이 너무 길어 안정적으로 동기화를 완료 할 수 없습니다.

일반 가용성 그룹은 SESSION_TIMEOUT 값을 늘려 동기화 세션을보다 안정적으로 만들 수 있습니다. 작년 말 DAG의 SESSION_TIMEOUT 매개 변수를 편집 할 수 없다는 것을 알았습니다. 이는 DAG가 지연 시간이 짧은 시나리오에서만 실행 가능하다는 것을 의미했습니다. 우리는 Microsoft에 티켓을 기록했으며 올해 초에 핫픽스가 릴리스되었습니다.

개선 : SQL Server 2016 및 2017에서 분산 가용성 그룹 복제본에 대한 SESSION_TIMEOUT 값 구성