Always On 가용성 그룹 개요(SQL Server)Overview of Always On Availability Groups (SQL Server)

이 항목은 다음에 적용됩니다. 예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 Server와 관련된 내용은 AlwaysOn 가용성 그룹 개요(SQL Server) 를 참조하세요.For content related to previous versions of SQL Server, see Overview of AlwaysOn Availability Groups (SQL Server).

이 항목에서는 Always On 가용성 그룹Always On availability groups 에서 하나 이상의 가용성 그룹을 구성하고 관리하는 데 중심이 되는 SQL Server 2017SQL Server 2017개념을 소개합니다.This topic introduces the Always On 가용성 그룹Always On availability groups concepts that are central for configuring and managing one or more availability groups in SQL Server 2017SQL Server 2017. 가용성 그룹에서 제공하는 이점의 요약과 Always On 가용성 그룹Always On availability groups 용어의 개요는 Always On 가용성 그룹(SQL Server)을 참조하세요.For a summary of the benefits offered by availability groups and an overview of Always On 가용성 그룹Always On availability groups terminology, see Always On Availability Groups (SQL Server).

가용성 그룹가용성 데이터베이스라고 하는 개별 사용자 데이터베이스의 불연속 집합에 대해 복제된 환경을 지원합니다.An availability group supports a replicated environment for a discrete set of user databases, known as availability databases. HA(고가용성) 또는 읽기-배율에 대한 가용성 그룹을 만들 수 있습니다.You can create an availability group for high availability (HA) or for read-scale. HA 가용성 그룹은 함께 장애 조치를 수행하는 데이터베이스 그룹입니다.An HA availability group is a group of databases that fail over together. 읽기-배율 가용성 그룹은 읽기 전용 작업을 위해 다른 SQL Server 인스턴스에 복사되는 데이터베이스 그룹입니다.A read-scale availability group is a group of databases that are copied to other instances of SQL Server for read-only workload. 가용성 그룹은 하나의 주 데이터베이스 집합과 1~8개의 해당 보조 데이터베이스 집합을 지원합니다.An availability group supports one set of primary databases and one to eight sets of corresponding secondary databases. 보조 데이터베이스는 백업이 아닙니다 .Secondary databases are not backups. 계속하여 정기적으로 데이터베이스 및 해당 트랜잭션 로그를 백업하세요.Continue to back up your databases and their transaction logs on a regular basis.

모든 유형의 주 데이터베이스 백업을 만들 수 있습니다.You can create any type of backup of a primary database. 또는 로그 백업과 보조 데이터베이스의 복사 전용 전체 백업을 만들 수 있습니다.Alternatively, you can create log backups and copy-only full backups of secondary databases. 자세한 내용은 활성 보조: 보조 복제본에 백업(Always On 가용성 그룹)개념을 소개합니다.For more information, see Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups).

각 가용성 데이터베이스 집합은 가용성 복제본에 의해 호스팅됩니다.Each set of availability database is hosted by an availability replica. 가용성 복제본에는 주 복제본Two types of availability replicas exist: a single primary replica. 보조 복제본의 두 가지 유형이 있습니다. 주 복제본은 하나이고 주 데이터베이스를 호스팅하며, 보조 복제본은 1~8개로 각각 보조 데이터베이스 집합을 호스팅하고 가용성 그룹에 대한 잠재적인 장애 조치(Failover) 대상 역할을 합니다.which hosts the primary databases, and one to eight secondary replicas, each of which hosts a set of secondary databases and serves as a potential failover targets for the availability group. 가용성 그룹은 가용성 복제본의 수준에서 장애 조치(Failover)됩니다.An availability group fails over at the level of an availability replica. 가용성 복제본은 가용성 그룹에 속한 데이터베이스 집합에 대해 데이터베이스 수준에서만 중복을 제공합니다.An availability replica provides redundancy only at the database level—for the set of databases in one availability group. 따라서 데이터 파일 손실, 트랜잭션 로그 손상 등으로 인해 주의 대상 데이터베이스가 발생할 경우 이러한 데이터베이스 문제로는 장애 조치(Failover)가 수행되지 않습니다.Failovers are not caused by database issues such as a database becoming suspect due to a loss of a data file or corruption of a transaction log.

