Always On Linux에서 가용성 그룹Always On Availability Groups on Linux

이 항목 적용 대상: 예(Linux에만 해당) SQL Server없습니다Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스없습니다 병렬 데이터 웨어하우스 THIS TOPIC APPLIES TO: yesSQL Server (Linux only)noAzure SQL DatabasenoAzure SQL Data WarehousenoParallel Data Warehouse

이 문서에서는 Linux 기반에서 Always On 가용성 그룹 (Ag)의 특성을 설명 SQL ServerSQL Server 설치 합니다.This article describes the characteristics of Always On Availability Groups (AGs) under Linux-based SQL ServerSQL Server installations. Linux 및 Windows Server 장애 조치 클러스터 (WSFC) 간의 차이점에 대해서도 설명-Ag를 기반으로 합니다.It also covers differences between Linux- and Windows Server failover cluster (WSFC)-based AGs. 참조는 Windows 기반 설명서 , Ag의 기본 사항에 대 한 역할을 동일한 Windows 및 Linux를 제외 하 고 WSFC에서 수행 합니다.See the Windows-based documentation for the basics of AGs, as they work the same on Windows and Linux except for the WSFC.

가용성 그룹의 상위 수준 관점에서 보면 SQL ServerSQL Server Linux에서와 동일 WSFC 기반으로 하는 구현에는 합니다.From a high-level standpoint, availability groups under SQL ServerSQL Server on Linux are the same as they are on WSFC-based implementations. 모든 제한 사항 및 기능 같음을, 몇 가지 예외가 것입니다.That means that all the limitations and features are the same, with some exceptions. 주요 차이점은 다음과 같습니다.The main differences include:

  • Linux의 Microsoft Distributed Transaction Coordinator (DTC)를 사용할 수 없습니다 SQL Server 2017(14.x)SQL Server 2017 (14.x)합니다.Microsoft Distributed Transaction Coordinator (DTC) is not supported under Linux in SQL Server 2017(14.x)SQL Server 2017 (14.x). 응용 프로그램 분산된 트랜잭션 사용 해야 하는 AG 필요 하는 경우 배포 SQL ServerSQL Server Windows에서 합니다.If your applications require the use of distributed transactions and need an AG, deploy SQL ServerSQL Server on Windows.
  • Linux 기반 배포 대신 WSFC Pacemaker를 사용합니다.Linux-based deployments use Pacemaker instead of a WSFC.
  • 작업 그룹 클러스터 시나리오를 제외 하 고 Windows에서 Ag에 대 한 대부분 구성과 달리 Pacemaker Active Directory 도메인 서비스 (AD DS) 필요가 없습니다.Unlike most configurations for AGs on Windows except for the Workgroup Cluster scenario, Pacemaker never requires Active Directory Domain Services (AD DS).
  • 한 노드에서 다른 AG 실패 하는 방법 Linux와 Windows 간에 차이가 있습니다.How to fail an AG from one node to another is different between Linux and Windows.
  • 와 같은 특정 설정을 required_synchronized_secondaries_to_commit WSFC 기반 설치를 TRANSACT-SQL을 사용 하는 반면 Pacemaker linux를 통해 변경 해야 합니다.Certain settings such as required_synchronized_secondaries_to_commit can only be changed via Pacemaker on Linux, whereas a WSFC-based install uses Transact-SQL.

복제 데이터베이스와 클러스터 노드Number of replicas and cluster nodes

AG에 SQL Server StandardSQL Server Standard 두 총 복제본을 가질 수: 하나의 주 파일 그룹 및 가용성 용도로 사용할 수 있는 보조를 두 개 있습니다.An AG in SQL Server StandardSQL Server Standard can have two total replicas: one primary, and one secondary that can only be used for availability purposes. 읽을 수 있는 쿼리와 같은 다른 작업에 사용할 수 없습니다.It cannot be used for anything else, such as readable queries. 에 AG SQL Server EnterpriseSQL Server Enterprise 총 복제본을 최대 9 개까지 가질 수: 기본 및 최대 3 (주 포함)는 8 개의 보조를 최대 개 하나 동기적 일 수 있습니다.An AG in SQL Server EnterpriseSQL Server Enterprise can have up to nine total replicas: one primary and up to eight secondaries, of which up to three (including the primary) can be synchronous. 기본 클러스터를 사용 하는 경우 있을 수 있습니다는 최대 16 개의 노드로 구성 총 Corosync 관련 된 경우.If using an underlying cluster, there can be a maximum of 16 nodes total when Corosync is involved. 최대 9 개에서 16 개의 노드로 구성 된 가용성 그룹 걸쳐 있을 수 SQL Server EnterpriseSQL Server Enterprise, 2 대와 SQL Server StandardSQL Server Standard합니다.An availability group can span at most nine of the 16 nodes with SQL Server EnterpriseSQL Server Enterprise, and two with SQL Server StandardSQL Server Standard.

