Always On 가용성 그룹에 대한 필수 조건, 제한 사항 및 권장 사항Prerequisites, Restrictions, and Recommendations for Always On availability groups

적용 대상:Applies to: 예SQL ServerSQL Server(지원되는 모든 버전)yesSQL ServerSQL Server (all supported versions) 적용 대상:Applies to: 예SQL ServerSQL Server(지원되는 모든 버전)yesSQL ServerSQL Server (all supported versions)

이 문서에서는 호스트 컴퓨터, WSFC(Windows Server 장애 조치 클러스터), 서버 인스턴스 및 가용성 그룹에 대한 필수 조건, 제한 사항 및 권장 사항을 포함하여 Always On 가용성 그룹Always On availability groups을 배포할 때 고려해야 할 사항에 대해 설명합니다.This article describes considerations for deploying Always On 가용성 그룹Always On availability groups, including prerequisites, restrictions, and recommendations for host computers, Windows Server failover clusters (WSFC), server instances, and availability groups. 이러한 각 구성 요소에 대한 보안 고려 사항과 필요한 권한이 있는 경우 알려줍니다.For each of these components security considerations and required permissions, if any, are indicated.

중요

Always On 가용성 그룹Always On availability groups을 배포하기 전에 이 항목의 모든 섹션을 읽어 보십시오.Before you deploy Always On 가용성 그룹Always On availability groups, we strongly recommend that you read every section of this topic.

가용성 그룹을 지원하는 .NET 핫픽스.NET Hotfixes that Support Availability Groups

Always On 가용성 그룹Always On availability groups과 함께 사용할 SQL Server 2019 (15.x)SQL Server 2019 (15.x) 구성 요소 및 기능에 따라 다음 테이블에 표시되어 있는 추가 .NET 핫픽스를 설치해야 할 수 있습니다.Depending on the SQL Server 2019 (15.x)SQL Server 2019 (15.x) components and features you will use with Always On 가용성 그룹Always On availability groups, you may need to install additional .NET hotfixes identified in the following table. 이러한 핫픽스는 순서에 관계없이 설치할 수 있습니다.The hotfixes can be installed in any order.

종속 기능Dependent Feature 핫픽스Hotfix 링크Link
Reporting ServicesReporting Services .NET 3.5 SP1 핫픽스는 읽기 전용 및 multisubnetfailover Always On 기능을 위한 지원을 SQL 클라이언트에 추가합니다.Hotfix for .NET 3.5 SP1 adds support to SQL Client for Always On features of Read-intent, readonly, and multisubnetfailover. Reporting ServicesReporting Services 보고서 서버에 핫픽스를 설치해야 합니다.The hotfix needs to be installed on each Reporting ServicesReporting Services report server. KB 2654347: Always On 기능을 위한 지원을 추가하는 .NET 3.5 SP1 핫픽스KB 2654347: Hotfix for .NET 3.5 SP1 to add support for Always On features

검사 목록: 요구 사항(Windows 시스템)Checklist: Requirements (Windows System)

Always On 가용성 그룹Always On availability groups 기능을 지원하려면 하나 이상의 가용성 그룹에 참여할 모든 컴퓨터가 다음 기본 요구 사항을 충족해야 합니다.To support the Always On 가용성 그룹Always On availability groups feature, ensure that every computer that is to participate in one or more availability groups meets the following fundamental requirements:

요구 사항Requirement 링크Link
시스템이 도메인 컨트롤러가 아닌지 확인하세요.Ensure that the system is not a domain controller. 가용성 그룹은 도메인 컨트롤러에서 지원되지 않습니다.Availability groups are not supported on domain controllers.
각 컴퓨터에서 Windows Server 2012 이상 버전이 실행되고 있어야 합니다.Ensure that each computer is running Windows Server 2012 or later versions. SQL Server 2016 설치를 위한 하드웨어 및 소프트웨어 요구 사항Hardware and Software Requirements for Installing SQL Server 2016
각 컴퓨터가 WSFC의 노드인지 확인합니다.Ensure that each computer is a node in a WSFC. SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링)Windows Server Failover Clustering (WSFC) with SQL Server
WSFC에 가용성 그룹 구성을 지원할 수 있는 노드가 충분한지 확인합니다.Ensure that the WSFC contains sufficient nodes to support your availability group configurations. 클러스터 노드는 가용성 그룹에 복제본 1개를 호스트할 수 있습니다.A cluster node can host one replica for an availability group. 동일한 노드는 동일한 가용성 그룹에서 복제본 2개를 호스트할 수 없습니다.The same node cannot host two replicas from the same availability group. 클러스터 노드는 각 그룹의 복제본 1개를 사용하여 여러 가용성 그룹에 참여할 수 있습니다.The cluster node can participate in multiple availability groups, with one replica from each group.

계획된 가용성 그룹의 가용성 복제본을 지원하는 데 필요한 클러스터 노드 수를 데이터베이스 관리자에게 문의하세요.Ask your database administrators how many cluster nodes are required for to support the availability replicas of the planned availability groups.

Always On 가용성 그룹 개요(SQL Server)을 참조하세요.Overview of Always On Availability Groups (SQL Server).

중요

또한 시스템이 가용성 그룹에 연결되도록 올바르게 구성되었는지 확인합니다.Also ensure that your environment is correctly configured for connecting to an availability group. 자세한 내용은 Always On 클라이언트 연결(SQL Server)을 참조하세요.For more information, see Always On Client Connectivity (SQL Server).

가용성 복제본을 호스팅하는 컴퓨터에 대한 권장 사항(Windows 시스템)Recommendations for Computers That Host Availability Replicas (Windows System)

  • 동등한 시스템: 지정된 가용성 그룹의 경우 모든 가용성 복제본은 동일한 작업을 처리할 수 있는 동등한 시스템에서 실행해야 합니다.Comparable systems: For a given availability group, all the availability replicas should run on comparable systems that can handle identical workloads.

  • 전용 네트워크 어댑터: 성능을 최대화하려면 Always On 가용성 그룹Always On availability groups 전용 네트워크 어댑터(네트워크 인터페이스 카드)를 사용합니다.Dedicated network adapters: For best performance, use a dedicated network adapter (network interface card) for Always On 가용성 그룹Always On availability groups.

  • 충분한 디스크 공간: 가용성 복제본을 호스팅하는 서버 인스턴스가 있는 모든 컴퓨터에는 가용성 그룹의 모든 데이터베이스를 저장하기에 충분한 디스크 공간이 있어야 합니다.Sufficient disk space: Every computer on which a server instance hosts an availability replica must possess sufficient disk space for all the databases in the availability group. 주 데이터베이스의 크기가 늘어나면 해당하는 보조 데이터베이스도 같은 크기만큼 늘어난다는 것에 유의해야 합니다.Keep in mind that as primary databases grow, their corresponding secondary databases grow the same amount.

사용 권한(Windows 시스템)Permissions (Windows System)