주 복제본은 주 데이터베이스를 클라이언트에서 읽기/쓰기 연결에 사용할 수 있게 만듭니다.The primary replica makes the primary databases available for read-write connections from clients. 주 복제본은 각 주 데이터베이스의 트랜잭션 로그 레코드를 모든 보조 복제본에 보냅니다.The primary replica sends transaction log records of each primary database to every secondary database. 또한 데이터 동기화라고 하는 이 프로세스는 데이터베이스 수준에서 발생합니다.This process - known as data synchronization - occurs at the database level. 모든 보조 복제본은 트랜잭션 로그 레코드를 캐시, 즉 로그를확정 한 다음 해당하는 보조 데이터베이스에 적용합니다.Every secondary replica caches the transaction log records (hardens the log) and then applies them to its corresponding secondary database. 데이터 동기화는 주 데이터베이스 및 연결된 각 보조 데이터베이스 간에 다른 데이터베이스와 독립적으로 발생합니다.Data synchronization occurs between the primary database and each connected secondary database, independently of the other databases. 따라서 보조 데이터베이스가 중지되거나 실패할 때 다른 보조 데이터베이스에 영향을 주지 않을 수 있으며, 주 데이터베이스는 중지되거나 실패할 때 다른 주 데이터베이스에 영향을 주지 않을 수 있습니다.Therefore, a secondary database can be suspended or fail without affecting other secondary databases, and a primary database can be suspended or fail without affecting other primary databases.

필요한 경우 보조 데이터베이스에 대한 읽기 전용 액세스를 지원하기 위해 하나 이상의 보조 복제본을 구성할 수 있으며, 보조 데이터베이스에서 백업을 허용하도록 보조 복제본을 구성할 수 있습니다.Optionally, you can configure one or more secondary replicas to support read-only access to secondary databases, and you can configure any secondary replica to permit backups on secondary databases.

SQL Server 2017은 가용성 그룹에 대해 서로 다른 두 가지 아키텍처를 도입하고 있습니다.SQL Server 2017 introduces two different architectures for availability groups. Always On 가용성 그룹은 고가용성, 재해 복구 및 읽기-배율 분산을 제공합니다.Always On availability groups provide high availability, disaster recovery, and read-scale balancing. 이러한 가용성 그룹에는 클러스터 관리자가 필요합니다.These availability groups require a cluster manager. Windows에서는 장애 조치 클러스터링에서 클러스터 관리자를 제공하며,In Windows, failover clustering provides the cluster manager. Linux에서는 Pacemaker를 사용할 수 있습니다.In Linux, you can use Pacemaker. 다른 아키텍처는 읽기-배율 가용성 그룹입니다.The other architecture is a read-scale availability group. 읽기-배율 가용성 그룹은 읽기 전용 작업에 대한 복제본을 제공하지만, 고가용성은 제공하지 않습니다.A read scale availability group provides replicas for read-only workloads but not high availability. 읽기-배율 가용성 그룹에는 클러스터 관리자가 없습니다.In a read-scale availability group there is no cluster manager.

Windows에서 HA용 Always On 가용성 그룹Always On availability groups을 배포하려면 WSFC(Windows Server 장애 조치 클러스터)가 필요합니다.Deploying Always On 가용성 그룹Always On availability groups for HA on Windows requires a Windows Server Failover Cluster(WSFC). 지정된 가용성 그룹의 가용성 복제본 각각은 동일한 WSFC 클러스터의 서로 다른 노드에 있어야 합니다.Each availability replica of a given availability group must reside on a different node of the same WSFC. 유일한 예외는 다른 WSFC 클러스터로 마이그레이션되는 동안 가용성 그룹이 일시적으로 두 클러스터에 걸쳐 있는 경우입니다.The only exception is that while being migrated to another WSFC cluster, an availability group can temporarily straddle two clusters.

참고

Linux의 가용성 그룹에 대한 자세한 내용은 Linux에서 SQL Server에 대한 Always On 가용성 그룹을 참조하세요.For information about availability groups on Linux, see Always On availability group for SQL Server on Linux .

HA 구성에서 만드는 모든 가용성 그룹에 대해 클러스터 역할이 만들어집니다.In an HA configuration, a cluster role is created for every availability group that you create. WSFC 클러스터에서는 이 역할을 모니터링하여 주 복제본의 상태를 평가합니다.The WSFC cluster monitors this role to evaluate the health of the primary replica. Always On 가용성 그룹Always On availability groups 에 대한 쿼럼은 지정된 클러스터 노드가 가용성 복제본을 호스팅하는지 여부에 관계없이 WSFC 클러스터의 모든 노드를 기반합니다.The quorum for Always On 가용성 그룹Always On availability groups is based on all nodes in the WSFC cluster regardless of whether a given cluster node hosts any availability replicas. 데이터베이스 미러링과 달리 Always On 가용성 그룹Always On availability groups에는 모니터 역할이 없습니다.In contrast to database mirroring, there is no witness role in Always On 가용성 그룹Always On availability groups.

참고