자동으로 다른 복제본으로 장애 조치 하는 기능을 필요로 하는 2 복제본 구성을에 설명 된 대로 구성 으로만 이동 가능한 복제본을 사용 해야 구성 전용 복제 및 쿼럼합니다.A two-replica configuration that requires the ability to automatically fail over to another replica requires the use of a configuration-only replica, as described in Configuration-only replica and quorum. 구성 전용 복제에 도입 된 SQL Server 2017(14.x)SQL Server 2017 (14.x) 누적 업데이트 1 (CU1)을 하는이 구성에 배포 된 최소 버전 이어야 합니다.Configuration-only replicas were introduced in SQL Server 2017(14.x)SQL Server 2017 (14.x) Cumulative Update 1 (CU1), so that should be the minimum version deployed for this configuration.

Pacemaker 사용 되는 경우 올바르게 구성 해야 실행 중 상태로 유지 됩니다.If Pacemaker is used, it must be properly configured so it remains up and running. 즉,는 쿼럼 및 STONITH 해야 적절 하 게 구현 사항이 추가 Pacemaker 관점에서 볼 때 SQL ServerSQL Server 구성 전용 복제 등의 요구 사항을 합니다.That means that quorum and STONITH must be implemented properly from a Pacemaker perspective, in addition to any SQL ServerSQL Server requirements such as a configuration-only replica.

읽기 가능한 보조 복제본 에서만 지원 됩니다 SQL Server EnterpriseSQL Server Enterprise합니다.Readable secondary replicas are only supported with SQL Server EnterpriseSQL Server Enterprise.

클러스터 유형 및 장애 조치 모드Cluster type and failover mode

처음 SQL Server 2017(14.x)SQL Server 2017 (14.x) Ag에 대 한 점 클러스터 유형입니다.New to SQL Server 2017(14.x)SQL Server 2017 (14.x) is the introduction of a cluster type for AGs. Linux 용은 두 개의 올바른 값: 외부 및 없음입니다.For Linux, there are two valid values: External and None. 클러스터 유형의 외부 Pacemaker AG 아래 사용 됨을 의미 합니다.A cluster type of External means that Pacemaker will be used underneath the AG. 클러스터 유형 장애 조치 모드도 외부로 설정할 수에 대해 외부를 사용 하 여 (에서 새로 SQL Server 2017(14.x)SQL Server 2017 (14.x)).Using External for cluster type requires that the failover mode be set to External as well (also new in SQL Server 2017(14.x)SQL Server 2017 (14.x)). 자동 장애 조치가 지원 되지만 달리는 WSFC 장애 조치 모드가 설정 되어 외부, 자동이 아님 Pacemaker 사용 되는 경우.Automatic failover is supported, but unlike a WSFC, failover mode is set to External, not automatic, when Pacemaker is used. WSFC, 달리 AG의 Pacemaker 부분 AG 구성 된 후 생성 됩니다.Unlike a WSFC, the Pacemaker portion of the AG is created after the AG is configured.

None 클러스터 유형에 대 한 요구 사항은 없습니다 또는 AG ´ ֲ, Pacemaker 의미 합니다.A cluster type of None means that there is no requirement for, nor will the AG use, Pacemaker. Pacemaker 구성 서버에도 AG이 none 인 클러스터 유형으로 구성 된 Pacemaker 됩니다 참조 하거나 관리 하지 않으므로 해당 AG 합니다.Even on servers that have Pacemaker configured, if an AG is configured with a cluster type of None, Pacemaker will not see or manage that AG. None 클러스터 종류는 보조 복제본에 주에서 수동 장애 조치만 지원합니다.A cluster type of None only supports manual failover from a primary to a secondary replica. None을 사용 하 여 만든 AG는 주로 읽기-확장 시나리오 뿐 아니라 업그레이드에 대 한 대상 합니다.An AG created with None is primarily targeted for the read-scale out scenario as well as upgrades. 자동 장애 조치가 필요한 인 로컬 가용성 또는 재해 복구와 같은 시나리오에서 작동할 수 하는 동안 권장 되지 않습니다.While it can work in scenarios like disaster recovery or local availability where no automatic failover is necessary, it is not recommended. 수신기 스토리 Pacemaker 하지 않고 보다 복잡 한 이기도합니다.The listener story is also more complex without Pacemaker.

