500 개의 데이터베이스가있는 SQL Server 2017-CU9 이후 빈번한 AG 연결 끊기

15

여러분 안녕하세요, 미리 도와 주셔서 감사합니다. SQL Server 2017 가용성 그룹에 문제가 있습니다.

배경

회사는 소매 B2B 백엔드 소프트웨어입니다. 약 500 개의 단일 테넌트 데이터베이스와 모든 테넌트가 사용하는 5 개의 공유 데이터베이스. 워크로드 특성은 대부분 읽히고 대부분의 데이터베이스는 활동이 매우 적습니다.

공동 위치에서 호스팅되는 실제 프로덕션 서버는 최근 공유 SAN / FCI 구성의 Windows Server 2012의 SQL Server 2014 Enterprise에서 2 소켓 / 32 코어 / 768GB RAM 및 로컬의 Windows Server 2016의 SQL Server 2017 Enterprise로 업그레이드되었습니다. AlwaysOn AG를 사용하는 SSD 드라이브. AG 트래픽은 교차 케이블 연결로 전용 10G NIC 포트를 사용합니다.

요구 사항은 모든 데이터베이스를 페일 오버해야하므로 모두 단일 AG에 배치해야했습니다. 동일한 서버에서 읽을 수없는 단일 동기식 복제본입니다.

새로운 서버는 2018 년 6 월부터 양산되었습니다. 최신 CU (당시 CU7)와 Windows 업데이트가 설치되었으며 시스템이 제대로 작동했습니다. 약 한 달 후 CU7에서 CU9로 서버를 업데이트 한 후 우선 순위에 따라 다음과 같은 과제를 발견했습니다.

우리는 SQL Sentry를 사용하여 서버를 모니터링하고 물리적 병목 현상이 관찰되지 않았습니다. 모든 주요 지표는 양호 해 보입니다. CPU는 평균 20 %, IO 시간은 일반적으로 1ms 미만, RAM이 완전히 활용되지 않음 및 네트워크 <1 %입니다.

도전 과제

장애 조치 후 증상이 좋아지는 것처럼 보이지만 어느 서버가 기본 서버인지에 관계없이 며칠 내에 다시 나타납니다. 두 서버에서 증상이 동일합니다.

산발적 인 클라이언트 시간 초과 및 연결 실패

... 연결하는 동안 오류가 발생했습니다 ...

또는

실행 시간 초과가 만료되었습니다

때때로 이들은 최대 40 초 동안 지속 된 다음 가라 앉습니다.
트랜잭션 로그 백업 작업은 이전보다 10 배 더 오래 걸립니다. 이전에는 500 개의 데이터베이스 모두의 로그를 백업하는 데 2-3 분이 걸렸으며 이제는 15-25 개가 걸립니다. 우리는 백업 자체가 좋은 처리량으로 잘 작동한다는 것을 확인했습니다. 그러나 한 로그의 백업을 완료 한 후 다음 로그를 시작하기 전에 약간의 지연이 있습니다. 매우 낮게 시작되지만 하루나 이틀 안에 2-3 초가됩니다. 500 개의 데이터베이스를 곱하면 차이가 있습니다.
경우에 따라 수동 장애 조치 후 무작위로 보이는 일부 데이터베이스가 "동기화하지 않음"상태에 빠지는 경우가 있습니다. 이 문제를 해결하는 유일한 방법은 보조 복제본에서 SQL Server 서비스를 다시 시작하거나 이러한 데이터베이스를 제거한 후 AG에 다시 가입시키는 것입니다.
CU10에서 도입 된 또 다른 문제 (CU11에서는 해결되지 않음) : master.sys.databases에서 차단시 보조 시간 초과에 대한 연결 및 보조 복제본에 SSMS 개체 탐색기를 사용할 수 없음 근본 원인은 다음 쿼리를 실행하는 Microsoft SQL Server VSS 기록기에 의해 차단 된 것 같습니다.
```
select name, 
       recovery_model_desc, 
       state_desc, 
       CONVERT(integer, is_in_standby), 
       ISNULL(source_database_id,0) 
  from master.sys.databases
```