WSFC 클러스터와 SQLServer AlwaysOn 구성 요소의 관계에 대한 자세한 내용은 SQL Server의 WSFC(Windows Server 장애 조치(Failover) 클러스터링)를 참조하세요.For information about the relationship of SQL Server Always On components to the WSFC cluster, see Windows Server Failover Clustering (WSFC) with SQL Server.

다음 그림에서는 하나의 주 복제본과 네 개의 보조 복제본이 포함된 가용성 그룹을 보여 줍니다.The following illustration shows an availability group that contains one primary replica and four secondary replicas. 하나의 주 복제본과 두 개의 동기 커밋 보조 복제본을 포함하여 최대 8개의 보조 복제본이 지원됩니다.Up to eight secondary replicas are supported, including one primary replica and two synchronous-commit secondary replicas.

5개 복제본이 있는 가용성 그룹Availabilty group with five replicas

Availability Databases Availability Databases

데이터베이스를 가용성 그룹에 추가하려면 데이터베이스는 주 복제본을 호스팅하는 서버 인스턴스에 있는 온라인 읽기-쓰기 데이터베이스여야 합니다.To add a database to an availability group, the database must be an online, read-write database that exists on the server instance that hosts the primary replica. 데이터베이스를 추가하면 이 데이터베이스는 가용성 그룹을 주 데이터베이스로 조인하며 클라이언트에서 사용할 수 있는 상태로 유지됩니다.When you add a database, it joins the availability group as a primary database, while remaining available to clients. 새로운 주 데이터베이스의 백업이 보조 복제본을 호스팅하는 서버 인스턴스로 복원될 때까지 해당 보조 데이터베이스는 존재하지 않습니다(RESTORE WITH NORECOVERY 사용).No corresponding secondary database exists until backups of the new primary database are restored to the server instance that hosts the secondary replica (using RESTORE WITH NORECOVERY). 새 보조 데이터베이스는 가용성 그룹에 조인될 때까지 RESTORING 상태에 있습니다.The new secondary database is in the RESTORING state until it is joined to the availability group. 자세한 내용은 Always On 보조 데이터베이스에서 데이터 이동 시작(SQL Server)을 참조하세요.For more information, see Start Data Movement on an Always On Secondary Database (SQL Server).

조인하면 보조 데이터베이스가 ONLINE 상태로 전환되고 해당 주 데이터베이스와의 데이터 동기화가 시작됩니다.Joining places the secondary database into the ONLINE state and initiates data synchronization with the corresponding primary database. 데이터 동기화 는 주 데이터베이스에 대한 변경 사항이 보조 데이터베이스에서 재현되는 프로세스입니다.Data synchronization is the process by which changes to a primary database are reproduced on a secondary database. 데이터 동기화를 수행하면 주 데이터베이스가 트랜잭션 로그 레코드를 보조 데이터베이스에 전송합니다.Data synchronization involves the primary database sending transaction log records to the secondary database.

중요

가용성 데이터베이스는 에서 데이터베이스 복제본 Transact-SQLTransact-SQL, PowerShell 및 SMO(SQL Server 관리 개체) 이름이라고도 합니다.An availability database is sometimes called a database replica in Transact-SQLTransact-SQL, PowerShell, and SQL Server Management Objects (SMO) names. 예를 들어 "데이터베이스 복제본"이라는 용어는 가용성 데이터베이스 sys.dm_hadr_database_replica_statessys.dm_hadr_database_replica_cluster_states에 대한 정보를 반환하는 Always On 동적 관리 뷰의 이름에서 사용됩니다.For example, the term "database replica" is used in the names of the Always On dynamic management views that return information about availability databases: sys.dm_hadr_database_replica_states and sys.dm_hadr_database_replica_cluster_states. 그러나 SQL Server 온라인 설명서에서 "복제본"이라는 용어는 일반적으로 가용성 복제본입니다.However, in SQL Server Books Online, the term "replica" typically refers to availability replicas. 예를 들어 "주 복제본"과 "보조 복제본"은 항상 가용성 복제본을 나타냅니다.For example, "primary replica" and "secondary replica" always refer to availability replicas.

가용성 복제본 Availability Replicas

각 가용성 그룹은 가용성 복제본이라는 두 개 이상의 장애 조치(Failover) 파트너 집합을 정의합니다.Each availability group defines a set of two or more failover partners known as availability replicas. 가용성 복제본 은 가용성 그룹의 구성 요소입니다.Availability replicas are components of the availability group. 각 가용성 복제본은 가용성 그룹에 있는 가용성 데이터베이스의 복사본을 호스팅합니다.Each availability replica hosts a copy of the availability databases in the availability group. 가용성 그룹의 각 가용성 복제본은 WSFC 클러스터의 서로 다른 노드에 있는 별도의 SQL ServerSQL Server 인스턴스에서 호스팅해야 합니다.For a given availability group, the availability replicas must be hosted by separate instances of SQL ServerSQL Server residing on different nodes of a WSFC cluster. 각 서버 인스턴스에서 Always On을 사용하도록 설정해야 합니다.Each of these server instances must be enabled for Always On.