클러스터 유형에 저장 됩니다는 SQL ServerSQL Server 동적 관리 뷰 (DMV) sys.availability_groups, 열에 cluster_typecluster_type_desc합니다.Cluster type is stored in the SQL ServerSQL Server dynamic management view (DMV) sys.availability_groups, in the columns cluster_type and cluster_type_desc.

필수_동기화_보조_를_커밋required_synchronized_secondaries_to_commit

처음 SQL Server 2017(14.x)SQL Server 2017 (14.x) Ag 호출에서 사용 되는 설정은 required_synchronized_secondaries_to_commit합니다.New to SQL Server 2017(14.x)SQL Server 2017 (14.x) is a setting that is used by AGs called required_synchronized_secondaries_to_commit. 이렇게 하면 AG 주와 록스텝에 있어야 하는 보조 복제본의 수입니다.This tells the AG the number of secondary replicas that must be in lockstep with the primary. 자동 장애 조치 (경우에 외부 클러스터 유형 Pacemaker와 통합 됨), 같은 있으며 온라인 또는 오프 라인 보조 복제본의 수는 경우 주 가용성 등의 동작을 제어 합니다.This enables things like automatic failover (only when integrated with Pacemaker with a cluster type of External), and controls the behavior of things like the availability of the primary if the right number of secondary replicas is either online or offline. 이 과정에 대 한 자세한을 이해 하려면 참조 가용성 그룹 구성에 대 한 높은 가용성 및 데이터 보호합니다.To understand more about how this works, see High availability and data protection for availability group configurations. required_synchronized_secondaries_to_commit 값은 기본적으로 설정 되 고 Pacemaker에서 유지 관리 / SQL ServerSQL Server합니다.The required_synchronized_secondaries_to_commit value is set by default and maintained by Pacemaker/ SQL ServerSQL Server. 이 값을 직접 재정의할 수 있습니다.You can manually override this value.

조합의 required_synchronized_secondaries_to_commit 새 시퀀스 번호 (에 저장 되어 sys.availability_groups) Pacemaker 알립니다 및 SQL ServerSQL Server , 예를 들어 자동 장애 조치가 발생할 수 있습니다.The combination of required_synchronized_secondaries_to_commit and the new sequence number (which is stored in sys.availability_groups) informs Pacemaker and SQL ServerSQL Server that, for example, automatic failover can happen. 이 경우 보조 복제본에 시퀀스 번호가 같은 기본 최신 모든 구성 정보가 최신 상태로 않음 것입니다.In that case, a secondary replica would have the same sequence number as the primary, meaning it is up to date with all the latest configuration information.

에 대해 설정할 수 있는 값이 세 가지 required_synchronized_secondaries_to_commit: 0, 1 또는 2입니다.There are three values that can be set for required_synchronized_secondaries_to_commit: 0, 1, or 2. 복제 데이터베이스를 사용할 수 없게 하는 경우의 동작을 제어 합니다.They control the behavior of what happens when a replica becomes unavailable. 숫자 주와 동기화 해야 하는 보조 복제본의 수를 나타냅니다.The numbers correspond to the number of secondary replicas that must be synchronized with the primary. Linux의 동작은 다음과 같습니다.The behavior is as follows under Linux:

  • 0 – 보조 복제본이 없는 동기화 할 필요 하기 때문 없는 자동 장애 조치가 가능 합니다.0 – No automatic failover is possible since no secondary replica is required to be synchronized. 주 데이터베이스를 항상 사용할 수 있습니다.The primary database is available at all times.
  • 1 – 하나의 보조 복제본이 주;와 동기화 된 상태에서 여야 합니다. 자동 장애 조치가 가능 합니다.1 – One secondary replica must be in a synchronized state with the primary; automatic failover is possible. 동기 보조 복제본 사용 가능할 때까지 주 데이터베이스를 사용할 수 없는 경우The primary database is unavailable until a secondary synchronous replica is available.
  • 2-3 개 이상의 노드 AG 구성의 두 보조 복제본을 주;와 동기화 되어야 합니다. 자동 장애 조치가 가능 합니다.2 – Both secondary replicas in a three or more node AG configuration must be synchronized with the primary; automatic failover is possible.