관찰

오류 로그에서 흡연 총을 발견했다고 생각합니다. 오류 로그는 AG 정보로 가득 차 있으며 '정보 만'으로 표시되지만 전혀 정상이 아닌 것처럼 보이며 응용 프로그램 오류와 빈도가 매우 밀접한 상관 관계가 있습니다.

오류는 여러 유형이며 순서대로 제공됩니다.

DbMgrPartnerCommitPolicy :: SetSyncState : GUID
DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint : GUID
복제본 ID가 {GUID} 인 가용성 복제본 'DB'에서 기본 데이터베이스 'XYZ'에 대해 보조 데이터베이스와의 AlwaysOn 가용성 그룹 연결이 종료되었습니다. 이것은 정보 메시지입니다. 사용자 조치가 필요하지 않습니다.
복제본 ID가 {GUID} 인 가용성 복제본 'DB'에서 기본 데이터베이스 'ABC'에 대해 보조 데이터베이스와 AlwaysOn 가용성 그룹 연결이 설정되었습니다. 이것은 정보 메시지입니다. 사용자 조치가 필요하지 않습니다.

어떤 날에는 수만 가지가 있습니다.

이 기사 에서는 SQL 2016의 동일한 유형의 오류 시퀀스에 대해 설명하고 비정상이라고 말합니다. 장애 조치 후 '비 동기화'현상에 대해서도 설명합니다. 논의 된 문제는 2016 년 문제이며 올해 초 CU에서 수정되었습니다. 그러나 AG가 이미 설정되어 있으므로 여기서는 안되는 자동 초기 시드 메시지에 대한 참조를 제외하고 처음 두 가지 유형의 메시지에 대해 찾을 수있는 유일한 관련 참조입니다.

다음은 PRIMARY에서 유형 당> 10K 오류가 발생한 날의 지난주 일일 오류 요약입니다 (2 차에서는 '기본 연결과 연결이 끊어짐 ...').

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

때때로 다음과 같은 "이상한"메시지가 나타납니다.

역할 동기화로 인해 미러링 세션 또는 가용성 그룹이 페일 오버되었으므로 가용성 그룹 데이터베이스 "DB"가 역할을 "SECONDARY"에서 "SECONDARY"로 변경하고 있습니다. 이것은 정보 메시지입니다. 사용자 조치가 필요하지 않습니다.

... "SECONDARY"에서 "RESOLVING"으로 상태가 변경되는 호스트 중.

수동 장애 조치 후 시스템은 이러한 유형의 단일 메시지없이 며칠 동안 진행될 수 있으며 갑작스런 이유없이 한 번에 수천 개가 발생하여 서버가 응답하지 않고 응용 프로그램이 발생합니다. 연결 시간이 초과되었습니다. 일부 응용 프로그램에는 재시도 메커니즘이 포함되어 있지 않으므로 데이터가 손실 될 수 있으므로 이는 심각한 버그입니다. 이러한 오류가 발생하면 다음 대기 유형이 급등합니다. 이것은 AG가 한 번에 모든 데이터베이스에 대한 연결을 끊은 것으로 보이는 직후의 대기를 보여줍니다.

약 30 초 후에 모든 것이 대기 상태로 정상으로 돌아가지만 AG 메시지는 다양한 비율로 하루 중 다른 시간에 오류 로그를 계속 넘치게됩니다. 이러한 오류 발생시 작업 부하가 동시에 증가하면 상황이 악화됩니다. 소수의 데이터베이스 만 연결이 끊어지면 일반적으로 자체적으로 충분히 빨리 해결되므로 연결 시간이 초과되지 않습니다.