한 인스턴스는 가용성 그룹별로 하나의 가용성 복제본만 호스팅할 수 있습니다.A given instance can host only one availability replica per availability group. 하지만 각 인스턴스는 여러 가용성 그룹에 사용될 수 있습니다.However, each instance can be used for many availability groups. 각 인스턴스는 독립 실행형 인스턴스이거나 SQL ServerSQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)일 수 있습니다.A given instance can be either a stand-alone instance or a SQL ServerSQL Server failover cluster instance (FCI). 서버 수준 중복이 필요한 경우에는 장애 조치(Failover) 클러스터 인스턴스를 사용하세요.If you require server-level redundancy, use Failover Cluster Instances.

모든 가용성 복제본에는 초기 역할이 할당됩니다. 초기 역할은 해당 복제본의 가용성 데이터베이스에서 상속하는 주 역할 또는 보조 역할입니다.Every availability replica is assigned an initial role—either the primary role or the secondary role, which is inherited by the availability databases of that replica. 지정된 복제본의 역할에 따라 읽기-쓰기 데이터베이스가 호스팅되는지 아니면 읽기 전용 데이터베이스가 호스팅되는지가 결정됩니다.The role of a given replica determines whether it hosts read-write databases or read-only databases. 주 복제본이라는 하나의 복제본에는 주 역할이 할당되며 이 복제본은 주 데이터베이스라는 읽기-쓰기 데이터베이스를 호스트합니다.One replica, known as the primary replica, is assigned the primary role and hosts read-write databases, which are known as primary databases. 보조 복제본이라는 하나 이상의 다른 복제본에는 보조 역할이 할당됩니다.At least one other replica, known as a secondary replica, is assigned the secondary role. 보조 복제본은 보조 데이터베이스라는 읽기 전용 데이터베이스를 호스팅합니다.A secondary replica hosts read-only databases, known as secondary databases.

참고

장애 조치(Failover) 도중과 같이 가용성 복제본의 역할이 불확실할 때 데이터베이스는 일시적으로 NOT SYNCHRONIZING 상태에 있습니다.When the role of an availability replica is indeterminate, such as during a failover, its databases are temporarily in a NOT SYNCHRONIZING state. 가용성 복제본의 역할이 확인될 때까지 데이터베이스의 역할은 RESOLVING으로 설정됩니다.Their role is set to RESOLVING until the role of the availability replica has resolved. 가용성 복제본이 주 역할로 확인되면 해당 데이터베이스는 주 데이터베이스가 됩니다.If an availability replica resolves to the primary role, its databases become the primary databases. 가용성 복제본이 보조 역할로 확인되면 해당 데이터베이스는 보조 데이터베이스가 됩니다.If an availability replica resolves to the secondary role, its databases become secondary databases.

가용성 모드 Availability Modes

가용성 모드는 각 가용성 복제본의 속성입니다.The availability mode is a property of each availability replica. 가용성 모드는 지정된 보조 복제본이 트랜잭션 로그 레코드를 디스크에 쓸 때까지(로그 확정) 주 복제본이 데이터베이스에서 트랜잭션을 커밋하기 위해 기다리는지 여부를 결정합니다.The availability mode determines whether the primary replica waits to commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log). Always On 가용성 그룹Always On availability groups비동기-커밋 모드동기-커밋 모드라는 두 가지 가용성 모드를 지원합니다. supports two availability modes—asynchronous-commit mode and synchronous-commit mode.

  • Asynchronous-commit modeAsynchronous-commit mode

    이 가용성 모드를 사용하는 가용성 복제본을비동기-커밋 복제본이라고 합니다.An availability replica that uses this availability mode is known as anasynchronous-commit replica. 비동기-커밋 모드에서는 주 복제본이 비동기-커밋 보조 복제본이 로그를 확정할 때까지 기다리지 않고 트랜잭션을 커밋합니다.Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgement that an asynchronous-commit secondary replica has hardened the log. 비동기-커밋 모드에서는 보조 데이터베이스의 트랜잭션 대기 시간이 최소화되지만 보조 데이터베이스가 주 데이터베이스보다 뒤쳐질 수 있어 일부 데이터가 손실될 수 있습니다.Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making some data loss possible.

  • Synchronous-commit modeSynchronous-commit mode

    이 가용성 모드를 사용하는 가용성 복제본을 동기-커밋 복제본이라고 합니다.An availability replica that uses this availability mode is known as a synchronous-commit replica. 동기-커밋 모드에서는 동기-커밋 주 복제본이 트랜잭션을 커밋하기 전에 동기-커밋 보조 복제본이 로그 확정을 완료했음을 확인할 때까지 기다립니다.Under synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log. 동기-커밋 모드에서는 지정된 보조 데이터베이스가 주 데이터베이스와 동기화되고 나면 커밋된 트랜잭션이 완전히 보호됩니다.Synchronous-commit mode ensures that once a given secondary database is synchronized with the primary database, committed transactions are fully protected. 이렇게 보호되는 대신에 트랜잭션 대기 시간이 증가합니다.This protection comes at the cost of increased transaction latency.

    자세한 내용은 가용성 모드(Always On 가용성 그룹)개념을 소개합니다.For more information, see Availability Modes (Always On Availability Groups).

