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

이 항목 적용 대상: 예SQL Server없습니다Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스 없습니다 병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Always On AG(가용성 그룹)를 호스트하는 SQL ServerSQL Server 인스턴스를 신규 SQL Server 2017SQL Server 2017 버전, 신규 SQL ServerSQL Server 서비스 팩 또는 누적 업데이트로 업그레이드하거나 신규 Windows 서비스 팩 또는 누적 업데이트를 설치하려는 경우 롤링 업그레이드를 수행하여 주 복제본을 단일 수동 장애 조치(failover)에만 적용하여 가동 중지 시간을 단축할 수 있습니다(또는 원본 주 복제본이 실패하는 경우 두 개의 수동 장애 조치(failover)).When upgrading a SQL ServerSQL Server instance that hosts an Always On Availability Group (AG) to a new SQL Server 2017SQL Server 2017 version, to a new SQL ServerSQL Server service 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를 실행하는 보조 복제본에 대한 초기 장애 조치(failover) 이후에, 가용성 그룹의 데이터베이스는 업그레이드 프로세스를 거쳐 최신 버전으로 업데이트됩니다.Also be aware that after the initial failover to a secondary replica running a newer version of SQL Server, the databases in that Availability Group will run through an upgrade process to bring them to the latest version. 이 기간 동안 이러한 데이터베이스에 대해 읽기가 가능한 복제본은 없습니다.During this time there will be no readable replicas for any of these databases. 초기 장애 조치(failover) 후 가동 중지 시간은 가용성 그룹의 데이터베이스 수에 따라 달라집니다.Downtime after the initial failover will depend on the number of databases in the Availability Group. 원래 주 데이터베이스로 장애 복구(failback)를 계획하는 경우, 이 단계는 장애 복구 시 반복되지 않습니다.If you plan on failing back to the original primary, this step will not be repeated when you fail back.

참고

이 문서는 SQL Server 업그레이드에 대한 설명으로 제한됩니다.This article limits the discussion to the upgrade of SQL Server itself. WSFC(Windows Server Failover Cluster) 클러스터를 포함하는 운영 체제 업그레이드를 다루지 않습니다.It does not cover upgrading the operating system containing the Windows Server Failover Cluster (WSFC). 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:

참고

준비가 된 복제본을 업그레이드하는 롤링 업그레이드 외부에서는 동일한 AG의 SQL Server 인스턴스 혼합 버전이 지원되지 않습니다.Mixing versions of SQL Server instances in the same AG is not supported outside of a rolling upgrade, which upgrades the replicas in place. 더 높은 버전의 SQL Server 인스턴스를 기존 AG에 새 복제본으로 추가할 수 없습니다.A higher version of a SQL Server instance cannot be added as a new replica to an existing AG. 예를 들어 SQL Server 2017 복제본은 기존 SQL Server 2016 AG에 추가할 수 없습니다.For example, a SQL Server 2017 replica cannot be added to an existing SQL Server 2016 AG. AG를 사용하여 SQL Server 인스턴스의 새 버전으로 마이그레이션하기 위해 지원되는 유일한 방법은 SQL Server 2016 Enterprise Edition 이상에 포함된 분산 AG입니다.To migrate to a new version of the SQL Server instance using AGs, the only supported method is a distributed AG, which is in SQL Server 2016 Enterprise Edition or later.

Always On AG의 롤링 업그레이드 기본 사항Rolling Upgrade Basics for Always On AGs

서버 업그레이드 또는 업데이트를 수행할 때 AG의 가동 중단 시간 및 데이터 손실을 최소화하려면 다음과 같은 지침을 따르세요.Observe the following guidelines when performing server upgrades or updates in order to minimize downtime and data loss for your AGs:

  • 롤링 업그레이드를 시작하기 전에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 are 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.

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

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

  • 항상 AG를 동기-커밋 보조 복제본 인스턴스로 장애 조치(failover)합니다.Always fail over the AG to a synchronous-commit secondary replica instance. 비동기-커밋 보조 복제본 인스턴스로 장애 조치(failover)하는 경우 데이터베이스가 데이터 손실에 취약해지고, 데이터 이동을 수동으로 다시 시작할 때까지 데이터 이동이 자동으로 중지됩니다.If you fail over to an asynchronous-commit secondary replica instance, the databases is vulnerable to 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.

  • AG를 장애 조치(failover)하기 전에 장애 조치(failover) 대상의 동기화 상태가 SYNCHRONIZED인지 확인하세요.Before failing over an AG, verify that the synchronization state of the failover target is SYNCHRONIZED.

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