실제로 문제를 시작한 CU9인지 확인하려고했지만 두 노드 만 CU9로 다운 그레이드 할 수있었습니다. 두 노드 중 하나를 CU8로 다운 그레이드하려고하면 해당 노드가 로그에 동일한 오류를 표시하는 '해결 중'상태로 고정됩니다.

해당 리소스 ID가 '… 인 Always On 가용성 그룹의 지속적 구성을 읽을 수 없습니다. 지속 구성은 기본 가용성 복제본을 호스팅하는 상위 버전의 SQL Server에 의해 작성됩니다. 로컬 가용성 복제본이 보조 복제본이되도록 로컬 SQL Server 인스턴스를 업그레이드하십시오.

즉, 두 노드를 동시에 CU8로 다운 그레이드 할 수 있도록 다운 타임을 도입해야합니다. 이것은 또한 우리가 겪고있는 것을 설명 할 수있는 AG에 대한 주요 업데이트가 있음을 시사합니다.

우리는 이미 max_worker_threads를 기본값 0 ( 이 기사 의 상자에서 = 960 )에서 점진적으로 최대 2,000까지 조정하여 오류에 영향을 미치지 않았습니다.

이러한 AG 단절을 해결하기 위해 무엇을 할 수 있습니까? 비슷한 문제가 발생하는 사람이 있습니까? AG에 데이터베이스가 많은 다른 사람들이 CU9 또는 CU8로 시작하는 SQL 오류 로그에서 유사한 메시지를 볼 수 있습니까?

도움을 주셔서 감사합니다.

sql-server availability-groups sql-server-2017

— SQLRaptor
소스

9

최신 정보:

상용 가용성 그룹 연결 끊기는 CU9에 의해 도입 된 회귀 인 것으로 확인되었으며 CU12 설치 후 해결되었습니다.
보조 복제본의 차단 문제는 CU10에 도입 된 VSS 기록기 코드 업데이트 관련 문제인 것으로 확인되었습니다. CU 13에서 해결 될 수 있기를 바랍니다. 임시 솔루션은 VSS 기록기 DLL을 Pre-CU10 DLL로 수동으로 대체하는 것입니다.
```
BEGIN RANT-SACTION;
```
불행히도 Microsoft는 Windows 10 업데이트뿐만 아니라 SQL Server와 같은 엔터프라이즈 미션 크리티컬 소프트웨어도 제대로 QA하지 못하는 것으로 보입니다.

나는 이전 서비스 팩 전략을 선호했는데, 적어도 절반의 업데이트가 부주의하게 릴리스되어 고객에게 생산 위기와 데이터 손실이 발생하기 전에 제대로 테스트 할 시간이 충분했습니다.
```
COMMIT RANT-SACTION;
```

— SQLRaptor
소스

2

작업자 스레드를 확인 했습니까? 일반적으로 항상 더 많은 작업자 스레드를 사용하여 작동하며 일반적으로 기본값은 충분하지 않습니다. 항상 600 데이터베이스와 동일한 문제가 발생했기 때문에 인스턴스 매개 변수에 더 많은 스레드를 추가하여 문제를 해결했습니다. 도움이 되었기를 바랍니다!

— 곤잘로 비시오
소스

2

@ 곤잘로 안녕하세요 조언에 감사드립니다. 우리는 이미 max_worker_threads 설정 각도를 다루었지만, 스레드가 충분하지 않은 경우에 일반적인 "사용 가능한 작업자 스레드 없음"과 같은 오류는 발생하지 않았습니다. 박스의 기본값은 1k 미만의 스레드였으며 오류에 영향을 미치지 않으면 서 점진적으로 2K까지 올렸습니다. 작업자 스레드 메트릭을 수집하며 최대 값으로 계산되지 않은 AG 스레드를 포함하여 평균 약 1500입니다. 따라서 스레드 제한에서 멀리 떨어져 있습니다.

— SQLRaptor