Always On 가용성 그룹 복제본 인스턴스 업그레이드Upgrading Always On Availability Group Replica Instances

이 항목은 다음에 적용됩니다. 예SQL Server(2016부터 시작)아니요Azure SQL 데이터베이스아니요Azure SQL 데이터 웨어하우스아니요병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL Server (starting with 2016)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

SQL ServerSQL Server Always On 가용성 그룹을 신규 SQL Server 2017SQL Server 2017 버전, 신규 SQL ServerSQL Server서비스 팩 또는 누적 업데이트로 업그레이드하거나 신규 Windows 서비스 팩 또는 누적 업데이트를 설치하려는 경우 롤링 업그레이드를 수행하여 주 복제본을 단일 수동 장애 조치(Failover)에만 적용하여 가동 중지 시간을 단축할 수 있습니다(또는 원본 주 복제본이 실패하는 경우 두 개의 수동 장애 조치(Failover)).When upgrading a SQL ServerSQL Server Always On Availability Group to a new SQL Server 2017SQL Server 2017 version, to a new SQL ServerSQL Serverservice pack or cumulative update, or when installing to a new Windows service pack or cumulative update, you can reduce downtime for the primary replica to only a single manual failover by performing a rolling upgrade (or two manual failovers if failing back to the original primary). 업그레이드 프로세스 동안 읽기 전용 작업 또는 장애 조치(Failover)에서는 보조 복제본을 사용할 수 없고 업그레이드 이후에는 주 복제본 노드에서의 작업 크기에 따라 보조 복제본이 주 복제본 노드를 따라잡기 위해서는 약간의 시간이 걸릴 수 있습니다(이로 인해 높은 네트워크 트래픽이 예상됨).During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and, after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic).

참고

이 항목은 SQL Server 업그레이드에 대한 설명으로 제한됩니다.This topic limits the discussion to the upgrade of SQL Server itself. WSFC(Windows Server Failover Clusting) 클러스터를 포함하는 운영 체제 업그레이드를 다루지 않습니다.It does not cover upgrading the operating system containing the Windows Server Failover Clusting (WSFC) cluster. Windows Server 2012 R2 이전의 운영 체제에서는 장애 조치(Failover) 클러스터를 호스팅하는 Windows 운영 체제 업그레이드가 지원되지 않습니다.Upgrading the Windows operating system hosting the failover cluster is not supported for operating systems before Windows Server 2012 R2. Windows Server 2012 R2에서 실행되는 클러스터 노드를 업그레이드하려면 클러스터 운영 체제 롤링 업그레이드를 참조하세요.To upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade

필수 구성 요소Prerequisites

시작하기 전에 다음과 같은 중요한 정보를 검토하십시오.Before you begin, review the following important information:

  • Supported Version and Edition Upgrades: 사용자의 Windows 운영 체제 버전 및 SQL Server 버전에서 SQL Server 2016으로 업그레이드할 수 있는지 확인합니다.Supported Version and Edition Upgrades: Verify that you can upgrade to SQL Server 2016 from your version of the Windows operating system and version of SQL Server. 예를 들어, SQL Server 2005 인스턴스에서 SQL Server 2017SQL Server 2017로 직접 업그레이드할 수 없습니다.For example, you cannot upgrade directly from a SQL Server 2005 instance to SQL Server 2017SQL Server 2017.

  • Choose a Database Engine Upgrade Method: 지원되는 버전 및 버전 업그레이드에 대한 검토와 사용자 환경에 설치된 기타 구성 요소를 바탕으로 적절한 업그레이드 방법 및 단계를 선택하여 올바른 순서로 구성 요소를 업그레이드합니다.Choose a Database Engine Upgrade Method: Select the appropriate upgrade method and steps based on your review of supported version and edition upgrades and also based on other components installed in your environment to upgrade components in the correct order.

  • 데이터베이스 엔진 업그레이드 계획 및 테스트: 릴리스 정보 및 알려진 업그레이드 문제, 업그레이드 전 검사 목록을 검토한 후 업그레이드 계획을 개발하고 테스트합니다.Plan and Test the Database Engine Upgrade Plan: Review the release notes and known upgrade issues, the pre-upgrade checklist, and develop and test the upgrade plan.

  • SQL Server 2016 설치를 위한 하드웨어 및 소프트웨어 요구 사항: SQL Server 2017SQL Server 2017를 설치하기 위한 소프트웨어 요구 사항을 검토합니다.Hardware and Software Requirements for Installing SQL Server 2016: Review the software requirements for installing SQL Server 2017SQL Server 2017. 추가 소프트웨어가 필요한 경우 가동 중지 시간을 최소화할 수 있도록 업그레이드 프로세스를 시작하기 전에 각 노드에 해당 소프트웨어를 설치하세요.If additional software is required, install it on each node before you begin the upgrade process to minimize any downtime.