required_synchronized_secondaries_to_commit 뿐만 아니라 데이터 손실을 동기 복제본으로 장애 조치의 동작을 제어 합니다.required_synchronized_secondaries_to_commit controls not only the behavior of failovers with synchronous replicas, but data loss. 1 또는 2의 값으로 보조 복제본은 항상 동기화 할 필요 이므로 데이터 중복 됩니다.With a value of 1 or 2, a secondary replica is always required to be synchronized, so there will always be data redundancy. 즉, 데이터가 손실 되지 않습니다.That means no data loss.

값을 변경 하려면 required_synchronized_secondaries_to_commit, 다음 구문을 사용 합니다.To change the value of required_synchronized_secondaries_to_commit, use the following syntax:

참고

값을 변경 하면 일시적인 가동 중지 의미를 다시 시작 하려면 리소스를 하면 됩니다.Changing the value causes the resource to restart, meaning a brief outage. 이 문제를 방지 하는 유일한 방법은 리소스를 관리 하지는 클러스터에 의해 일시적으로 설정 하는 합니다.The only way to avoid this is to set the resource to not be managed by the cluster temporarily.

Red Hat Enterprise Linux (RHEL) 및 UbuntuRed Hat Enterprise Linux (RHEL) and Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>

SUSE Linux Enterprise Server(SLES)SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

여기서 AGResourceName AG에 대해 구성 된 리소스의 이름 및 0, 1 또는 2가 있습니다.where AGResourceName is the name of the resource configured for the AG, and Value is 0, 1, or 2. 매개 변수를 관리 하는 Pacemaker 기본값으로 다시 설정, 값이 없는 동일한 문을 실행 합니다.To set it back to the default of Pacemaker managing the parameter, execute the same statement with no value.

다음 조건이 충족 되 면 AG의 자동 장애 조치 된 있습니다.Automatic failover of an AG is possible when the following conditions are met:

  • 주 복제본과 보조 복제본은 동기 데이터 이동으로 설정 됩니다.The primary and the secondary replica are set to synchronous data movement.
  • 보조 동기화 (동기화 하지 않는) 동일한 데이터 요소에서 두 가지 의미의 상태를 있습니다.The secondary has a state of synchronized (not synchronizing), meaning the two are at the same data point.
  • 클러스터 유형 외부로 설정 됩니다.The cluster type is set to External. 자동 장애 조치 none 클러스터 유형 수는 없습니다.Automatic failover is not possible with a cluster type of None.
  • sequence_number 되도록 보조 복제본의 주에 시퀀스 번호가 가장 높은 – 즉, 보조 복제본의 sequence_number 원래 주 복제본에서 것과 일치 합니다.The sequence_number of the secondary replica to become the primary has the highest sequence number – in other words, the secondary replica’s sequence_number matches the one from the original primary replica.

이러한 조건이 충족 될 경우 주 복제본을 호스팅하는 서버 오류가 발생 하면 AG 동기 복제본 소유권을 변경 됩니다.If these conditions are met and the server hosting the primary replica fails, the AG will change ownership to a synchronous replica. 동기 복제본에 대 한 동작 (있는 있을 수 3의 총: 하나의 주 파일 그룹 및 두 개의 보조 복제본)를 통해 추가로 제어할 수 required_synchronized_secondaries_to_commit합니다.The behavior for synchronous replicas (of which there can be three total: one primary and two secondary replicas) can further be controlled by required_synchronized_secondaries_to_commit. 이 Windows와 Linux 모두에서 Ag와 작동 하지만 완전히 다른 방식으로 구성 됩니다.This works with AGs on both Windows and Linux, but is configured completely differently. Linux에서 값 자체 AG 리소스에서 클러스터에 의해 자동으로 구성 됩니다.On Linux, the value is configured automatically by the cluster on the AG resource itself.