장애 조치(Failover) 유형 Types of Failover

주 복제본과 보조 복제본 간의 섹션 컨텍스트 내에서 주 역할과 보조 역할은 장애 조치(Failover)라는 프로세스에서 서로 교환할 수 있습니다.Within the context of a session between the primary replica and a secondary replica, the primary and secondary roles are potentially interchangeable in a process known as failover. 장애 조치(Failover) 중에 대상 보조 복제본은 주 역할로 전환되어 새로운 주 복제본이 됩니다.During a failover the target secondary replica transitions to the primary role, becoming the new primary replica. 새로운 주 복제본은 해당 데이터베이스를 주 데이터베이스로 온라인으로 전환하며 클라이언트 응용 프로그램은 이 데이터베이스에 연결할 수 있습니다.The new primary replica brings its databases online as the primary databases, and client applications can connect to them. 이전의 주 복제본이 사용 가능한 경우 이 복제본은 보조 역할로 전환되어 보조 복제본이 됩니다.When the former primary replica is available, it transitions to the secondary role, becoming a secondary replica. 이전의 주 복제본은 보조 데이터베이스가 되고 데이터 동기화가 다시 시작됩니다.The former primary databases become secondary databases and data synchronization resumes.

자동, 수동 및 강제(데이터가 손실될 수 있음)라는 세 가지 형태의 장애 조치(Failover)가 있습니다.Three forms of failover exist—automatic, manual, and forced (with possible data loss). 지정된 보조 복제본에서 지원되는 장애 조치(Failover)의 형태는 가용성 모드에 따라 다르며 동기-커밋 모드의 경우 다음과 같이 주 복제본 및 대상 보조 복제본의 장애 조치(Failover) 모드에 따라 다릅니다.The form or forms of failover supported by a given secondary replica depends on its availability mode, and, for synchronous-commit mode, on the failover mode on the primary replica and target secondary replica, as follows.

  • 대상 보조 복제본이 avt1과 현재 동기화되어 있는 경우 동기-커밋 모드는계획된 수동 장애 조치(Failover)자동 장애 조치(Failover)라는 두 가지 형태의 장애 조치(Failover)를 지원합니다.Synchronous-commit mode supports two forms of failover—planned manual failover and automatic failover, if the target secondary replica is currently synchronized with the avt1. 이러한 형태의 장애 조치(Failover)에 대한 지원은 장애 조치(Failover) 파트너에서 장애 조치(Failover) 모드 속성 의 설정에 따라 다릅니다.The support for these forms of failover depends on the setting of the failover mode property on the failover partners. 주 복제본 또는 보조 복제본에서 장애 조치(Failover) 모드가 "수동"으로 설정된 경우 해당 보조 복제본에 대해 수동 장애 조치(Failover)만 지원됩니다.If failover mode is set to "manual" on either the primary or secondary replica, only manual failover is supported for that secondary replica. 주 복제본과 보조 복제본에서 모두 장애 조치(Failover) 모드가 "자동"으로 설정된 경우 해당 보조 복제본에서는 자동 및 수동 장애 조치(Failover)가 모두 지원됩니다.If failover mode is set to "automatic" on both the primary and secondary replicas, both automatic and manual failover are supported on that secondary replica.

    • 계획된 수동 장애 조치(Failover) (데이터가 손실되지 않음)Planned manual failover (without data loss)

      수동 장애 조치(Failover)는 데이터베이스 관리자가 장애 조치(Failover) 명령을 실행한 후에 수행되며 결과적으로 동기화된 보조 복제본이 주 역할(데이터 보호 보장)로 전환되고 주 복제본이 보조 역할로 전환됩니다.A manual failover occurs after a database administrator issues a failover command and causes a synchronized secondary replica to transition to the primary role (with guaranteed data protection) and the primary replica to transition to the secondary role. 수동 장애 조치(Failover)를 수행하려면 주 복제본과 대상 보조 복제본이 모두 동기-커밋 모드에서 실행 중이어야 하며 보조 복제본은 항상 동기화되어야 합니다.A manual failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode, and the secondary replica must already be synchronized.

    • 자동 장애 조치(Failover) (데이터가 손실되지 않음)Automatic failover (without data loss)

      자동 장애 조치(Failover)는 동기화된 보조 복제본이 주 역할(데이터 보호 보장)로 전환되는 오류에 대응하여 수행됩니다.An automatic failover occurs in response to a failure that causes a synchronized secondary replica to transition to the primary role (with guaranteed data protection). 이전의 주 복제본을 사용할 수 있게 되면 이 복제본은 보조 역할로 전환됩니다.When the former primary replica becomes available, it transitions to the secondary role. 자동 장애 조치(Failover)를 수행하려면 장애 조치(Failover) 모드가 "자동"으로 설정된 상태로 주 복제본과 대상 보조 복제본이 모두 동기-커밋 모드에서 실행 중이어야 합니다.Automatic failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode with the failover mode set to "Automatic". 또한 보조 복제본이 이미 동기화되고, WSFC 쿼럼이 있으며, 가용성 그룹의 유연한 장애 조치(Failover) 정책에서 지정된 조건과 일치해야 합니다.In addition, the secondary replica must already be synchronized, have WSFC quorum, and meet the conditions specified by the flexible failover policyof the availability group.

      중요

      SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)는 가용성 그룹에 따라 AlwaysOn 자동 장애 조치(Failover)를 지원하지 않으므로 FCI에서 호스팅하는 모든 가용성 복제본은 수동 장애 조치(Failover)에 대해서만 구성될 수 있습니다.SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.

    참고

    동기화된 보조 복제본에 강제 장애 조치(failover) 명령을 실행하면 보조 복제본은 계획된 수동 장애 조치(failover)의 경우와 동일하게 작동하는 것을 참고하세요.Note that if you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a planned manual failover.

  • 비동기-커밋 모드에서 유일한 형태의 장애 조치(failover)는 일반적으로 강제 장애 조치(failover)라고 하는 강제 수동 장애 조치(failover)(데이터가 손실될 수 있음)입니다.Under asynchronous-commit mode, the only form of failover is forced manual failover (with possible data loss), typically called forced failover. 강제 장애 조치(failover)는 수동으로만 시작될 수 있기 때문에 수동 장애 조치(failover)의 한 형태로 간주됩니다.Forced failover is considered a form of manual failover because it can only be initiated manually. 강제 장애 조치(failover)는 재해 복구 옵션입니다.Forced failover is a disaster recovery option. 이것은 대상 보조 복제본이 주 복제본과 동기화되지 않은 경우 가능한 유일한 형태의 장애 조치(failover)입니다.It is the only form of failover that is possible when the target secondary replica is not synchronized with the primary replica.

    자세한 내용은 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)개념을 소개합니다.For more information, see Failover and Failover Modes (Always On Availability Groups).