WSFC를 관리하려면 사용자가 모든 클러스터 노드의 시스템 관리자여야 합니다.To administer a WSFC, the user must be a system administrator on every cluster node.

클러스터 관리를 위한 계정에 대한 자세한 내용은 부록 A: 장애 조치(failover) 클러스터 요구 사항을 참조하세요.For more information about the account for administering the cluster, see Appendix A: Failover Cluster Requirements.

TaskTask 링크Link
HostRecordTTL 값을 설정합니다.Set the HostRecordTTL value. HostRecordTTL 변경(Windows PowerShell 사용)Change the HostRecordTTL (Using Windows PowerShell)

HostRecordTTL 변경(Windows PowerShell 사용)Change the HostRecordTTL (Using Windows PowerShell)

  1. 관리자 권한으로 실행 을 통해 PowerShell 창을 엽니다.Open PowerShell window via Run as Administrator.

  2. FailoverClusters 모듈을 가져옵니다.Import the FailoverClusters module.

  3. Get-ClusterResource cmdlet을 사용하여 네트워크 이름 리소스를 찾은 다음에 아래와 같이 Set-ClusterParameter cmdlet을 사용하여 HostRecordTTL 값을 설정합니다.Use the Get-ClusterResource cmdlet to find the Network Name resource, then use Set-ClusterParameter cmdlet to set the HostRecordTTL value, as follows:

    Get-ClusterResource " <NetworkResourceName> " | Set-ClusterParameter HostRecordTTL <TimeInSeconds>Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

    다음 PowerShell 예제에서는 SQL Network Name (SQL35)라는 네트워크 이름 리소스에 대해 HostRecordTTL을 300초로 설정합니다.The following PowerShell example sets the HostRecordTTL to 300 seconds for a Network Name resource named SQL Network Name (SQL35).

    Import-Module FailoverClusters  
    
    $nameResource = "SQL Network Name (SQL35)"  
    Get-ClusterResource $nameResource | Set-ClusterParameter ClusterParameter HostRecordTTL 300  
    

    새 PowerShell 창을 열 때마다 FailoverClusters 모듈을 가져와야 합니다.Every time you open a new PowerShell window, you need to import the FailoverClusters module.

SQL Server 인스턴스 필수 구성 요소 및 제한 사항SQL Server Instance Prerequisites and Restrictions

각 가용성 그룹에는 인스턴스에서 호스팅되는 가용성 복제본 SQL ServerSQL Server이라는 일련의 장애 조치(Failover) 파트너가 필요합니다.Each availability group requires a set of failover partners, known as availability replicas, which are hosted by instances of SQL ServerSQL Server. 특정 서버 인스턴스는 독립 실행형 인스턴스 또는 SQL ServerSQL Server장애 조치(failover) 클러스터 인스턴스 일 수 있습니다.A given server instance can be a stand-alone instance or a SQL ServerSQL Serverfailover cluster instance (FCI).

섹션 내용In This Section:

검사 목록: 필수 구성 요소(서버 인스턴스)Checklist: Prerequisites (Server Instance)

필수 요소Prerequisite 링크Links
호스트 컴퓨터는 WSFC 노드여야 합니다.The host computer must be a WSFC node. 지정된 가용성 그룹의 가용성 복제본을 호스팅하는 SQL ServerSQL Server 인스턴스는 클러스터의 개별 노드에 있습니다.The instances of SQL ServerSQL Server that host availability replicas for a given availability group reside on separate nodes of the cluster. 다른 클러스터로 마이그레이션되는 동안 가용성 그룹이 일시적으로 두 클러스터에 걸쳐 있을 수 있습니다.An availability group can temporarily straddle two clusters while being migrated to different cluster. SQL Server 2016에서는 분산된 가용성 그룹을 소개합니다.SQL Server 2016 introduces distributed availability groups. 분산 가용성 그룹에서는 두 가용성 그룹이 서로 다른 클러스터에 있습니다.In a distributed availability group two availability groups reside on different clusters. SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링)Windows Server Failover Clustering (WSFC) with SQL Server

장애 조치(failover) 클러스터링 및 Always On 가용성 그룹(SQL Server)Failover Clustering and Always On Availability Groups (SQL Server)

분산된 가용성 그룹(Always On 가용성 그룹)Distributed Availability Groups (Always On Availability Groups)
가용성 그룹이 Kerberos로 작동하도록 하려는 경우:If you want an availability group to work with Kerberos:

가용성 그룹에 대한 가용성 복제본을 호스팅하는 모든 서버 인스턴스는 동일한 SQL Server 서비스 계정을 사용해야 합니다.All server instances that host an availability replica for the availability group must use the same SQL Server service account.

도메인 관리자는 가용성 그룹 수신기의 VNN(가상 네트워크 이름)에 대해 SQL Server 서비스 계정에서 Active Directory에 SPN(서비스 사용자 이름)을 수동으로 등록해야 합니다.The domain administrator needs to manually register a Service Principal Name (SPN) with Active Directory on the SQL Server service account for the virtual network name (VNN) of the availability group listener. SQL Server 서비스 계정이 아닌 다른 계정에 SPN이 등록된 경우 인증이 실패합니다.If the SPN is registered on an account other than the SQL Server service account, authentication will fail.



** 중요 ** SQL Server 서비스 계정을 변경하면 도메인 관리자가 SPN을 수동으로 다시 등록해야 합니다.** Important ** If you change the SQL Server service account, the domain administrator will need to manually re-register the SPN.
Kerberos 연결의 서비스 사용자 이름 등록Register a Service Principal Name for Kerberos Connections

간략한 설명:Brief explanation:

Kerberos 및 SPN은 상호 인증을 강제 적용합니다.Kerberos and SPNs enforce mutual authentication. SPN은 SQL Server 서비스를 시작하는 Windows 계정에 매핑됩니다.The SPN maps to the Windows account that starts the SQL Server services. SPN이 올바르게 등록되지 않았거나 실패하면, Windows 보안 계층이 SPN과 연결된 계정을 확인할 수 없으며, Kerberos 인증을 사용할 수 없습니다.If the SPN is not registered correctly or if it fails, the Windows security layer cannot determine the account associated with the SPN, and Kerberos authentication cannot be used.