구성 가능한 및 쿼럼Configuration-only replica and quorum

새로 SQL Server 2017(14.x)SQL Server 2017 (14.x) c u 1을 기준으로 구성 으로만 이동 가능한 복제본입니다.Also new in SQL Server 2017(14.x)SQL Server 2017 (14.x) as of CU1 is a configuration-only replica. Pacemaker WSFC 다르기 때문에 쿼럼 및 STONITH를 요구 하는 경우에 특히 더 2 노드 구성을 방금 작동 하지 않습니다 AG에 관한.Because Pacemaker is different than a WSFC, especially when it comes to quorum and requiring STONITH, having just a two-node configuration will not work when it comes to an AG. FCI에 대 한 클러스터 계층에서 발생 하는 모든 FCI 장애 조치 중재 하기 때문에 Pacemaker에서 제공 하는 쿼럼 메커니즘 괜찮아 수 있습니다.For an FCI, the quorum mechanisms provided by Pacemaker can be fine, because all FCI failover arbitration happens at the cluster layer. AG에 대 한 linux 중재에서 발생 SQL ServerSQL Server를 모든 메타 데이터가 저장 됩니다.For an AG, arbitration under Linux happens in SQL ServerSQL Server, where all the metadata is stored. 구성 전용 복제에 발생 하는 위치입니다.This is where the configuration-only replica comes into play.

다른 항목 없이 세 번째 노드 및 동기화 된 복제본이 하나 이상 필요한 것입니다.Without anything else, a third node and at least one synchronized replica would be required. 이 작동 하지 않는 SQL Server StandardSQL Server Standard이므로 두 개의 복제본 AG의 참여를 하나만 사용할 수 있습니다.This would not work for SQL Server StandardSQL Server Standard, since it can only have two replicas participating in an AG. 구성 전용 복제본 AG 구성의 다른 복제본과 동일 master 데이터베이스에서 AG 구성을 저장합니다.The configuration-only replica stores the AG configuration in the master database, same as the other replicas in the AG configuration. 구성 전용 복제본 AG에 참여 하는 사용자 데이터베이스는 수 없습니다.The configuration-only replica does not have the user databases participating in the AG. 구성 데이터는 주 데이터베이스에서 동기적으로 전송 됩니다.The configuration data is sent synchronously from the primary. 이 구성 데이터가 든 상관 없이 자동 또는 수동 장애 조치 하는 동안 사용 됩니다.This configuration data is then used during failovers, whether they are automatic or manual.

쿼럼을 유지 관리 하 고 외부의 클러스터 유형 자동 장애 조치를 사용 하도록 설정 하려면 AG, 하거나 다음 조건을 충족 해야 합니다.For an AG to maintain quorum and enable automatic failovers with a cluster type of External, it either must:

  • 동기 복제본이 3 개 포함 ( SQL Server EnterpriseSQL Server Enterprise 만); 또는Have three synchronous replicas ( SQL Server EnterpriseSQL Server Enterprise only); or
  • 두 개의 복제본 (주 및 보조) 뿐 아니라 구성 유일한 복제본을 포함 합니다.Have two replicas (primary and secondary) as well as a configuration only replica.

외부 사용 하는지에 관계 없이 수동 장애 조치가 발생할 수 있습니다 또는 None 클러스터 AG 구성에 대 한 종류입니다.Manual failovers can happen whether using External or None cluster types for AG configurations. None 클러스터 형식을 갖는 AG와 구성 전용 복제본을 구성할 수 있지만는 것, 배포로 인해 복잡 하기 때문입니다.While a configuration-only replica can be configured with an AG that has a cluster type of None, it is not recommended, since it complicates the deployment. 해당 구성에 대해 수동으로 수정 required_synchronized_secondaries_to_commit 하나 이상의 동기화 복제본이 있도록 값이 1 이상 있어야 합니다.For those configurations, manually modify required_synchronized_secondaries_to_commit to have a value of at least 1, so that there is at least one synchronized replica.