클라이언트 연결 Client Connections

가용성 그룹 수신기를 만들어 지정된 가용성 그룹의 주 복제본에 대한 클라이언트 연결을 제공할 수 있습니다.You can provide client connectivity to the primary replica of a given availability group by creating an availability group listener. 가용성 그룹 수신기 는 지정된 가용성 그룹에 연결된 리소스 집합을 해당 가용성 복제본에 대한 직접 클라이언트 연결에 제공합니다.An availability group listener provides a set of resources that is attached to a given availability group to direct client connections to the appropriate availability replica.

가용성 그룹 수신기는 VNN(가상 네트워크 이름) 역할을 하는 고유의 DNS 이름, 하나 이상의 VIP(가상 IP 주소) 및 TCP 포트 번호와 연결됩니다.An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN), one or more virtual IP addresses (VIPs), and a TCP port number. 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(failover)(SQL Server)개념을 소개합니다.For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

가용성 그룹에 두 개의 가용성 복제본만 있고 보조 복제본에 대한 읽기 액세스를 허용하도록 구성되지 않은 경우, 클라이언트는 데이터베이스 미러링 연결 문자열을 사용하여 주 복제본에 연결할 수 있습니다.If an availability group possesses only two availability replicas and is not configured to allow read-access to the secondary replica, clients can connect to the primary replica by using a database mirroring connection string. 이 방법은 데이터베이스 미러링에서 Always On 가용성 그룹Always On availability groups로 데이터베이스를 마이그레이션한 후 일시적으로 유용할 수 있습니다.This approach can be useful temporarily after you migrate a database from database mirroring to Always On 가용성 그룹Always On availability groups. 보조 복제본을 더 추가하기 전에 가용성 그룹의 가용성 그룹 수신기를 만들고 수신기의 네트워크 이름을 사용하도록 응용 프로그램을 업데이트해야 합니다.Before you add additional secondary replicas, you will need to create an availability group listener the availability group and update your applications to use the network name of the listener.

