다음을 통해 공유


가동 중지 시간 및 데이터 손실을 최소화하여 가용성 그룹 서버 업그레이드 및 업데이트

SQL Server 2012에서 서비스 팩 또는 최신 버전으로 서버 인스턴스를 업데이트하거나 업그레이드하는 경우 순차적 업데이트 또는 업그레이드를 수행하여 가용성 그룹의 가동 중지 시간을 단일 수동 장애 조치(failover)로 줄일 수 있습니다. SQL Server 버전을 업그레이드하는 경우 롤링 업그레이드라고 합니다. 핫픽스 또는 서비스 팩을 사용하여 현재 SQL Server 버전을 업데이트하는 경우 롤링 업데이트라고 합니다.

이 항목에서는 설명을 SQL Server 업그레이드/업데이트로만 제한합니다. 고가용성 SQL Server 인스턴스가 실행 중인 운영 체제 관련 업그레이드/업데이트는 운영 체제 업그레이드를 위한 AlwaysOn 가용성 그룹의 클러스터 간 마이그레이션을 참조하세요.

AlwaysOn 가용성 그룹에 대한 롤링 업그레이드/업데이트 모범 사례

가용성 그룹에 대한 가동 중지 시간 및 데이터 손실을 최소화하기 위해 서버 업그레이드/업데이트를 수행할 때 다음 모범 사례를 관찰해야 합니다.

  • 롤링 업그레이드/업데이트를 시작하기 전에

    • 동기-커밋 복제본 중 하나 이상에서 수동 장애 전환을 연습용으로 실행합니다.

    • 모든 가용성 데이터베이스에 대해 전체 데이터베이스 백업을 수행하여 데이터를 보호합니다.

    • 모든 가용성 데이터베이스에서 DBCC CHECKDB 실행

  • 항상 원격 보조 복제본 노드를 먼저 업그레이드/업데이트한 다음, 로컬 보조 복제본 노드 다음에 주 복제본 노드를 마지막으로 업그레이드/업데이트합니다.

  • 업그레이드 중인 데이터베이스에서는 백업을 수행할 수 없습니다. 보조 복제본을 업그레이드하기 전에 기본 복제본에 대해서만 백업을 실행하도록 자동화된 백업 기본 설정을 구성합니다. 주 복제본을 업그레이드하기 전에 보조 복제본에서만 백업을 실행하도록 이 설정을 수정합니다.

  • 업그레이드/업데이트 프로세스 중에 가용성 그룹이 의도하지 않은 장애 조치(failover)를 방지하려면 시작하기 전에 모든 동기-커밋 복제본에서 가용성 장애 조치(failover)를 제거합니다.

  • 가용성 그룹을 보조 복제본이 있는 업그레이드된 노드로 장애 조치하기 전에 주 복제본 노드를 업그레이드하지 마세요. 그렇지 않으면 클라이언트 애플리케이션은 주 복제본에서 업그레이드/업데이트하는 동안 가동 중지 시간이 길어질 수 있습니다.

  • 항상 동기 커밋 보조 복제본 노드로 가용성 그룹을 장애 조치(페일오버)하십시오. 비동기 커밋 보조 복제본으로 장애 조치하는 경우 데이터베이스는 데이터 손실을 겪고 데이터 이동을 수동으로 다시 시작할 때까지 데이터 이동이 자동으로 일시 중단됩니다.

  • 다른 보조 복제본 노드를 업그레이드/업데이트하기 전에 주 복제본 노드를 업그레이드/업데이트하지 마세요. 업그레이드된 주 복제본은 더 이상 로그를 동일한 버전으로 업그레이드되지 않은 보조 복제본으로 전송할 수 없습니다. 보조 복제본으로 데이터 이동이 일시 중지된 경우 해당 복제본에 대한 자동 장애 조치(failover)를 수행할 수 없고 가용성 데이터베이스의 데이터가 손실될 수 있습니다.

  • 가용성 그룹을 장애 조치하기 전에 장애 조치 대상의 동기화 상태가 SYNCHRONIZED인지 확인합니다.

롤링 업그레이드/업데이트 프로세스

실제로 정확한 프로세스는 가용성 그룹의 배포 토폴로지 및 각 복제본의 커밋 모드와 같은 요인에 따라 달라집니다. 그러나 가장 간단한 시나리오에서 롤링 업그레이드/업데이트는 가장 간단한 형식으로 다음 단계를 포함하는 다단계 프로세스입니다.

HADR 시나리오에서 가용성 그룹 업그레이드

  1. 모든 동기-커밋 복제본에서 자동 장애 조치(failover)를 제거합니다.

  2. 비동기 커밋 보조 복제본을 실행하는 모든 원격 서버 인스턴스 업그레이드/업데이트

  3. 현재 주 복제본을 실행하지 않는 모든 로컬 서버 인스턴스 업그레이드/업데이트

  4. 수동으로 가용성 그룹을 동기 커밋 보조 복제본으로 장애 조치합니다.

  5. 이전에 주 복제본을 호스팅한 서버 인스턴스 업그레이드/업데이트

  6. 원하는 대로 자동 페일오버 파트너를 구성하십시오.

필요한 경우 추가 수동 장애 조치(failover)를 수행하여 가용성 그룹을 원래 구성으로 반환할 수 있습니다.