구성 전용 복제본의 모든 버전에서 호스팅될 수 SQL ServerSQL Server를 포함 하 여 SQL Server ExpressSQL Server Express합니다.A configuration-only replica can be hosted on any edition of SQL ServerSQL Server, including SQL Server ExpressSQL Server Express. 따라서 라이선스 비용 최소화을 Ag에서 함께 작동 SQL Server StandardSQL Server Standard합니다.This will minimize licensing costs and ensures it works with AGs in SQL Server StandardSQL Server Standard. 즉, 세 번째 서버에 대 한 최소 사양을 충족 해야 방금 필요 함을 SQL ServerSQL Server이므로 AG에 대 한 사용자 트랜잭션 트래픽을 받고 있지 않습니다.This means that the third required server just needs to meet the minimum specification for SQL ServerSQL Server, since it is not receiving user transaction traffic for the AG.

구성 전용 복제를 사용 하면 다음과 같은 동작이 있습니다.When a configuration-only replica is used, it has the following behavior:

  • 기본적으로 required_synchronized_secondaries_to_commit 0으로 설정 됩니다.By default, required_synchronized_secondaries_to_commit is set to 0. 이 수정할 수 있습니다 수동으로 1에 필요 합니다.This can be manually modified to 1 if desired.
  • 기본 실패 하는 경우 및 required_synchronized_secondaries_to_commit 은 0, 보조 복제본은 새로운 주 해 져 서 읽기 및 쓰기 모두에 사용할 수 있습니다.If the primary fails and required_synchronized_secondaries_to_commit is 0, the secondary replica will become the new primary and be available for both reading and writing. 값이 1 이면 자동 장애 조치가 발생 하지만 다른 복제본이 온라인 상태가 될 때까지 새 트랜잭션을 허용 하지 않습니다.If the value is 1, automatic failover will occur, but will not accept new transactions until the other replica is online.
  • 보조 복제본이 실패 하는 경우 및 required_synchronized_secondaries_to_commit 0, 주 복제본에는 여전히 트랜잭션을, 허용 있지만 (수동 또는 자동) 데이터 또는 가능한 장애 조치에 대 한 보호는이 시점에서 주에 실패 하면 보조 복제본을 사용할 수 없기 때문입니다.If a secondary replica fails and required_synchronized_secondaries_to_commit is 0, the primary replica still accepts transactions, but if the primary fails at this point, there is no protection for the data nor failover possible (manual or automatic), since a secondary replica is not available.
  • 구성 전용 복제에 실패 하면 AG는 정상적으로 작동 하지만 자동 장애 조치가 가능 합니다.If the configuration-only replicas fails, the AG will function normally, but no automatic failover is possible.
  • 기본 트랜잭션 받아들일 수 없습니다 및 장소가 동기 보조 복제본과 구성 으로만 이동 가능한 복제본이 모두 실패 하지 않아야 기본에 대 한 합니다.If both a synchronous secondary replica and the configuration-only replica fail, the primary cannot accept transactions, and there is nowhere for the primary to fail to.

C u 1에서 알려진된 버그가 있습니다를 통해 생성 되는 corosync.log 파일에 로깅에서 mssql-server-ha합니다.In CU1 there is a known bug in the logging in the corosync.log file that is generated via mssql-server-ha. 현재 메시지 있다고 "1 시퀀스 번호를 받을 것으로 예상 하지만 수신만 2 보조 복제본에 사용할 수 있는 필수 복제본 수에 따라 기본 수 없는 경우.If a secondary replica is not able to become the primary due to the number of required replicas available, the current message says "Expected to receive 1 sequence numbers but only received 2. 부족 합니다. 복제본은 온라인으로 안전 하 게 로컬 복제본을 승격 합니다. "Not enough replicas are online to safely promote the local replica." 숫자가 반대로 바꿈을, 및 "2 시퀀스 번호를 수신 하려고 하는데만 1을 받았습니다이 필드.The numbers should be reversed, and it should say "Expected to receive 2 sequence numbers but only received 1. 부족 합니다. 복제본은 온라인으로 안전 하 게 로컬 복제본을 승격 합니다. "Not enough replicas are online to safely promote the local replica."

여러 가용성 그룹Multiple availability groups

둘 이상의 AG Pacemaker 클러스터 또는 서버 집합을 만들 수 있습니다.More than one AG can be created per Pacemaker cluster or set of servers. 시스템 리소스입니다.The only limitation is system resources. AG 소유권 마스터도 표시 됩니다.AG ownership is shown by the master. 다른 Ag 서로 다른 노드에; 소유할 수 있습니다. 일부 필요가 동일한 노드에서 실행 중 이어야 합니다.Different AGs can be owned by different nodes; they do not all need to be running on the same node.