활성 보조 복제본 Active Secondary Replicas

Always On 가용성 그룹Always On availability groups 은 활성 보조 복제본을 지원합니다. supports active secondary replicas. 활성 보조 기능에는 다음에 대한 지원이 포함됩니다.Active secondary capabilities include support for:

  • 보조 복제본에 대한 백업 작업 수행Performing backup operations on secondary replicas

    보조 복제본은 전체 데이터베이스, 파일 또는 파일 그룹의 복사 전용 백업 및 로그 백업 수행을 지원합니다.The secondary replicas support performing log backups and copy-only backups of a full database, file, or filegroup. 가용성 그룹을 구성하여 백업을 수행해야 하는 위치에 대한 기본 설정을 지정할 수 있습니다.You can configure the availability group to specify a preference for where backups should be performed. 기본 설정은 SQL Server에서 적용하는 것이 아니므로 임시 백업에 영향을 미치지 않는다는 것을 이해해야 합니다.It is important to understand that the preference is not enforced by SQL Server, so it has no impact on ad-hoc backups. 이 기본 설정의 해석은 지정된 가용성 그룹의 각 데이터베이스에 대한 백업 작업으로 스크립팅하는 논리(있는 경우)에 따라 달라집니다.The interpretation of this preference depends on the logic, if any, that you script into your back jobs for each of the databases in a given availability group. 개별 가용성 복제본에 대해 동일한 가용성 그룹의 다른 복제본과 관련하여 이 복제본에서 백업을 수행하기 위한 우선 순위를 지정할 수 있습니다.For an individual availability replica, you can specify your priority for performing backups on this replica relative to the other replicas in the same availability group. 자세한 내용은 활성 보조: 보조 복제본에 백업(Always On 가용성 그룹)개념을 소개합니다.For more information, see Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups).

  • 하나 이상의 보조 복제본(읽기 가능한 보조 복제본)에 대한 읽기 전용 액세스(읽기 가능한 보조 복제본)Read-only access to one or more secondary replicas (readable secondary replicas)

    가용성 복제본이 보조 역할을 수행할 경우 로컬 데이터베이스에 대한 읽기 전용 액세스를 허용하도록 구성할 수 있습니다. 그러나 일부 작업은 부분적으로만 지원됩니다.Any availability replica can be configured to allow read-only access to its local databases when performing the secondary role, though some operations are not fully supported. 또한 주 복제본에서 읽기 전용 작업이 실행되지 않도록 하려는 경우에는 주 역할로 실행될 때 읽기/쓰기 액세스만 허용하도록 복제본을 구성할 수 있습니다.Also, if you would like to prevent read-only workloads from running on the primary replica, you can configure the replicas to allow only read-write access when running under the primary role. 자세한 내용은 활성 보조: 읽기 가능한 보조 복제본(Always On 가용성 그룹)개념을 소개합니다.For more information, see Active Secondaries: Readable Secondary Replicas (Always On Availability Groups).

    가용성 그룹에 현재 가용성 그룹 수신기와 하나 이상의 읽기 가능한 보조 복제본이 있는 경우 SQL ServerSQL Server 에서는 읽기 전용 연결 요청을 이러한 보조 복제본 중 하나로 라우팅할 수 있습니다(읽기 전용 라우팅).If an availability group currently possesses an availability group listener and one or more readable secondary replicas, SQL ServerSQL Server can route read-intent connection requests to one of them (read-only routing). 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(failover)(SQL Server)개념을 소개합니다.For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

세션 제한 시간 Session-Timeout Period

세션 제한 시간은 다른 가용성 복제본과의 연결이 얼마 동안 비활성으로 유지되면 연결이 종료되는지를 결정하는 가용성 복제본 속성입니다.The session-timeout period is an availability-replica property that determines how long connection with another availability replica can remain inactive before the connection is closed. 주 복제본과 보조 복제본은 활성 상태임을 알리기 위해 서로 ping합니다.The primary and secondary replicas ping each other to signal that they are still active. 제한 시간 내에 다른 복제본으로부터 ping을 받으면 연결이 아직 열려 있고 서버 인스턴스가 통신하고 있음을 나타냅니다.Receiving a ping from the other replica during the timeout period indicates that the connection is still open and that the server instances are communicating. ping을 받으면 가용성 복제본은 해당 연결에서의 세션 제한 시간 카운터를 다시 설정합니다.On receiving a ping, an availability replica resets its session-timeout counter on that connection.