참고: NTLM에는 이러한 요구 사항이 없습니다.Note: NTLM does not have this requirement.
SQL ServerSQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)를 사용하여 가용성 복제본을 호스팅하려는 경우 FCI 제한 사항을 이해하고 FCI 요구 사항을 충족해야 합니다.If you plan to use a SQL ServerSQL Server failover cluster instance (FCI) to host an availability replica, ensure that you understand the FCI restrictions and that the FCI requirements are met. SQL Server FCI(장애 조치(failover) 클러스터 인스턴스)를 사용하여 가용성 복제본을 호스트하기 위한 필수 구성 요소 및 요구 사항(이 문서 뒷부분)Prerequisites and Requirements on Using a SQL Server Failover Cluster Instance (FCI) to Host an Availability Replica (later in this article)
각 서버 인스턴스는 Always On 가용성 그룹에 참여하기 위해 동일한 버전의 SQL Server를 실행해야 합니다.Each server instance must be running the same version of SQL Server to participate in an Always On Availability Group. SQL 2014, SQL 2016, SQL 2017의 버전 및 지원되는 기능Editions and supported features for SQL 2014, SQL 2016, SQL 2017.
가용성 그룹의 가용성 복제본을 호스팅하는 모든 서버 인스턴스는 동일한 SQL ServerSQL Server 데이터 정렬을 사용해야 합니다.All the server instances that host availability replicas for an availability group must use the same SQL ServerSQL Server collation. 서버 데이터 정렬 설정 또는 변경Set or Change the Server Collation
가용성 그룹의 가용성 복제본을 호스팅할 각 서버 인스턴스에서 Always On 가용성 그룹Always On availability groups 기능을 사용하도록 설정합니다.Enable the Always On 가용성 그룹Always On availability groups feature on each server instance that will host an availability replica for any availability group. 특정 컴퓨터에서 Always On 가용성 그룹Always On availability groups 설치에서 지원하는 SQL ServerSQL Server 서버 인스턴스를 개수에 관계없이 사용하도록 설정할 수 있습니다.On a given computer, you can enable as many server instances for Always On 가용성 그룹Always On availability groups as your SQL ServerSQL Server installation supports. Always On 가용성 그룹 활성화 및 비활성화(SQL Server)Enable and Disable Always On Availability Groups (SQL Server)



** 중요 ** WSFC를 삭제하고 다시 만드는 경우 원본 클러스터에서 Always On 가용성 그룹Always On availability groups에 대해 사용하도록 설정한 각 서버 인스턴스에서 Always On 가용성 그룹Always On availability groups 기능을 해제한 다음 다시 사용하도록 설정해야 합니다.** Important ** If you destroy and re-create a WSFC, you must disable and re-enable the Always On 가용성 그룹Always On availability groups feature on each server instance that was enabled for Always On 가용성 그룹Always On availability groups on the original cluster.
각 서버 인스턴스에는 데이터베이스 미러링 엔드포인트가 있어야 합니다.Each server instance requires a database mirroring endpoint. 이 엔드포인트는 서버 인스턴스의 미러링 모니터 서버 및 데이터베이스 미러링 파트너와 모든 가용성 복제본에서 공유합니다.Note that this endpoint is shared by all the availability replicas and database mirroring partners and witnesses on the server instance.

가용성 복제본을 호스팅하도록 선택한 서버 인스턴스가 도메인 사용자 계정으로 실행되고 있고 아직 데이터베이스 미러링 엔드포인트를 가지고 있지 않는 경우, 새 가용성 그룹 마법사 (또는 가용성 그룹에 복제본 추가 마법사) 가 엔드포인트를 만들고 서버 인스턴스 서비스 계정에 CONNECT 권한을 부여할 수 있습니다.If a server instance that you select to host an availability replica is running under a domain user account and does not yet have a database mirroring endpoint, the New Availability Group Wizard (or Add Replica to Availability Group Wizard) can create the endpoint and grant CONNECT permission to the server instance service account. 그러나 SQL ServerSQL Server 서비스가 로컬 시스템, 로컬 서비스 또는 네트워크 서비스와 같은 기본 제공 계정이나 비도메인 계정으로 실행 중인 경우에는 사용자가 엔드포인트 인증을 위한 인증서를 사용해야 하며 마법사를 통해 서버 인스턴스에 대한 데이터베이스 미러링 엔드포인트를 만들 수는 없습니다.However, if the SQL ServerSQL Server service is running as a built-in account, such as Local System, Local Service, or Network Service, or a nondomain account, you must use certificates for endpoint authentication, and the wizard will be unable to create a database mirroring endpoint on the server instance. 이 경우 마법사를 시작하기 전에 데이터 미러링 엔드포인트를 수동으로 만드는 것이 좋습니다.In this case, we recommend that you create the database mirroring endpoints manually before you launch the wizard.



** 보안 정보 **Always On 가용성 그룹Always On availability groups 에 대한 전송 보안은 데이터베이스 미러링의 경우와 동일합니다.** Security Note ** Transport security for Always On 가용성 그룹Always On availability groups is the same as for database mirroring.
데이터베이스 미러링 엔드포인트(SQL Server)The Database Mirroring Endpoint (SQL Server)

데이터베이스 미러링 및 Always On 가용성 그룹에 대한 전송 보안(SQL Server)Transport Security for Database Mirroring and Always On Availability Groups (SQL Server)
FILESTREAM을 사용하는 데이터베이스를 가용성 그룹에 추가하려는 경우 가용성 그룹의 가용성 복제본을 호스팅할 모든 서버 인스턴스에 FILESTREAM이 설정되었는지 확인합니다.If any databases that use FILESTREAM will be added to an availability group, ensure that FILESTREAM is enabled on every server instance that will host an availability replica for the availability group. Enable and Configure FILESTREAMEnable and Configure FILESTREAM
포함된 데이터베이스를 가용성 그룹에 추가하려는 경우 가용성 그룹의 가용성 복제본을 호스팅할 모든 서버 인스턴스에서 contained database authentication 서버 옵션이 1 로 설정되어 있는지 확인합니다.If any contained databases will be added to an availability group, ensure that the contained database authentication server option is set to 1 on every server instance that will host an availability replica for the availability group. contained database authentication 서버 구성 옵션contained database authentication Server Configuration Option

서버 구성 옵션(SQL Server)Server Configuration Options (SQL Server)

가용성 그룹의 스레드 사용량Thread Usage by Availability Groups