데이터베이스에 대 한 드라이브 및 폴더 위치Drive and folder location for databases

AG에 참여 하는 사용자 데이터베이스에 대 한 드라이브 및 폴더 구조는 Windows 기반 Ag에서와 동일 해야 합니다.As on Windows-based AGs, the drive and folder structure for the user databases participating in an AG should be identical. 예를 들어, 사용자 데이터베이스는 /var/opt/mssql/userdata 서버 A에서 Server B에서은 같은 폴더 있어야 유일한 예외는 섹션에서 설명한 Windows 기반 가용성 그룹 및 복제본과의 상호 운용성합니다.For example, if the user databases are in /var/opt/mssql/userdata on Server A, that same folder should exist on Server B. The only exception to this is noted in the section Interoperability with Windows-based availability groups and replicas.

Linux 수신기The listener under Linux

수신기가 AG에 대 한 선택적 기능입니다.The listener is optional functionality for an AG. 응용 프로그램 및 최종 사용자가 데이터를 호스팅하는 서버에 알아야 않아도 있도록 모든 연결 (읽기/쓰기 주 복제본 및/또는 읽기 전용 보조 복제본)에 대 한 항목의 단일 지점을 제공 합니다.It provides a single point of entry for all connections (read/write to the primary replica and/or read-only to secondary replicas) so that applications and end users do not need to know which server is hosting the data. WSFC에서 DNS 뿐 아니라 네트워크 이름 리소스와 다음 AD DS (필요한 경우)에 등록 되어 있는 IP 리소스의 조합입니다.In a WSFC, this is the combination of a network name resource and an IP resource, which is then registered in AD DS (if needed) as well as DNS. AG 리소스 자체와 함께, 해당 추상화를 제공합니다.In combination with the AG resource itself, it provides that abstraction. 수신기에 대 한 자세한 내용은 참조 하십시오. 수신기, 클라이언트 연결 및 응용 프로그램 장애 조치합니다.For more information on a listener, see Listeners, Client Connectivity, and Application Failover.

Linux 수신기가 다르게 구성 되어 있지만 해당 기능은 동일 합니다.The listener under Linux is configured differently, but its functionality is the same. Pacemaker에서 네트워크 이름 리소스의 개념이 없습니다 또는 AD DS;에 생성 하는 개체 노드 중 하나에서 실행할 수 있는 Pacemaker에서 만든 IP 주소 리소스만 있습니다.There is no concept of a network name resource in Pacemaker, nor is an object created in AD DS; there is just an IP address resource created in Pacemaker that can run on any of the nodes. "이름"으로 DNS에서 수신기에 대 한 IP 리소스와 관련 된 항목을 만들어야 합니다.An entry associated with the IP resource for the listener in DNS with a “friendly name” needs to be created. 수신기 IP 리소스는만 해당 가용성 그룹에 대 한 주 복제본을 호스팅하는 서버에서 활성화 됩니다.The IP resource for the listener will only be active on the server hosting the primary replica for that availability group.

Pacemaker을 사용 하는 경우 수신기와 연결 된 IP 주소 리소스 만들어집니다 됩니다 일시적인 가동 중지 한 서버에서 중지 하 고 다른에서 시작 하는 IP 주소 처럼 자동 또는 수동 장애 조치 인지 합니다.If Pacemaker is used and an IP address resource is created that is associated with the listener, there will be a brief outage as the IP address stops on the one server and starts on the other, whether it is automatic or manual failover. 단일 이름 및 IP 주소 조합 하 여 추상화를 제공이 중단을 마스킹하지 않습니다.While this provides abstraction through the combination of a single name and IP address, it does not mask the outage. 응용 프로그램은 어떤 종류의 기능이를 감지 하 여 다시 연결 하 여 연결 해제를 처리할 수 있어야 합니다.An application must be able to handle the disconnect by having some sort of functionality to detect this and reconnect.

