빠른 VPN도 동기식 SQL 커밋을 느리게 만드는 이유

프라이머리에서 쿼리 세션을 열고 단순한 쓰기가 무엇을 기다리는지 확인하세요. 데이터베이스가 동기 커밋 가용성 그룹에 속하고 보조 복제본이 연결되어 있으면 그 대기의 일부는 건물 밖으로 나갑니다: 로그 레코드가 복제본으로 이동해 그곳에서 강화되고, 그 강화에 대한 소식이 커밋이 끝나기 전에 돌아옵니다. 대역폭은 그 왕복을 줄이지 않습니다. 아래 설명은 화면에서 원격 디스크까지 그리고 다시 돌아오는 승인을 추적합니다.

프라이머리의 대기 유형에서 시작하세요

원격 복제본에서 기다리는 쓰기는 CPU나 잠금 대기가 아니라 로그와 관련된 대기로 나타나며, 트랜잭션 기간은 행 수가 아니라 왕복을 따릅니다. 작은 커밋이 많을수록 각각이 왕복 비용을 따로 지불하므로 분명해집니다. 한 번의 대량 작업은 같은 비용을 더 긴 승인 하나 안에 숨깁니다.

링크에 대해 어떤 결론을 내리기 전에 작업 부하를 커밋 빈도로 정렬하세요.

네트워크를 읽기 전에 복제본 상태를 읽으세요. 중요한 카운터는 전송 큐, redo 큐, 동기화 상태이며, 함께 보조 복제본이 따라가고 있는지 뒤처지는지 보여 줍니다. 커지는 전송 큐는 전송을 가리키고, 커지는 redo 큐는 보조 복제본 자체의 작업이나 스토리지를 가리킵니다. 이는 서로 다른 수리이며, 대역폭을 더해도 어느 쪽도 나아지지 않습니다.

승인을 보조 복제본까지 따라가세요

동기 커밋에서는 프라이머리가 커밋을 완료로 보고하기 전에 해당 로그가 보조 복제본에서 강화되었다는 확인을 기다립니다. 강화되었다는 것은 로그에 내구적으로 기록되었다는 뜻이며, 데이터 페이지로 재생되었다는 뜻이 아닙니다. 바로 이 구분 때문에 동기 보조 복제본이 redo에서 뒤처지면서도 강화를 확인할 수 있습니다.

경로를 순서대로 걸으며 전체가 아니라 각 단계를 측정하세요. 로그 레코드는 전송을 거치고, 보조 복제본이 이를 쓰고 플러시하며, 승인은 같은 경로로 돌아옵니다. 전송 지연, 보조 복제본의 스케줄링, 보조 복제본 로그 디스크의 지연이 모두 합계에 들어가며, 첫 번째만 네트워크 담당자의 몫입니다. 로그 볼륨이 다른 무언가로 포화된 보조 복제본은 링크가 유휴 상태여도 모든 커밋을 늘릴 수 있습니다.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

조용한 오후에 한 번이 아니라 대표적인 쓰기 전후에 그 스냅숏을 찍으세요. 차이가 커밋을 기다리는 동안 어느 큐가 움직였는지 알려 줍니다.

링크가 아니라 경로를 측정하세요

처리량 테스트는 여러분의 복제본이 아닌 두 지점 사이의 용량을 여러분의 작업이 아닌 부하에서 측정합니다. 실제 트래픽이 흐르는 동안 실제 복제본 경로를 따라 양방향으로 지연과 손실을 네트워크 담당자에게 요청하세요. 여기서는 손실된 세그먼트가 재전송 비용을 낳고 모든 커밋이 승인 하나를 기다리기 때문에 손실이 용량보다 중요합니다. 다운로드 테스트에서 훌륭해 보이는 링크도 말 많은 커밋 패턴에는 부적합할 수 있습니다.

측정하는 동안 데이터베이스 전송 보안과 접근 제어를 그대로 유지하세요. 경로를 측정하는 일은 결코 그것들을 우회할 이유가 아닙니다.

시간을 직관이 아니라 카운터와 연관 지으세요. 전송 큐가 비어 있는데 커밋이 여전히 기다리면 지연은 승인이나 보조 복제본의 플러시에 있습니다. 전송 큐가 꾸준히 커지면 전송이나 용량이 제약입니다. 어떤 관찰이 결론을 뒷받침했는지 기록해 다음 사람이 논쟁이 아니라 측정을 반복할 수 있게 하세요.

비동기 모드가 실제로 바꾸는 것

비동기 커밋은 보조 복제본의 강화 승인을 기다리는 것을 없애므로 쓰기가 빨라지고 따라서 내구성 위치가 바뀝니다. 프라이머리는 그 원격 확인 없이 트랜잭션을 확정합니다. 그러면 보조 복제본이 뒤처지는 것이 허용되며, 그 뒤처짐이 곧 노출입니다.

로그가 사용 가능한 장애 조치 대상에 도달하기 전에 프라이머리를 잃으면, 해당 복제본으로 서비스를 강제로 옮기는 것은 애플리케이션에 이미 커밋되었다고 알린 트랜잭션을 버립니다.

이는 복구 지점에 대한 결정이며 데이터베이스 소유자의 몫이고 성능 검토의 몫이 아닙니다. 먼저 허용되는 데이터 손실 창을 정하고, 그것을 충족하는 모드를 선택한 다음 그 경계 안에서 최적화하세요. 동기 보호를 유지하는 선택지에는 애플리케이션이 허용하는 곳에서 피할 수 있는 커밋 왕복을 없애기, 측정된 전송 또는 스토리지 병목 고치기, 승인이 더 짧은 거리를 이동하도록 복제본 옮기기가 포함됩니다. 시작할 때의 변하지 않은 내구성 요구와 견주어 저울질하세요.