Always On 가용성 그룹Always On availability groups 은 작업자 스레드에 대해 다음 요구 사항을 충족해야 합니다.has the following requirements for worker threads:

  • SQL ServerSQL Server의 유휴 인스턴스에서 Always On 가용성 그룹Always On availability groups 은 0개의 스레드를 사용합니다.On an idle instance of SQL ServerSQL Server, Always On 가용성 그룹Always On availability groups uses 0 threads.

  • 가용성 그룹에서 사용되는 최대 스레드 수는 최대 서버 스레드 수('max worker threads')에서 40을 빼고 구성된 설정입니다.The maximum number of threads used by availability groups is the configured setting for the maximum number of server threads ('max worker threads') minus 40.

  • 지정된 서버 인스턴스에서 호스팅되는 가용성 복제본은 단일 스레드 풀을 공유합니다.The availability replicas hosted on a given server instance share a single thread pool.

    스레드는 다음과 같이 요청 시 공유됩니다.Threads are shared on an on-demand basis, as follows:

    • 일반적으로 3-10개의 공유 스레드가 있지만 이 수는 주 복제본 워크로드에 따라 증가할 수 있습니다.Typically, there are 3-10 shared threads, but this number can increase depending on the primary replica workload.

    • 지정된 스레드가 얼마 동안 유휴 상태인 경우 일반 SQL ServerSQL Server 스레드 풀로 반환됩니다.If a given thread is idle for a while, it is released back into the general SQL ServerSQL Server thread pool. 일반적으로 비활성 스레드는 아무 작업이 없는 상태가 지속된 지 15초 이내에 해제됩니다.Normally, an inactive thread is released after ~15 seconds of inactivity. 그러나 마지막 활동에 따라 유휴 스레드가 더 길게 유지될 수 있습니다.However, depending on the last activity, an idle thread might be retained longer.

    • SQL Server 인스턴스에서는 보조 복제본에 대한 병렬 다시 실행을 위해 최대 100개의 스레드를 사용합니다.A SQL Server instance uses up to 100 threads for parallel redo for secondary replicas. 각 데이터베이스는 최대 총 CPU 코어 수의 절반을 사용하지만 데이터베이스당 스레드는 16개까지 사용됩니다.Each database uses up to one-half of the total number of CPU cores, but not more than 16 threads per database. 단일 인스턴스에 필요한 총 스레드 수가 100개를 넘으면 SQL Server에서는 나머지 모든 데이터베이스에 대해 단일 다시 실행 스레드를 사용합니다.If the total number of required threads for a single instance exceeds 100, SQL Server uses a single redo thread for every remaining database. 직렬 다시 실행 스레드는 아무 작업이 없는 상태가 지속된 지 15초 이내에 해제됩니다.Serial Redo threads are released after ~15 seconds of inactivity.

  • 또한 가용성 그룹은 다음과 같이 비공유 스레드를 사용합니다.In addition, availability groups use unshared threads, as follows:

    • 각각의 주 복제본은 각 주 데이터베이스에 대해 1개의 로그 캡처 스레드를 사용합니다.Each primary replica uses 1 Log Capture thread for each primary database. 또한 각 보조 데이터베이스에 대해 1개의 로그 전송 스레드를 사용합니다.In addition, it uses 1 Log Send thread for each secondary database. 로그 전송 스레드는 아무 작업이 없는 상태가 지속된 지 15초 이내에 해제됩니다.Log send threads are released after ~15 seconds of inactivity.

    • 보조 복제본의 백업은 백업 작업 시간 동안 주 스레드를 복제본에 보관합니다.A backup on a secondary replica holds a thread on the primary replica for the duration of the backup operation.

  • SQL Server 2019에서는 메모리 최적화 가용성 그룹 데이터베이스를 위한 병렬 다시 실행이 도입되었습니다.SQL Server 2019 introduced parallel redo for memory optimized availability group databases. SQL Server 2016 및 2017에서는 가용성 그룹의 데이터베이스가 메모리 최적화된 경우에도 디스크 기반 테이블에서 병렬 다시 실행을 사용하지 않습니다.In SQL Server 2016 and 2017, disk-based tables do not use parallel redo if a database in an availability group is also memory optimized.

자세한 내용은 Always On - HADRON 학습 시리즈: HADRON 사용 데이터베이스의 작업자 풀 사용(CSS SQL ServerSQL Server 엔지니어 블로그)을 참조하세요.For more information, see Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (a CSS SQL ServerSQL Server Engineers Blog).

사용 권한(서버 인스턴스)Permissions (Server Instance)

TaskTask 필요한 권한Required Permissions
데이터베이스 미러링 엔드포인트 만들기Creating the database mirroring endpoint CREATE ENDPOINT 권한 또는 sysadmin 고정 서버 역할의 멤버 자격이 필요합니다.Requires CREATE ENDPOINT permission, or membership in the sysadmin fixed server role. CONTROL ON ENDPOINT 권한도 필요합니다.Also requires CONTROL ON ENDPOINT permission. 자세한 내용은 GRANT 엔드포인트 사용 권한(Transact-SQL)을 참조하세요.For more information, see GRANT Endpoint Permissions (Transact-SQL).
다음 사용 Always On 가용성 그룹Always On availability groupsEnabling Always On 가용성 그룹Always On availability groups 로컬 컴퓨터의 관리자 그룹 멤버 자격과 WSFC에 대한 모든 권한이 필요합니다.Requires membership in the Administrator group on the local computer and full control on the WSFC.
TaskTask 아티클Article
데이터베이스 미러링 엔드포인트가 있는지 여부 확인Determining whether database mirroring endpoint exists sys.database_mirroring_endpoints(Transact-SQL)sys.database_mirroring_endpoints (Transact-SQL)
데이터베이스 미러링 엔드포인트 만들기(없는 경우)Creating the database mirroring endpoint (if it does not yet exist) Windows 인증에 대한 데이터베이스 미러링 엔드포인트 만들기(Transact-SQL)Create a Database Mirroring Endpoint for Windows Authentication (Transact-SQL)

데이터베이스 미러링 엔드포인트에 대한 인증서 사용(Transact-SQL)Use Certificates for a Database Mirroring Endpoint (Transact-SQL)

Always On 가용성 그룹에 대한 데이터베이스 미러링 엔드포인트 만들기(SQL Server PowerShell)Create a Database Mirroring Endpoint for Always On Availability Groups (SQL Server PowerShell)
가용성 그룹 활성화Enabling Availability Groups Always On 가용성 그룹 활성화 및 비활성화(SQL Server)Enable and Disable Always On Availability Groups (SQL Server)

네트워크 연결 권장 사항Network Connectivity Recommendations

WSFC 노드 간의 통신 및 가용성 복제본 간의 통신에는 동일한 네트워크 링크를 사용하는 것이 좋습니다.We strongly recommend that you use the same network links for communications between WSFC nodes and communications between availability replicas. 개별 네트워크 링크를 사용하면 가끔씩이라도 일부 링크에 문제가 발생할 경우 예기치 않은 동작이 발생할 수 있습니다.Using separate network links can cause unexpected behaviors if some of links fail (even intermittently).

예를 들어, 가용성 그룹으로 자동 장애 조치(Failover)를 지원하기 위해서는 자동 장애 조치(Failover) 파트너인 두 번째 복제본이 SYNCHRONIZED 상태여야 합니다.For example, for an availability group to support automatic failover, the secondary replica that is the automatic-failover partner must be in the SYNCHRONIZED state. 이 보조 복제본에 대한 네트워크 링크가 가끔씩이라도 실패할 경우 복제본이 UNSYNCHRONIZED 상태가 되고 링크가 복원될 때까지 다시 동기화를 시작할 수 없습니다.If the network link to this secondary replica fails (even intermittently), the replica enters the UNSYNCHRONIZED state and cannot begin to resynchronize until the link is restored. 보조 복제본이 동기화되지 않은 상태에서 WSFC가 자동 장애 조치를 요청하는 경우 자동 장애 조치가 수행되지 않습니다.If the WSFC requests an automatic failover while the secondary replica is unsynchronized, automatic failover will not occur.