그러나 DNS 이름 및 IP 주소는 여전히 부족 합니다. 보조 복제본에 대 한 읽기 전용 라우팅 등 WSFC에 수신기를 제공 하는 모든 기능을 제공 합니다.However, the combination of the DNS name and IP address is still not enough to provide all the functionality that a listener on a WSFC provides, such as read-only routing for secondary replicas. AG를 구성할 때 "수신기"는 여전히에서 구성할 수을 해야 SQL ServerSQL Server합니다.When configuring an AG, a “listener” still needs to be configured in SQL ServerSQL Server. 마법사 뿐만 아니라 TRANSACT-SQL 구문에서이 볼 수 있습니다.This can be seen in the wizard as well as the Transact-SQL syntax. 두 가지 방법으로 Windows에서와 동일 하 게 작동 하도록 구성할 수 있습니다.There are two ways that this can be configured to function the same as on Windows:

  • 만든 "수신기"와 연결 된 IP 주소가 외부 클러스터 유형 AG에 대 한 SQL ServerSQL Server Pacemaker에서 만들어진 리소스의 IP 주소 여야 합니다.For an AG with a cluster type of External, the IP address associated with the “listener” created in SQL ServerSQL Server should be the IP address of the resource created in Pacemaker.
  • None 클러스터 종류를 사용 하 여 만든 AG에 대 한 주 복제본과 연결 된 IP 주소를 사용 합니다.For an AG created with a cluster type of None, use the IP address associated with the primary replica.

그런 다음 제공 된 IP 주소와 연결 된 인스턴스가 응용 프로그램의 읽기 전용 라우팅 요청 등을 위한 코디네이터 됩니다.The instance associated with the provided IP address then becomes the coordinator for things like the read-only routing requests from applications.

Windows 기반 가용성 그룹 및 복제본과의 상호 운용성Interoperability with Windows-based availability groups and replicas

외부 웹 서비스 또는 WSFC 즉의 클러스터 형식을 갖는 AG 플랫폼 크로스 해당 복제본을 가질 수 없습니다.An AG that has a cluster type of External or one that is WSFC cannot have its replicas cross platforms. 이러한 사항은 AG 인지 SQL Server StandardSQL Server Standard 또는 SQL Server EnterpriseSQL Server Enterprise합니다.This is true whether the AG is SQL Server StandardSQL Server Standard or SQL Server EnterpriseSQL Server Enterprise. 기본 클러스터와 기존의 AG 구성에서 즉, 하나의 복제본 WSFC 오류 코드 및 기타 Pacemaker와 linux에 있을 수 없습니다.That means in a traditional AG configuration with an underlying cluster, one replica cannot be on a WSFC and the other on Linux with Pacemaker.

None 클러스터 유형 AG의 복제본이 있으므로 동일한 AG의 Linux 및 Windows 기반 복제본을 모두 수 OS 경계를 교차를 가질 수 있습니다.An AG with a cluster type of NONE can have its replicas cross OS boundaries, so there could be both Linux- and Windows-based replicas in the same AG. 예로 여기서 주 복제본은 Windows 기반 보조 Linux 배포판 중 하나에 다음과 같습니다.An example is shown here where the primary replica is Windows-based, while the secondary is on one of the Linux distributions.

하이브리드 없음

분산된 AG OS 경계를 넘을 수 수도 있습니다.A distributed AG can also cross OS boundaries. 기본 Ag 구성 방법, 예: 외부 되 고 사용 하 여 구성에 대 한 규칙에 의해 바인딩된 Linux 전용 이지만 AG에 가입 된 WSFC를 사용 하 여 구성할 수 없습니다.The underlying AGs are bound by the rules for how they are configured, such as one configured with External being Linux-only, but the AG that it is joined to could be configured using a WSFC. 다음 예를 살펴 보십시오.Consider the following example:

하이브리드 Dist AG

다음 단계Next steps

Linux에서 SQL Server에 대 한 가용성 그룹을 구성 합니다.Configure availability group for SQL Server on Linux

Linux에서 SQL Server에 대 한 읽기 확장성이 가용성 그룹을 구성 합니다.Configure read-scale availability group for SQL Server on Linux

RHEL에서 가용성 그룹 클러스터 리소스를 추가 합니다.Add availability group Cluster Resource on RHEL

SLES에 가용성 그룹 클러스터 리소스를 추가 합니다.Add availability group Cluster Resource on SLES

Ubuntu 가용성 그룹 클러스터 리소스를 추가 합니다.Add availability group Cluster Resource on Ubuntu

플랫폼 간 가용성 그룹 구성Configure a cross-platform availability group