Always On 가용성 그룹의 롤링 업그레이드를 위한 최상의 방법Rolling Upgrade Best Practices for Always On Availability Groups

서버 업그레이드 도는 업데이트를 수행할 때 가용성 그룹에 대한 가동 중단 시간 및 데이터 손실을 최소화하기 위해 다음과 같은 최상의 방법을 구현해야 합니다.The following best practices should be observed when performing server upgrades or updates in order to minimize downtime and data loss for your availability groups:

  • 롤링 업그레이드를 시작하기 전에Before starting the rolling upgrade,

    • 동기-커밋 복제본 인스턴스 중 하나 이상에서 수동 장애 조치(Failover)를 연습해 봅니다.Perform a practice manual failover on at least one of your synchronous-commit replica instances

    • 모든 가용성 데이터베이스에 대해 전체 데이터베이스 백업을 수행하여 데이터를 보호합니다.Protect your data by performing a full database backup on every availability database

    • 모든 가용성 데이터베이스에서 DBCC CHECKDB를 실행합니다.Run DBCC CHECKDB on every availability database

  • 항상 원격 보조 복제본을 먼저 업그레이드한 후 로컬 보조 복제본 인스턴스와 주 복제본 인스턴스 순으로 업그레이드합니다.Always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last.

  • 업그레이드되고 있는 데이터베이스에 대한 백업은 발생할 수 없습니다.Backups cannot occur on a database that is in the process of being upgraded. 보조 복제본을 업그레이드하기 전에 주 복제본에 대해서만 백업을 실행하도록 자동화된 백업 기본 설정을 구성합니다.Prior to upgrading the secondary replicas, configure the automated backup preference to run backups only on the primary replica. 버전을 업그레이드하는 동안 백업을 위해 복제본을 읽거나 사용할 수 없습니다.During a version upgrade, no replicas will be readable or available for backups. 비-버전 업그레이드 동안 자동화 업데이트가 보조 복제본에서 실행되도록 구성한 후 주 복제본을 업그레이드할 수 있습니다.During a non-version upgrade, you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.

  • 버전 업그레이드 동안 읽기 가능 보조 복제본은 읽기 가능 보조 복제본을 업그레이드한 후 및 주 복제본이 업그레이드된 보조 복제본으로 장애 조치(Failover)되거나 주 복제본이 업그레이드되기 이전에 읽을 수 없습니다.During a version upgrade, readable secondaries cannot be read after an upgrade of the readable secondary and before either the primary replica is failed over to an upgraded secondary or the primary replica is upgraded.

  • 업그레이드 프로세스 동안 가용성 그룹에서 의도하지 않은 장애 조치(failover)를 수행하지 않도록 시작하기 전에 모든 동기-커밋에서 가용성 장애 조치(failover)를 제거하십시오.To prevent the availability group from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.

  • 가용성 그룹을 보조 복제본이 포함된 업그레이드된 인스턴스로 장애 조치(Failover)하기 전에 주 복제본 인스턴스를 업그레이드해서는 안 됩니다.Do not upgrade the primary replica instance before failing over the availability group to an upgraded instance with a secondary replica first. 그렇지 않으면 주 복제본 인스턴스에서 업그레이드를 진행하는 동안 클라이언트 응용 프로그램의 작동 중단 시간이 길어질 수 있습니다.Otherwise, client applications may suffer extended downtime during the upgrade on the primary replica instance.

  • 항상 가용성 그룹을 동기-커밋 보조 복제본 인스턴스로 장애 조치(failover)합니다.Always fail over the availability group to a synchronous-commit secondary replica instance. 비동기-커밋 보조 복제본 인스턴스로 장애 조치(failover)하는 경우 데이터베이스의 데이터가 손실되고, 데이터 이동을 수동으로 다시 시작할 때까지 데이터 이동이 자동으로 중지됩니다.If you fail over to an asynchronous-commit secondary replica instance, the databases will suffer data loss, and data movement is automatically suspended until you manually resume data movement.

  • 다른 보조 복제본 노드를 업그레이드하기 전에 주 복제본 인스턴스를 업그레이드해서는 안 됩니다.Do not upgrade the primary replica instance before upgrading or updating any other secondary replica instance. 업그레이드된 주 복제본은 SQL Server 2017SQL Server 2017 인스턴스가 아직 같은 버전으로 업그레이드되지 않은 보조 복제본에 로그를 더 이상 전달할 수 없습니다.An upgraded primary replica can no longer ship logs to any secondary replica whose SQL Server 2017SQL Server 2017 instance that has not yet been upgraded to the same version. 보조 복제본으로 데이터 이동이 일시 중지된 경우 해당 복제본에 대한 자동 장애 조치(failover)를 수행할 수 없고 가용성 데이터베이스의 데이터가 손실될 수 있습니다.When data movement to a secondary replica is suspended, no automatic failover can occur for that replica, and your availability databases are vulnerable to data loss.

  • 가용성 그룹을 장애 조치(failover)하기 전에 장애 조치(failover) 대상의 동기화 상태가 SYNCHRONIZED인지 확인하십시오.Before failing over an availability group, verify that the synchronization state of the failover target is SYNCHRONIZED.