클라이언트 연결 지원Client Connectivity Support

클라이언트 연결의 Always On 가용성 그룹Always On availability groups 지원에 대한 자세한 내용은 Always On 클라이언트 연결(SQL Server)을 참조하세요.For information about Always On 가용성 그룹Always On availability groups support for client connectivity, see Always On Client Connectivity (SQL Server).

SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)를 사용하여 가용성 복제본을 호스팅하기 위한 필수 구성 요소 및 제한 사항Prerequisites and Restrictions for Using a SQL Server Failover Cluster Instance (FCI) to Host an Availability Replica

섹션 내용In This Section:

제한 사항(FCI)Restrictions (FCIs)

참고

장애 조치(failover) 클러스터 인스턴스는 CSV(클러스터 공유 볼륨)를 지원합니다.Failover Cluster Instances supports Clustered Shared Volumes (CSV). CSV에 대한 자세한 내용은 장애 조치(Failover) 클러스터에서 클러스터 공유 볼륨 이해를 참조하세요.For more information on CSV, see Understanding Cluster Shared Volumes in a Failover Cluster.

  • FCI의 클러스터 노드는 특정 가용성 그룹에 대한 하나의 복제본만 호스팅할 수 있습니다. FCI에 가용성 복제본을 추가하는 경우 잠재적인 FCI 소유자인 WSFC 노드는 동일한 가용성 그룹에 대해 다른 복제본을 호스팅할 수 없습니다.The cluster nodes of an FCI can host only one replica for a given availability group: If you add an availability replica on an FCI, the WSFC nodes that are possible FCI owners cannot host another replica for the same availability group. 가능한 충돌을 방지하려면 장애 조치(Failover) 클러스터 인스턴스의 가능한 소유자를 구성하는 것이 좋습니다.To avoid possible conflicts, it is recommended to configure possible owners for the failover cluster instance. 그러면 단일 WSFC에서 동일한 가용성 그룹의 두 가용성 복제본을 호스트하려고 시도하지 않게 됩니다.This will prevent potentially causing a single WSFC from attempting to host two availability replicas for the same availability group.

    또한 다른 모든 복제본은 동일한 Windows Server 장애 조치(Failover) 클러스터의 다른 클러스터 노드에 있는 SQL Server 2016 인스턴스에서 호스트해야 합니다.Furthermore, every other replica must be hosted by an instance of SQL Server 2016 that resides on a different cluster node in the same Windows Server failover cluster. 유일한 예외는 다른 클러스터로 마이그레이션되는 동안 가용성 그룹이 일시적으로 두 클러스터에 걸쳐 있을 수 있는 경우입니다.The only exception is that while being migrated to another cluster, an availability group can temporarily straddle two clusters.

경고

장애 조치(Failover) 클러스터 관리자를 사용하여 가용성 그룹을 호스트하는 장애 조치(Failover) 클러스터 인스턴스 를 동일한 가용성 그룹의 복제본을 이미 호스트하는 노드로 이동하면 가용성 그룹의 복제본이 손실되어 대상 노드에서 온라인 상태가 될 수 없습니다.Using the Failover Cluster Manager to move a failover cluster instance hosting an availability group to a node that is already hosting a replica of the same availability group may result in the loss of the availability group replica, preventing it from being brought online on the target node. 장애 조치(Failover) 클러스터의 단일 노드는 동일한 가용성 그룹의 복제본 2개 이상을 호스트할 수 없습니다.A single node of a failover cluster cannot host more than one replica for the same availability group. 이러한 결과가 나타나는 방식 및 복구 방법에 대한 자세한 내용은 블로그 Replica unexpectedly dropped in availability group(복제본이 가용성 그룹에서 예기치 않게 손실되는 경우)를 참조하세요.For more information on how this occurs, and how to recover, see the blog Replica unexpectedly dropped in availability group.

  • FCI는 가용성 그룹별 자동 장애 조치(failover)를 지원하지 않습니다. FCI는 가용성 그룹에 의한 자동 장애 조치(failover)를 지원하지 않으므로 FCI에서 호스트하는 모든 가용성 복제본은 수동 장애 조치(failover)에 대해서만 구성될 수 있습니다.FCIs do not support automatic failover by availability groups: FCIs do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can be configured for manual failover only.

  • FCI 네트워크 이름 변경: 가용성 복제본을 호스트하는 FCI의 네트워크 이름을 변경해야 하는 경우 복제본을 해당 가용성 그룹에서 제거한 다음, 다시 가용성 그룹에 추가해야 합니다.Changing FCI network name: If you need to change the network name of an FCI that hosts an availability replica, you will need to remove the replica from its availability group and then add the replica back into the availability group. 주 복제본은 제거할 수 없으므로 주 복제본을 호스팅하는 FCI의 이름을 바꾸려는 경우 보조 복제본으로 장애 조치한 다음 이전 주 복제본을 제거하고 다시 추가해야 합니다.You cannot remove the primary replica, so if you are renaming an FCI that is hosting the primary replica, you should fail over to a secondary replica and then remove the former primary replica and add it back. FCI 이름을 바꾸면 해당 데이터베이스 미러링 엔드포인트의 URL이 변경될 수 있습니다.Note that renaming an FCI might alter the URL of its database mirroring endpoint. 복제본을 추가할 때 현재 엔드포인트 URL을 지정해야 합니다.When you add the replica ensure that you specify the current endpoint URL.

검사 목록: 필수 구성 요소(FCI)Checklist: Prerequisites (FCIs)

필수 요소Prerequisite 링크Link
각 SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)에 SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스 설치별로 필요한 공유 스토리지가 있는지 확인합니다.Ensure that each SQL Server failover cluster instance (FCI) possesses the required shared storage as per standard SQL Server failover cluster instance installation.
TaskTask 아티클Article
SQL Server 장애 조치(Failover) 클러스터 설치Installing a SQL Server Failover Cluster 새 SQL Server 장애 조치(failover) 클러스터 만들기(설치 프로그램)Create a New SQL Server Failover Cluster (Setup)
SQL Server 장애 조치(Failover) 클러스터의 전체 업그레이드In-place upgrade of your existing SQL Server Failover Cluster SQL Server 장애 조치(failover) 클러스터 인스턴스 업그레이드(설치 프로그램)Upgrade a SQL Server Failover Cluster Instance (Setup)
기존 SQL Server 장애 조치(Failover) 클러스터 유지 관리Maintaining your existing SQL Server Failover Cluster SQL Server 장애 조치(Failover) 클러스터에서 노드 추가 또는 제거(설치)Add or Remove Nodes in a SQL Server Failover Cluster (Setup)

가용성 그룹 필수 구성 요소 및 제한 사항Availability Group Prerequisites and Restrictions

섹션 내용In This Section:

제한 사항(가용성 그룹)Restrictions (Availability Groups)

  • 가용성 복제본은 하나의 WSFC의 다른 노드에서 호스팅해야 합니다. 지정된 가용성 그룹의 경우 가용성 복제본은 동일한 WSFC의 다른 노드에서 실행되는 서버 인스턴스에서 호스팅해야 합니다.Availability replicas must be hosted by different nodes of one WSFC: For a given availability group, availability replicas must be hosted by server instances running on different nodes of the same WSFC. 유일한 예외는 다른 클러스터로 마이그레이션되는 동안 가용성 그룹이 일시적으로 두 클러스터에 걸쳐 있을 수 있는 경우입니다.The only exception is that while being migrated to another cluster, an availability group can temporarily straddle two clusters.

    참고

    동일한 실제 컴퓨터에 가상 머신이 있는 경우에는 각 가상 머신이 개별 컴퓨터 역할을 하므로 가상 머신별로 동일한 가용성 그룹의 가용성 복제본을 하나씩 호스팅할 수 있습니다.Virtual machines on the same physical computer can each host an availability replica for the same availability group because each virtual machine acts as a separate computer.

  • 고유한 가용성 그룹 이름: 각 가용성 그룹 이름은 WSFC에서 고유해야 합니다.Unique availability group name: Each availability group name must be unique on the WSFC. 가용성 그룹 이름의 최대 길이는 128자입니다.The maximum length for an availability group name is 128 characters.

  • 가용성 복제본: 각 가용성 그룹은 하나의 주 복제본과 최대 8개의 보조 복제본을 지원합니다.Availability replicas: Each availability group supports one primary replica and up to eight secondary replicas. 모든 복제본은 비동기 커밋 모드에서 실행하거나 최대 3개의 복제본은 동기 커밋 동기 모드에서 실행할 수 있습니다(하나의 주 복제본과 2개의 동기 보조 복제본).All of the replicas can run under asynchronous-commit mode, or up to three of them can run under synchronous-commit mode (one primary replica with two synchronous secondary replicas).

  • 가용성 그룹 및 컴퓨터당 가용성 데이터베이스의 최대 수: 컴퓨터(가상 머신 또는 물리적 컴퓨터)에 만들 수 있는 데이터베이스와 가용성 그룹의 실제 수는 하드웨어 및 작업에 따라 다르며 정해진 제한은 없습니다.Maximum number of availability groups and availability databases per computer: The actual number of databases and availability groups you can put on a computer (VM or physical) depends on the hardware and workload, but there is no enforced limit. Microsoft는 물리적 컴퓨터당 최대 10개의 AG와 100개의 DB를 테스트했으며, 하지만 이것이 바인딩 제한은 아닙니다.Microsoft has tested up to 10 AGs and 100 DBs per physical machine, however this is not a binding limit. 서버의 하드웨어 사양 및 워크로드에 따라 더 많은 수의 데이터베이스와 가용성 그룹을 SQL Server 인스턴스에 배치할 수 있습니다.Depending on the hardware specification on the server and the workload, you can put a higher number of databases and availability groups on an instance of SQL Server. 오버로드된 시스템 징후에는 작업자 스레드 소진, 가용성 그룹 시스템 뷰와 DMV에 대한 느린 응답 시간 및/또는 대기된 디스패처 시스템 덤프 및 기타 징후가 포함될 수 있습니다.Signs of overloaded systems can include, but are not limited to, worker thread exhaustion, slow response times for availability group system views and DMVs, and/or stalled dispatcher system dumps. 해당 애플리케이션 SLA 내에서 최대 작업량을 처리할 수 있도록 하기 위해 프로덕션 환경과 유사한 작업으로 환경을 철저히 테스트하세요.Please make sure to thoroughly test your environment with a production-like workload to ensure it can handle peak workload capacity within your application SLAs. SLA를 고려할 경우 예상 응답 시간뿐 아니라 오류 상태에서의 로드를 검토해야 합니다.When considering SLAs be sure to consider load under failure conditions as well as expected response times.

  • 장애 조치(Failover) 클러스터 관리자를 사용하여 가용성 그룹을 조작하지 마세요.Do not use the Failover Cluster Manager to manipulate availability groups. SQL Server 장애 조치(Failover) 클러스터 인스턴스(FCI)의 상태는 SQL Server와 WSFC(Windows 장애 조치(failover) 클러스터) 간에 공유되며, SQL Server 클러스터에 관해 클러스터에 보다 더 자세한 상태 정보를 유지합니다.The state of a SQL Server Failover Cluster Instance (FCI) is shared between SQL Server and the Windows Failover Cluster (WSFC), with SQL Server keeping more detailed state information about the instances than the cluster cares about. 관리 모델은 SQL Server가 트랜잭션을 구동해야 하며, 상태에 대한 클러스터의 보기를 SQL Server의 상태 뷰와 동기화 상태로 유지할 책임을 집니다.The management model is that SQL Server must drive the transactions, and is responsible for keeping the cluster's view of the state in sync with SQL Server's view of state. 클러스터의 상태가 SQL Server 외부에서 변경되는 경우 WSFC와 SQL Server 간에 상태가 동기화되지 않을 수 있으며 이로 인해 예기치 않은 동작이 발생할 수 있습니다.If the state of the cluster is changed outside of SQL Server it is possible for the state to get out of sync between WSFC and SQL Server, which may lead to unpredictable behavior.

    예를 들면 다음과 같습니다.For example:

    • 가능한 소유자와 같은 가용성 그룹 속성을 변경하지 마세요.Do not change any availability group properties, such as the possible owners.

    • 장애 조치(Failover) 클러스터 관리자를 사용하여 가용성 그룹을 장애 조치하지 마세요.Do not use the Failover Cluster Manager to fail over availability groups. Transact-SQLTransact-SQL 또는 SQL Server Management StudioSQL Server Management Studio를 사용해야 합니다.You must use Transact-SQLTransact-SQL or SQL Server Management StudioSQL Server Management Studio.

필수 구성 요소(가용성 그룹)Prerequisites (Availability Groups)

가용성 그룹 구성을 구성하거나 다시 구성할 때 다음 요구 사항을 따라야 합니다.When creating or reconfiguring an availability group configuration, ensure that you adhere to the following requirements.

필수 요소Prerequisite DescriptionDescription
SQL ServerSQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)를 사용하여 가용성 복제본을 호스팅하려는 경우 FCI 제한 사항을 이해하고 FCI 요구 사항을 충족해야 합니다.If you plan to use a SQL ServerSQL Server failover cluster instance (FCI) to host an availability replica, ensure that you understand the FCI restrictions and that the FCI requirements are met. SQL Server FCI(장애 조치(Failover) 클러스터 인스턴스)를 사용하여 가용성 복제본을 호스트하기 위한 필수 구성 요소 및 제한 사항(이 문서 앞부분)Prerequisites and Restrictions for Using a SQL Server Failover Cluster Instance (FCI) to Host an Availability Replica (earlier in this article)