세션 제한 시간은 각 복제본이 다른 복제본으로부터 ping을 받기 위해 무기한 대기하는 것을 방지합니다.The session-timeout period prevents either replica from waiting indefinitely to receive a ping from the other replica. 세션 제한 시간 내 다른 복제본으로부터 ping을 받지 못하면 이 복제본은 시간 초과됩니다.If no ping is received from the other replica within the session-timeout period, the replica times out. 그러면 연결이 닫히고 시간 초과된 복제본은 DISCONNECTED 상태로 됩니다.Its connection is closed, and the timed-out replica enters the DISCONNECTED state. 연결이 끊어진 복제본이 동기 커밋 모드로 구성되어 있더라도 트랜잭션에서는 해당 복제본이 다시 연결되어 다시 동기화될 때까지 대기하지 않습니다.Even if a disconnected replica is configured for synchronous-commit mode, transactions will not wait for that replica to reconnect and resynchronize.

각 가용성 복제본의 기본 세션 제한 시간은 10초입니다.The default session-timeout period for each availability replica is 10 seconds. 이 값은 사용자가 구성할 수 있으며 최소값은 5초입니다.This value is user-configurable, with a minimum of 5 seconds. 일반적으로 제한 시간을 10초 이상으로 유지하는 것이 좋습니다.Generally, we recommend that you keep the time-out period at 10 seconds or greater. 10초 미만의 값을 설정하면 로드가 많은 시스템에서 잘못된 실패를 선언할 수 있습니다.Setting the value to less than 10 seconds creates the possibility of a heavily loaded system declaring a false failure.

참고

확인 역할인 경우 ping이 발생하지 않기 때문에 세션 제한 시간이 적용되지 않습니다.In the resolving role, the session-timeout period does not apply because pinging does not occur.

자동 페이지 복구 Automatic Page Repair

각 가용성 복제본은 데이터 페이지를 읽지 못하게 하는 특정 오류 유형을 확인하여 로컬 데이터베이스의 손상된 페이지를 자동으로 복구하려고 시도합니다.Each availability replica tries to automatically recover from corrupted pages on a local database by resolving certain types of errors that prevent reading a data page. 보조 복제본이 페이지를 읽을 수 없는 경우 복제본은 주 복제본에서 페이지의 새 복사본을 요청합니다.If a secondary replica cannot read a page, the replica requests a fresh copy of the page from the primary replica. 주 복제본이 페이지를 읽을 수 없는 경우 복제본은 모든 보조 복제본에 새 복사본에 대한 요청을 브로드캐스팅하고 처음 응답하는 보조 복제본에서 페이지를 가져옵니다.If the primary replica cannot read a page, the replica broadcasts a request for a fresh copy to all the secondary replicas and gets the page from the first to respond. 이 요청이 성공하면 읽을 수 없는 페이지는 새 복사본으로 대체되고 일반적으로 오류가 해결됩니다.If this request succeeds, the unreadable page is replaced by the copy, which usually resolves the error.

자세한 내용은 자동 페이지 복구(가용성 그룹: 데이터베이스 미러링)를 참조하세요.For more information, see Automatic Page Repair (Availability Groups: Database Mirroring).

참고 항목See Also

가용성 모드(Always On 가용성 그룹) Availability Modes (Always On Availability Groups)
장애 조치 및 장애 조치 모드(Always On 가용성 그룹) Failover and Failover Modes (Always On Availability Groups)
Always On 가용성 그룹에 대한 Transact-SQL 문 개요(SQL Server) Overview of Transact-SQL Statements for Always On Availability Groups (SQL Server)
Always On 가용성 그룹에 대한 PowerShell Cmdlet 개요(SQL Server) Overview of PowerShell Cmdlets for Always On Availability Groups (SQL Server)
메모리 내 OLTP 데이터베이스에 대한 고가용성 지원 High Availability Support for In-Memory OLTP databases
Always On 가용성 그룹에 대한 필수 조건, 제한 사항 및 권장 사항(SQL Server) Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)
가용성 그룹의 생성 및 구성(SQL Server) Creation and Configuration of Availability Groups (SQL Server)
활성 보조: 읽기 가능한 보조 복제본(Always ON 가용성 그룹) Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
활성 보조: 보조 복제본에 백업(Always On 가용성 그룹) Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups)
가용성 그룹 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치(SQL Server)Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)