롤링 업그레이드 프로세스Rolling Upgrade Process

실제로 정확한 프로세스는 가용성 그룹의 배포 토폴로지 및 각 복제본의 커밋 모드와 같은 요소에 따라 달라집니다.In practice, the exact process will depend on factors such as the deployment topology of your availability groups and the commit mode of each replica. 가장 간단한 시나리오는 다음 단계가 포함된 가장 간단한 형식의 다단계 프로세스로 롤링 업그레이드를 수행하는 것입니다.But in the simplest scenario, a rolling upgrade is a multi-stage process that in its simplest form involves the following steps:

HADR 시나리오의 가용성 그룹 업그레이드Availability Group Upgrade in HADR Scenario

  1. 모든 동기-커밋 복제본에서 자동 장애 조치(failover)를 제거합니다.Remove automatic failover on all synchronous-commit replicas

  2. 비동기-커밋 보조 복제본을 실행하는 모든 원격 보조 복제본 인스턴스를 업그레이드합니다.Upgrade all remote secondary replica instances running asynchronous-commit secondary replicas

  3. 현재 주 복제본을 실행하지 않는 모든 로컬 보조 복제본 인스턴스를 업그레이드합니다.Upgrade the all local replica secondary instances that are not currently running the primary replica

  4. 수동으로 가용성 그룹을 로컬 동기-커밋 보조 복제본으로 장애 조치(failover)합니다.Manually fail over the availability group to a local synchronous-commit secondary replica

  5. 이전에 주 복제본을 호스팅한 로컬 복제본 인스턴스를 업그레이드 또는 업데이트합니다.Upgrade or update the local replica instance that formerly hosted the primary replica

  6. 자동 장애 조치(Failover) 파트너를 원하는 대로 구성합니다.Configure automatic failover partners as desired

    필요한 경우 추가 수동 장애 조치(failover)를 수행하여 가용성 그룹을 원래 구성으로 되돌릴 수 있습니다.If necessary, you can perform an extra manual failover to return the availability group to its original configuration.

원격 보조 복제본 하나가 포함된 가용성 그룹Availability Group with One Remote Secondary Replica

재해 복구용으로만 가용성 그룹을 배포한 경우 가용성 그룹을 비동기-커밋 보조 복제본으로 장애 조치(failover)해야 할 수 있습니다.If you have deployed an availability group only for disaster recovery, you may need to fail over the availability group to an asynchronous-commit secondary replica. 다음 그림에서는 이 구성을 보여 줍니다.Such configuration is illustrated by the following figure:

DR 시나리오의 가용성 그룹 업그레이드Availability Group Upgrade in DR Scenario

이 경우 롤링 업그레이드 동안 가용성 그룹을 비동기-커밋 보조 복제본으로 장애 조치(failover)해야 합니다.In this situation, you must fail over the availability group to the asynchronous-commit secondary replica during the rolling upgrade. 데이터 손실을 방지하려면 가용성 그룹을 장애 조치(failover)하기 전에 커밋 모드를 동기 커밋으로 변경하고 보조 복제본이 동기화될 때까지 기다리십시오.To prevent data loss, change the commit mode to synchronous commit and wait for the secondary replica to be synchronized before you fail over the availability group. 즉, 롤링 업그레이드 프로세스는 다음과 같습니다.Therefore, the rolling upgrade process may look as follows:

  1. 원격 사이트에서 보조 복제본 인스턴스 업그레이드Upgrade the secondary replica instance on the remote site

  2. 커밋 모드를 동기 커밋으로 변경Change the commit mode to synchronous commit

  3. 동기화 상태가 SYNCHRONIZED가 될 때까지 대기Wait until synchronization state is SYNCHRONIZED

  4. 가용성 그룹을 원격 사이트의 보조 복제본으로 장애 조치(failover)Fail over the availability group to the secondary replica on the remote site

  5. 로컬 (주 사이트) 복제본 인스턴스 업그레이드 또는 업데이트Upgrade or update the local (primary site) replica instance

  6. 가용성 그룹을 주 사이트로 다시 장애 조치(failover)Fail over the availability group back to the primary site

  7. 커밋 모드를 비동기 커밋으로 변경Change the commit mode to asynchronous commit

    동기-커밋 모드는 원격 사이트로 데이터 동기화에 권장되는 설정이 아니므로 설정 변경 후 클라이언트 응용 프로그램에서 데이터베이스 대기 시간이 증가됨을 즉각적으로 알릴 수 있습니다.Since the synchronous-commit mode is not a recommended setting for data synchronization to a remote site, client applications may notice an immediate increase in database latency after the setting change. 또한 장애 조치(failover)를 수행하면 승인되지 않은 모든 로그 메시지가 삭제됩니다.Moreover, performing a failover will cause all unacknowledged log messages to be discarded. 두 사이트 간 긴 네트워크 지연 시간으로 인해 삭제된 로그 메시지의 양이 상당히 커질 수 있고 이에 따라 방대한 양의 트랜잭션이 실패할 수 있습니다.The amount of discarded log messages can be quite large due to the high network latency between the two sites, causing clients to experience a high volume of transactional failure. 다음을 수행하여 클라이언트 응용 프로그램에 대한 영향을 최소화할 수 있습니다.You can minimize impact to client applications by doing the following:

  • 클라이언트 트래픽이 낮을 때 유지 관리 기간을 신중하게 선택합니다.Carefully select a maintenance window during low client traffic

  • 주 사이트에서 SQL Server 2017SQL Server 2017 을(를) 업그레이드 또는 업데이트하는 동안 가용성 모드를 비동기 커밋으로 변경한 다음 주 사이트에 대한 장애 조치(failover)를 수행할 준비가 되면 동기 커밋으로 되돌립니다.While upgrading or updating SQL Server 2017SQL Server 2017 on the primary site, change the availability mode back to asynchronous commit, then revert to synchronous commit when you are ready to fail over to the primary site again

장애 조치(Failover) 클러스터 인스턴스 노드가 포함된 가용성 그룹Availability Group with Failover Cluster Instance Nodes

가용성 그룹에 FCI(장애 조치(failover) 클러스터 인스턴스) 노드가 포함된 경우 활성 노드를 업그레이드하기 전에 비활성 노드를 업그레이드해야 합니다.If an availability group contains failover cluster instance (FCI) nodes, you should upgrade the inactive nodes before you upgrade the active nodes. 아래 그림에서는 로컬 고가용성을 위한 FCI 및 원격 재해 복구용 FCI 간 비동기 커밋과 함께 일반적인 가용성 그룹 시나리오와 업그레이드 시퀀스를 설명합니다.The figure below illustrates a common availability group scenario with FCIs for local high availability and asynchronous commit between the FCIs for remote disaster recovery, and the upgrade sequence.