보안(가용성 그룹)Security (Availability Groups)

  • 보안은 WSFC에서 상속됩니다.Security is inherited from the WSFC. Windows Server 장애 조치 클러스터링은 전체 클러스터의 세분성에서 두 가지 수준의 사용자 보안을 제공합니다.Windows Server failover clustering provides two levels of user security at the granularity of entire cluster:

    • 읽기 전용 액세스Read-only access

    • 모든 권한Full control

      Always On 가용성 그룹Always On availability groups에는 모든 권한이 필요하며, SQL ServerSQL Server 인스턴스에서 Always On 가용성 그룹Always On availability groups을 사용하도록 설정하면 서비스 SID를 통해 클러스터에 대한 모든 권한이 제공됩니다.need full control, and enabling Always On 가용성 그룹Always On availability groups on an instance of SQL ServerSQL Server gives it full control of the cluster (through Service SID).

      클러스터 관리자에서 서버 인스턴스에 대한 보안을 직접 추가하거나 제거할 수 없습니다.You cannot directly add or remove security for a server instance in Cluster Manager. 클러스터 보안 세션을 관리하려면 SQL ServerSQL Server 구성 관리자 또는 이와 동등한 SQL ServerSQL Server의 WMI를 사용합니다.To manage cluster security sessions, use the SQL ServerSQL Server Configuration Manager or the WMI equivalent from SQL ServerSQL Server.

  • SQL ServerSQL Server 인스턴스에는 레지스트리, 클러스터 등에 액세스할 수 있는 권한이 있어야 합니다.Each instance of SQL ServerSQL Server must have permissions to access the registry, cluster, and so forth.

  • Always On 가용성 그룹Always On availability groups 가용성 복제본을 호스팅하는 서버 인스턴스 간의 연결에는 암호화를 사용하는 것이 좋습니다.We recommend that you use encryption for connections between server instances that host Always On 가용성 그룹Always On availability groups availability replicas.

사용 권한(가용성 그룹)Permissions (Availability Groups)

TaskTask 필요한 권한Required Permissions
가용성 그룹 만들기Creating an availability group CREATE AVAILABILITY GROUP 서버 권한, ALTER ANY AVAILABILITY GROUP 권한, CONTROL SERVER 권한 중 하나와 sysadmin 고정 서버 역할의 멤버 자격이 필요합니다.Requires membership in the sysadmin fixed server role and either CREATE AVAILABILITY GROUP server permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.
가용성 그룹 변경Altering an availability group 가용성 그룹에 대한 ALTER AVAILABILITY GROUP 권한, CONTROL AVAILABILITY GROUP 권한, ALTER ANY AVAILABILITY GROUP 권한 또는 CONTROL SERVER 권한이 필요합니다.Requires ALTER AVAILABILITY GROUP permission on the availability group, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.

또한 데이터베이스를 가용성 그룹에 조인하려면 db_owner 고정 데이터베이스 역할의 멤버여야 합니다.In addition, joining a database to an availability group requires membership in the db_owner fixed database role.
가용성 그룹 삭제Dropping/deleting an availability group 가용성 그룹에 대한 ALTER AVAILABILITY GROUP 권한, CONTROL AVAILABILITY GROUP 권한, ALTER ANY AVAILABILITY GROUP 권한 또는 CONTROL SERVER 권한이 필요합니다.Requires ALTER AVAILABILITY GROUP permission on the availability group, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission. 로컬 복제본 위치에서 호스팅되지 않는 가용성 그룹을 삭제하려면 해당 가용성 그룹에 대한 CONTROL SERVER 권한이나 CONTROL 권한이 필요합니다.To drop an availability group that is not hosted on the local replica location you need CONTROL SERVER permission or CONTROL permission on that Availability Group.
TaskTask 아티클Article
가용성 그룹 만들기Creating an availability group 가용성 그룹 사용(새 가용성 그룹 마법사)Use the Availability Group (New Availability Group Wizard)

가용성 그룹 만들기(Transact-SQL)Create an Availability Group (Transact-SQL)

가용성 그룹 만들기(SQL Server PowerShell)Create an Availability Group (SQL Server PowerShell)

가용성 복제본 추가 또는 수정 시 엔드포인트 URL 지정(SQL Server)Specify the Endpoint URL When Adding or Modifying an Availability Replica (SQL Server)
가용성 복제본 개수 수정Modifying the number of availability replicas 가용성 그룹에 보조 복제본 추가(SQL Server)Add a Secondary Replica to an Availability Group (SQL Server)

가용성 그룹에 보조 복제본 조인(SQL Server)Join a Secondary Replica to an Availability Group (SQL Server)

가용성 그룹에서 보조 복제본 제거(SQL Server)Remove a Secondary Replica from an Availability Group (SQL Server)
가용성 그룹 수신기 만들기Creating an availability group listener 가용성 그룹 수신기 만들기 또는 구성(SQL Server)Create or Configure an Availability Group Listener (SQL Server)
가용성 그룹 삭제Dropping an availability group 가용성 그룹 제거(SQL Server)Remove an Availability Group (SQL Server)

가용성 데이터베이스 필수 구성 요소 및 제한 사항Availability Database Prerequisites and Restrictions

가용성 그룹에 추가하기에 적합한 데이터베이스는 다음 필수 구성 요소 및 제한 사항을 충족해야 합니다.To be eligible to be added to an availability group, a database must meet the following prerequisites and restrictions.

섹션 내용In This Section:

검사 목록: 요구 사항(가용성 데이터베이스)Checklist: Requirements (Availability Databases)

가용성 그룹에 추가하기에 적합한 데이터베이스는 다음 조건을 충족해야 합니다.To be eligible to be added to an availability group, a database must:

요구 사항Requirements 링크Link
사용자 데이터베이스여야 합니다.Be a user database. 시스템 데이터베이스는 가용성 그룹에 포함될 수 없습니다.System databases cannot belong to an availability group.
가용성 그룹을 만들려고 하며 서버 인스턴스에서 액세스할 수 있는 SQL ServerSQL Server 인스턴스에 있어야 합니다.Reside on the instance of SQL ServerSQL Server where you create the availability group and be accessible to the server instance.
읽기/쓰기 데이터베이스여야 합니다.Be a read-write database. 읽기 전용 데이터베이스는 가용성 그룹에 추가할 수 없습니다.Read-only databases cannot be added to an availability group. sys.databases (is_read_only = 0)sys.databases (is_read_only = 0)
다중 사용자 데이터베이스여야 합니다.Be a multi-user database. sys.databases (user_access = 0)sys.databases (user_access = 0)
AUTO_CLOSE를 사용하면 안 됩니다.Not use AUTO_CLOSE. sys.databases (is_auto_close_on = 0)sys.databases (is_auto_close_on = 0)
전체 복구 모델(전체 복구 모드라고도 함)을 사용합니다.Use the full recovery model (also known as, full recovery mode). sys.databases (recovery_model = 1)sys.databases (recovery_model = 1)
전체 데이터베이스 백업을 하나 이상 소유해야 합니다.Possess at least one full database backup.