하나의 원격 보조 복제본이 있는 가용성 그룹

재해 복구용으로만 가용성 그룹을 배포한 경우, 가용성 그룹을 비동기 커밋 보조 복제본으로 전환해야 할 수 있습니다. 다음 그림에서는 이 구성을 보여 줍니다.

DR 시나리오에서 가용성 그룹 업그레이드

이 경우 롤링 업그레이드/업데이트 중에 가용성 그룹을 비동기 커밋을 사용하는 보조 복제본으로 장애 조치해야 합니다. 데이터 손실을 방지하려면 커밋 모드를 동기 커밋으로 변경하고 가용성 그룹을 장애 조치하기 전에 보조 복제본이 동기화될 때까지 기다립니다. 따라서 롤링 업그레이드/업데이트 프로세스는 다음과 같이 표시할 수 있습니다.

  1. 원격 서버 업그레이드/업데이트

  2. 커밋 모드를 동기 커밋으로 변경

  3. 동기화 상태가 SYNCHRONIZED가 될 때까지 기다립니다.

  4. 가용성 그룹을 원격 사이트로 장애 조치하십시오

  5. 로컬(기본 사이트) 서버 업그레이드/업데이트

  6. 가용성 그룹을 주 사이트에서 장애 조치 작업 수행

  7. 커밋 모드를 비동기 커밋으로 변경

동기-커밋 모드는 원격 사이트에 대한 데이터 동기화에 권장되는 설정이 아니므로 클라이언트 애플리케이션은 설정 변경 후 데이터베이스 대기 시간이 즉시 증가할 수 있습니다. 또한 장애 조치(failover)를 수행하면 승인되지 않은 모든 로그 메시지가 삭제됩니다. 두 사이트 간의 네트워크 대기 시간이 높기 때문에 삭제된 로그 메시지의 양이 상당히 클 수 있으므로 클라이언트에서 대량의 트랜잭션 오류가 발생할 수 있습니다. 다음을 수행하여 클라이언트 애플리케이션에 미치는 영향을 최소화할 수 있습니다.

  • 클라이언트 트래픽이 낮을 때 유지 관리 기간을 신중하게 선택합니다.

  • 기본 사이트에서 SQL Server를 업그레이드/업데이트하는 동안 가용성 모드를 비동기 커밋으로 변경한 후, 다시 기본 사이트로 장애 조치를 수행할 준비가 되면 동기 커밋으로 되돌리십시오.

장애 조치(failover) 클러스터 인스턴스 노드를 사용하는 가용성 그룹

가용성 그룹에 FCI(장애 조치(failover) 클러스터 인스턴스) 노드가 포함된 경우 활성 노드를 업그레이드/업데이트하기 전에 비활성 노드를 업그레이드/업데이트해야 합니다. 아래 그림에서는 원격 재해 복구를 위한 FCI와 업그레이드 시퀀스 간의 로컬 고가용성 및 비동기 커밋에 대한 FCI를 사용하는 일반적인 가용성 그룹 시나리오를 보여 줍니다.

FCI와 함께 가용성 그룹 업그레이드

  1. 업그레이드/업데이트 REMOTE2

  2. FCI2를 "fail over"하여 REMOTE2로 장애 조치하십시오.

  3. 업그레이드 및 업데이트 REMOTE1

  4. 업그레이드/업데이트 PRIMARY2

  5. FCI1을 PRIMARY2로 장애 처리하세요.

  6. 업그레이드/업데이트 PRIMARY1

여러 가용성 그룹을 사용하여 SQL Server 인스턴스 업그레이드/업데이트

개별 서버 노드(활성/활성 구성)에서 주 복제본을 사용하여 여러 가용성 그룹을 실행하는 경우 업그레이드/업데이트 경로에는 프로세스에서 고가용성을 유지하기 위한 더 많은 장애 조치(failover) 단계가 포함됩니다. 다음 표와 같이 3개의 서버 노드에서 세 개의 가용성 그룹을 실행하고 있으며 모든 보조 복제본이 동기-커밋 모드에서 실행되고 있다고 가정합니다.

가용성 그룹 Node1 Node2 Node3
AG1 기본
AG2 기본
AG3 기본

부하가 분산된 롤링 업그레이드/업데이트를 다음 순서로 수행하는 것이 상황에 적절할 수 있습니다.

  1. AG2를 Node3으로 장애 조치하여 Node2의 리소스를 확보하기 위해

  2. Node2 업그레이드/업데이트

  3. AG1을 Node2로 장애 조치하여 Node1을 확보합니다.

  4. Node1 업그레이드/업데이트

  5. AG2와 AG3을 Node1로 장애 조치하여 Node3를 해제합니다.

  6. Node3 업그레이드/업데이트

  7. AG3를 Node3로 장애 조치하십시오.

이 업그레이드/업데이트 순서의 평균 가동 중지 시간은 각 가용성 그룹에서 장애 조치(failover) 횟수가 2회 미만입니다. 결과 구성은 아래 표에 나와 있습니다.

가용성 그룹 Node1 Node2 Node3
AG1 기본
AG2 기본
AG3 기본

특정 구현에 따라 업그레이드/업데이트 경로가 달라질 수 있으며 클라이언트 애플리케이션에서 발생하는 가동 중지 시간도 달라질 수 있습니다.