FCI를 통한 가용성 그룹 업그레이드Availability Group Upgrade with FCIs

  1. REMOTE2 업그레이드 또는 업데이트Upgrade or update REMOTE2

  2. FCI2를 REMOTE2로 장애 조치(Failover)Fail over FCI2 to REMOTE2

  3. REMOTE1 업그레이드 또는 업데이트Upgrade or update REMOTE1

  4. PRIMARY2 업그레이드 또는 업데이트Upgrade or update PRIMARY2

  5. FCI1을 PRIMARY2로 장애 조치(Failover)Fail over FCI1 to PRIMARY2

  6. PRIMARY1 업그레이드 또는 업데이트Upgrade or update PRIMARY1

여러 가용성 그룹이 있는 SQL Server 인스턴스 업그레이드/업데이트Upgrade Update SQL Server Instances with Multiple Availability Groups

별도의 서버 노드(활성/비활성 구성)에서 주 복제본이 있는 여러 가용성 그룹을 실행 중인 경우 프로세스 중에 고가용성을 유지하기 위해 업그레이드 경로에 더 많은 장애 조치(failover) 단계가 포함됩니다.If you are running multiple availability groups with primary replicas on separate server nodes (an Active/Active configuration), the upgrade path involves more failover steps to preserve high availability in the process. 다음 표와 같이 3개의 서버 노드에서 3개의 가용성 그룹을 실행하고 모든 보조 복제본이 동기-커밋 모드에서 실행 중이라고 가정합니다.Suppose you are running three availability groups on three server nodes as shown in the following table, and all secondary replicas are running in synchronous-commit mode.

가용성 그룹Availability Group Node1Node1 Node2Node2 Node3Node3
AG1AG1 Primary
AG2AG2 Primary
AG3AG3 Primary

다음 시퀀스에서 부하 분산 롤링 업그레이드를 실행하기 위한 상황에 적합할 수 있습니다.It may be appropriate in your situation to perform a load-balanced rolling upgrade in the following sequence:

  1. AG2를 Node3으로 장애 조치(Failover)(Node2를 확보하기 위함)Fail over AG2 to Node3 (to free up Node2)

  2. Node2 업그레이드 또는 업데이트Upgrade or update Node2

  3. AG1을 Node2로 장애 조치(Failover)(Node1을 확보하기 위함)Fail over AG1 to Node2 (to free up Node1)

  4. Node1 업그레이드 또는 업데이트Upgrade or update Node1

  5. AG2 및 AG3을 Node1로 장애 조치(Failover)(Node3을 확보하기 위함)Fail over both AG2 and AG3 to Node1 (to free up Node3)

  6. Node3 업그레이드 또는 업데이트Upgrade or update Node3

  7. AG3을 Node3으로 장애 조치(Failover)Fail over AG3 to Node3

    이 업그레이드 시퀀스에는 가용성 그룹당 2번의 장애 조치(Failover)보다 적은 평균적인 작동 중단 시간이 발생합니다.This upgrade sequence has an average downtime of less than two failovers per availability group. 결과적인 구성이 아래 표에 표시됩니다.The resulting configuration is shown in the table below.

가용성 그룹Availability Group Node1Node1 Node2Node2 Node3Node3
AG1AG1 Primary
AG2AG2 Primary
AG3AG3 Primary

특정 구현에 따라 업그레이드 경로가 달라질 수 있으며 클라이언트 응용 프로그램에 발생하는 작동 중지 시간도 달라질 수 있습니다.Based on your specific implementation, your upgrade path may vary, and the downtime that client applications experience may vary as well.

참고

대부분의 경우에서 롤링 업그레이드가 완료된 후 원래 주 복제본에 대한 장애 복구가 수행됩니다.In many cases, after the rolling upgrade is completed, you will failback to the original primary replica.

참고 항목See Also

설치 마법사를 사용하여 SQL Server 2016으로 업그레이드(설치) Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)
명령 프롬프트에서 SQL Server 2016 설치Install SQL Server 2016 from the Command Prompt