실제로 정확한 프로세스는 AG의 배포 토폴로지 및 각 복제본의 커밋 모드와 같은 요소에 따라 달라집니다.In practice, the exact process depends on factors such as the deployment topology of your AGs 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 시나리오에서 AG 업그레이드AG 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. 수동으로 AG를 로컬 동기-커밋 보조 복제본으로 장애 조치(failover)합니다.Manually fail over the AG 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)를 수행하여 AG를 원래 구성으로 되돌릴 수 있습니다.If necessary, you can perform an extra manual failover to return the AG to its original configuration.

원격 보조 복제본 하나가 포함된 AGAG with One Remote Secondary Replica

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

DR 시나리오에서 AG 업그레이드AG Upgrade in DR Scenario

이 경우 롤링 업그레이드 동안 AG를 비동기-커밋 보조 복제본으로 장애 조치(failover)해야 합니다.In this situation, you must fail over the AG to the asynchronous-commit secondary replica during the rolling upgrade. 데이터 손실을 방지하려면 AG를 장애 조치(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 AG. 즉, 롤링 업그레이드 프로세스는 다음과 같습니다.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. AG를 원격 사이트의 보조 복제본으로 장애 조치(failover)Fail over the AG to the secondary replica on the remote site

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

  6. AG를 주 사이트로 다시 장애 조치(failover)Fail over the AG 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 causes all unacknowledged log messages to be discarded. 두 사이트 간 긴 네트워크 지연 시간으로 인해 삭제된 로그 메시지 수가 상당히 많아질 수 있고 이에 따라 방대한 양의 트랜잭션이 실패할 수 있습니다.The number discarded log messages can be significant 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 actions:

  • 클라이언트 트래픽이 낮을 때 유지 관리 기간을 신중하게 선택합니다.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) 클러스터 인스턴스 노드가 포함된 AGAG with Failover Cluster Instance Nodes

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

FCI로 AG 업그레이드AG 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

여러 AG가 있는 SQL Server 인스턴스 업그레이드/업데이트Upgrade Update SQL Server Instances with Multiple AGs

별도의 서버 노드(활성/비활성 구성)에서 주 복제본이 있는 여러 AG를 실행 중인 경우 프로세스 중에 고가용성을 유지하기 위해 업그레이드 경로에 더 많은 장애 조치(failover) 단계가 포함됩니다.If you are running multiple AGs 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개의 AG를 실행하고 모든 복제본이 동기 커밋 모드에서 실행 중이라고 가정합니다.Suppose you are running three AGs on three server nodes with all replicas in synchronous commit mode as shown in the following table:

AGAG 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

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

AGAG 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 fail back to the original primary replica.

변경 데이터 캡처 또는 복제를 위한 특별한 단계Special steps for change data capture or replication

적용하는 업데이트에 따라 변경 데이터 캡처 또는 복제가 활성화된 AG 복제본 데이터베이스에 추가 단계가 필요할 수 있습니다.Depending on the update being applied, additional steps may be required for AG replica databases that are enabled for change data capture or replication. 업데이트에 대한 릴리스 정보를 참조하여 다음 단계가 필요한지 확인하세요.Refer to the release notes for the update to determine if the following steps are required:

  1. 각 보조 복제본을 업그레이드합니다.Upgrade each secondary replica.

  2. 모든 보조 복제본이 업그레이드된 후 AG를 업그레이드된 인스턴스로 장애 조치(failover)합니다.After all secondary replicas have been upgraded, fail over the AG to an upgraded instance.

  3. 주 복제본을 호스트하는 인스턴스에서 다음 Transact-SQL을 실행합니다.Run the following Transact-SQL on the instance that hosts the primary replica:

    EXECUTE [master].[sys].[sp_vupgrade_replication];
    

    참고

    이 명령을 실행하는 데 몇 분 정도 걸릴 수 있습니다.This command may take several minutes to run.

  4. 원래 주 복제본이었던 인스턴스를 업그레이드합니다.Upgrade the instance that was originally the primary replica.

자세한 내용은 최신 CU로 업그레이드한 후 CDC 기능이 중단될 수 있음을 참조하세요.For background information, see CDC functionality may break after upgrading to the latest CU.

참고 항목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