참고: 데이터베이스를 전체 복구 모드로 설정한 후 전체 복구 로그 체인을 시작하려면 전체 백업이 필요합니다.Note: After setting a database to full recovery mode, a full backup is required to initiate the full-recovery log chain.
전체 데이터베이스 백업 만들기(SQL Server)Create a Full Database Backup (SQL Server)
기존 가용성 그룹에 속하지 않아야 합니다.Not belong to any existing availability group. sys.databases (group_database_id = NULL)sys.databases (group_database_id = NULL)
데이터베이스 미러링용으로 구성되지 않아야 합니다.Not be configured for database mirroring. sys.database_mirroring (데이터베이스가 미러링에 참가하지 않으면 접두사가 "mirroring_"인 모든 열이 NULL입니다.)sys.database_mirroring (If the database does not participate in mirroring, all columns prefixed with "mirroring_" are NULL.)
FILESTREAM을 사용하는 데이터베이스를 가용성 그룹에 추가하려면 먼저 가용성 그룹의 가용성 복제본을 호스팅하거나 호스팅할 모든 서버 인스턴스에서 FILESTREAM을 사용하도록 설정되어 있는지 확인합니다.Before adding a database that uses FILESTREAM to an availability group, ensure that FILESTREAM is enabled on every server instance that hosts or will host an availability replica for the availability group. Enable and Configure FILESTREAMEnable and Configure FILESTREAM
포함된 데이터베이스를 가용성 그룹에 추가하기 전에 가용성 그룹의 가용성 복제본을 호스팅하거나 호스팅할 모든 서버 인스턴스에서 contained database authentication 서버 옵션이 1 로 설정되어 있는지 확인합니다.Before adding a contained database to an availability group, ensure that the contained database authentication server option is set to 1 on every server instance that hosts or will host an availability replica for the availability group. contained database authentication 서버 구성 옵션contained database authentication Server Configuration Option

서버 구성 옵션(SQL Server)Server Configuration Options (SQL Server)

참고

Always On 가용성 그룹Always On availability groups은 지원되는 모든 데이터베이스 호환성 수준에서 작동합니다.works with any supported database compatibility level.

제한 사항(가용성 데이터베이스)Restrictions (Availability Databases)

  • 보조 데이터베이스의 파일 경로(드라이브 문자 포함)와 해당하는 주 데이터베이스의 경로가 다를 경우 다음 제한 사항이 적용됩니다.If the file path (including the drive letter) of a secondary database differs from the path of the corresponding primary database, the following restrictions apply:

    • 새 가용성 그룹 마법사New Availability Group Wizard/가용성 그룹에 데이터베이스 추가 마법사Add Database to Availability Group Wizard: 초기 데이터 동기화 선택 페이지에서 전체 옵션이 지원되지 않습니다.새 가용성 그룹 마법사New Availability Group Wizard/가용성 그룹에 데이터베이스 추가 마법사Add Database to Availability Group Wizard: The Full option is not supported (on theSelect Initial Data Synchronization Page page),

    • RESTORE WITH MOVE: 보조 데이터베이스를 만들려면 보조 복제본을 호스팅하는 각 SQL ServerSQL Server 인스턴스에서 데이터베이스 파일에 대해 RESTORED WITH MOVE를 실행해야 합니다.RESTORE WITH MOVE: To create the secondary databases, the database files must be RESTORED WITH MOVE on each instance of SQL ServerSQL Server that hosts a secondary replica.

    • 파일 추가 작업에 미치는 영향: 보조 데이터베이스에서 보조 복제본에 대한 이후 파일 추가 작업은 실패할 수 있습니다.Impact on add-file operations: A later add-file operation on the primary replica might fail on the secondary databases. 이 오류로 인해 보조 데이터베이스가 일시 중지될 수 있습니다.This failure could cause the secondary databases to be suspended. 이로 인해 보조 복제본이 NOT SYNCHRONIZING 상태가 됩니다.This, in turn, causes the secondary replicas to enter the NOT SYNCHRONIZING state.

      참고

      실패한 파일 추가 작업을 해결하는 방법은 실패한 파일 추가 작업 문제 해결(Always On 가용성 그룹)을 참조하세요.For information about responding to a failed ad-file operation, see Troubleshoot a Failed Add-File Operation (Always On Availability Groups).

  • 현재 가용성 그룹에 속한 데이터베이스는 삭제할 수 없습니다.You cannot drop a database that currently belongs to an availability group.

TDE 데이터베이스 보호를 위한 후속 작업Follow Up for TDE Protected Databases

TDE(투명한 데이터 암호화)를 사용하는 경우 다른 키를 만들고 해독하기 위한 인증서 또는 비대칭 키가 가용성 그룹의 가용성 복제본을 호스팅하는 모든 서버 인스턴스에서 동일해야 합니다.If you use transparent data encryption (TDE), the certificate or asymmetric key for creating and decrypting other keys must be the same on every server instance that hosts an availability replica for the availability group. 자세한 내용은 다른 SQL Server로 TDE 보호 데이터베이스 이동을 참조하세요.For more information, see Move a TDE Protected Database to Another SQL Server.

사용 권한(가용성 데이터베이스)Permissions (Availability Databases)

데이터베이스에 대한 ALTER 권한이 필요합니다.Requires ALTER permission on the database.

TaskTask 아티클Article
보조 데이터베이스 준비(수동)Preparing a secondary database (manually) 가용성 그룹에 대한 보조 데이터베이스 준비(SQL Server)Manually Prepare a Secondary Database for an Availability Group (SQL Server)
가용성 그룹에 보조 데이터베이스 조인(수동)Joining a secondary database to availability group (manually) 가용성 그룹에 보조 데이터베이스 조인(SQL Server)Join a Secondary Database to an Availability Group (SQL Server)
가용성 데이터베이스 개수 수정Modifying the number of availability databases 가용성 그룹에 데이터베이스 추가(SQL Server)Add a Database to an Availability Group (SQL Server)

가용성 그룹에서 보조 데이터베이스 제거(SQL Server)Remove a Secondary Database from an Availability Group (SQL Server)

가용성 그룹에서 주 데이터베이스 제거(SQL Server)Remove a Primary Database from an Availability Group (SQL Server)

참고 항목See Also

Always On 가용성 그룹 개요(SQL Server) Overview of Always On Availability Groups (SQL Server)
장애 조치(failover) 클러스터링 및 Always On 가용성 그룹(SQL Server) Failover Clustering and Always On Availability Groups (SQL Server)
Always On 클라이언트 연결(SQL Server)Always On Client Connectivity (SQL Server)