Linux에서 고가용성을 위한 SQL Server Always On 가용성 그룹 구성
적용 대상:
SQL Server - Linux
이 문서에서는 Linux에서 고가용성을 위해 SQL Server Always On AG(가용성 그룹)를 만드는 방법을 설명합니다. AG의 구성 유형에는 두 가지가 있습니다. ‘고가용성’ 구성은 클러스터관리자를 사용하여 비즈니스 연속성을 제공합니다. 이 구성에는 읽기 확장 복제본도 포함될 수 있습니다. 이 문서에서는 고가용성을 위한 AG를 만드는 방법을 설명합니다.
클러스터 관리자 없이 ‘읽기 확장’을 위한 AG를 만들 수도 있습니다. 읽기 확장용 AG는 성능 확장에 대한 읽기 전용 복제본(replica) 제공합니다. 고가용성을 제공하지 않습니다. 읽기 확장을 위한 AG를 만들려면 Linux에서 읽기 확장을 위한 SQL Server 가용성 그룹 구성을 참조하세요.
고가용성 및 데이터 보호를 보장하는 구성에는 두 개 또는 세 개의 동기 커밋 복제본이 필요합니다. 3개의 동기 복제본(replica) 사용하면 한 서버를 사용할 수 없더라도 AG가 자동으로 복구할 수 있습니다. 자세한 내용은 가용성 그룹 구성에 대한 고가용성 및 데이터 보호를 참조 하세요.
모든 서버는 물리적 서버 또는 가상 서버여야 하며, 가상 서버는 동일한 가상화 플랫폼에 있어야 합니다. 이 요구 사항은 펜싱 에이전트가 플랫폼별로 지정되기 때문입니다. 게스트 클러스터 정책을 참조하세요.
로드맵
Linux 서버에서 고가용성을 위한 AG를 만드는 단계는 Windows Server 장애 조치(failover) 클러스터의 단계와 다릅니다. 다음 목록에서는 개괄적인 단계를 설명합니다.
SQL Server on Linux에 대한 설치 지침입니다.
Important
Linux 고가용성은 펜싱 에이전트를 사용하여 서버의 리소스를 격리하기 때문에 AG에 포함된 세 개의 서버가 모두 동일한 플랫폼(물리적 또는 가상)에 있어야 합니다. 펜싱 에이전트는 플랫폼별로 지정됩니다.
AG를 만듭니다. 이 단계는 현재 문서에서 설명합니다.
Pacemaker와 같은 클러스터 리소스 관리자를 구성합니다.
클러스터 리소스 관리자를 구성하는 방법은 특정 Linux 배포에 따라 다릅니다. 배포 관련 지침은 다음 링크를 참조하세요.
Important
프로덕션 환경에는 고가용성을 위해 펜싱 에이전트가 필요합니다. 이 문서의 예제에서는 펜싱 에이전트를 사용하지 않습니다. 예제는 테스트 및 유효성 검사를 위해서만 제공됩니다.
Pacemaker 클러스터는 펜싱을 사용하여 클러스터를 알려진 상태로 되돌립니다. 펜싱을 구성하는 방법은 배포 및 환경에 따라 달라집니다. 현재 펜싱은 일부 클라우드 환경에서 사용할 수 없습니다. 자세한 내용은 RHEL 고가용성 클러스터의 지원 정책 - 가상화 플랫폼을 참조하세요.
SLES의 경우 SUSE Linux Enterprise 고가용성 확장을 참조하세요.
클러스터에 AG를 리소스로 추가합니다.
클러스터에 AG를 리소스로 추가하는 방법은 Linux 배포에 따라 다릅니다. 배포 관련 지침은 다음 링크를 참조하세요.
여러 NIC(네트워크 인터페이스)에 대한 고려 사항
여러 NIC가 있는 서버에 대한 가용성 그룹을 설정하는 방법에 대한 내용은 다음 관련 섹션을 참조하세요.
필수 구성 요소
가용성 그룹을 만들려면 먼저 다음을 수행해야 합니다.
- 가용성 복제본을 호스트하는 모든 서버가 통신할 수 있도록 환경을 설정합니다.
- SQL Server를 설치합니다.
참고
Linux에서는 가용성 그룹을 먼저 만들어야만 클러스터에서 관리할 클러스터 리소스로 추가할 수 있습니다. 이 문서에는 가용성 그룹을 만드는 예제가 나옵니다. 클러스터를 만들고 가용성 그룹을 클러스터 리소스로 추가하는 배포 관련 지침은 “다음 단계”에 있는 링크를 참조하세요.
각 호스트의 컴퓨터 이름을 업데이트합니다.
각 SQL Server 이름은 다음과 같아야 합니다.
- 15자 이하입니다.
- 네트워크 내에서 고유합니다.
컴퓨터 이름을 설정하려면
/etc/hostname을 편집합니다. 다음 스크립트에서는 vi를 사용하여/etc/hostname을 편집할 수 있습니다.sudo vi /etc/hostnamehosts 파일을 구성합니다.
참고
호스트 이름이 DNS 서버에 해당 IP 주소로 등록된 경우 다음 단계를 수행할 필요가 없습니다. 가용성 그룹 구성의 일부로 사용할 모든 노드가 서로 통신할 수 있는지 확인합니다. 호스트 이름에 대한 ping은 해당 IP 주소를 사용하여 응답해야 합니다. 또한
/etc/hosts파일에 localhost IP 주소 127.0.0.1을 노드의 호스트 이름에 매핑하는 레코드가 포함되지 않아야 합니다.모든 서버의 호스트 파일에는 가용성 그룹에 참여할 모든 서버의 IP 주소 및 이름이 포함됩니다.
다음 명령은 현재 서버의 IP 주소를 반환합니다.
sudo ip addr show/etc/hosts를 업데이트합니다. 다음 스크립트에서는 vi를 사용하여/etc/hosts를 편집할 수 있습니다.sudo vi /etc/hosts다음 예제에서는
node1,node2및node3에 대한 항목이 추가된node1의/etc/hosts를 보여 줍니다. 이 샘플에서node1은 주 복제본을 호스트하는 서버를 나타내고,node2및node3은 보조 복제본을 호스트하는 서버를 나타냅니다.127.0.0.1 localhost localhost4 localhost4.localdomain4 ::1 localhost localhost6 localhost6.localdomain6 10.128.18.12 node1 10.128.16.77 node2 10.128.15.33 node3
SQL Server 설치
SQL Server를 설치합니다. 다음 링크는 다양한 배포에 대한 SQL Server 설치 지침으로 연결됩니다.
Always On 가용성 그룹 사용
SQL Server 인스턴스를 호스트하는 각 노드에서 Always On 가용성 그룹을 사용하도록 설정한 다음, mssql-server를 다시 시작합니다. 다음 스크립트를 실행합니다.
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server
AlwaysOn_health 이벤트 세션을 사용하도록 설정
필요에 따라 XE(확장 이벤트)를 사용하도록 설정하면 가용성 그룹 문제를 해결할 때 근본 원인 진단에 도움이 될 수 있습니다. SQL Server의 각 인스턴스에서 다음 명령을 실행합니다.
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO
이 XE 세션에 대한 자세한 내용은 Always On 가용성 그룹에 대한 확장 이벤트 구성을 참조하세요.
인증서 만들기
Linux의 SQL Server 서비스는 인증서를 사용하여 미러링 엔드포인트 간의 통신을 인증합니다.
다음 Transact-SQL 스크립트는 마스터 키와 인증서를 만듭니다. 그런 다음, 인증서를 백업하고 프라이빗 키로 파일을 보호합니다. 강력한 암호로 스크립트를 업데이트합니다. 기본 SQL Server 인스턴스에 연결합니다. 인증서를 만들려면 다음 Transact-SQL 스크립트를 실행합니다.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate
TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (
FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
ENCRYPTION BY PASSWORD = '**<Private_Key_Password>**'
);
이제 기본 SQL Server 복제본은 /var/opt/mssql/data/dbm_certificate.cer에 인증서, var/opt/mssql/data/dbm_certificate.pvk에 프라이빗 키가 있습니다. 이러한 두 파일을 가용성 복제본을 호스트할 모든 서버의 동일한 위치로 복사합니다. mssql 사용자를 사용하거나 mssql 사용자에게 이러한 파일에 액세스할 수 있는 권한을 부여합니다.
예를 들어 원본 서버에서 다음 명령은 파일을 대상 컴퓨터에 복사합니다. **<node2>** 값을 복제본을 호스트할 SQL Server 인스턴스의 이름으로 바꿉니다.
cd /var/opt/mssql/data
scp dbm_certificate.* root@**<node2>**:/var/opt/mssql/data/
각 대상 서버에서 mssql 사용자에게 인증서에 액세스할 수 있는 권한을 부여합니다.
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
보조 서버에서 인증서 만들기
다음 Transact-SQL 스크립트는 기본 SQL Server 복제본에 대해 만든 백업을 사용하여 마스터 키와 인증서를 만듭니다. 강력한 암호로 스크립트를 업데이트합니다. 해독 암호는 이전 단계에서 .pvk 파일을 만들 때 사용한 암호와 동일합니다. 인증서를 만들려면 모든 보조 서버에서 다음 스크립트를 실행합니다.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '**<Master_Key_Password>**';
CREATE CERTIFICATE dbm_certificate
FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (
FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
DECRYPTION BY PASSWORD = '**<Private_Key_Password>**'
);
모든 복제본에서 데이터베이스 미러링 엔드포인트 만들기
데이터베이스 미러링 엔드포인트는 TCP(전송 제어 프로토콜)를 사용하여 데이터베이스 미러링 세션에 참여하거나 가용성 복제본을 호스트하는 서버 인스턴스 간에 메시지를 보내고 받습니다. 데이터베이스 미러링 엔드포인트는 고유의 TCP 포트 번호에서 수신합니다.
다음 Transact-SQL 스크립트는 가용성 그룹에 대해 수신하는 엔드포인트 Hadr_endpoint를 만듭니다. 이 스크립트는 엔드포인트를 시작하고 만든 인증서에 대해 연결 권한을 부여합니다. 스크립트를 실행하기 전에 **< ... >** 사이의 값을 바꿉니다. 필요에 따라 IP 주소 LISTENER_IP = (0.0.0.0)을 포함할 수 있습니다. 수신기 IP 주소는 IPv4 주소여야 합니다. 또한 0.0.0.0을 사용할 수 있습니다.
모든 SQL Server 인스턴스에서 환경에 대한 다음 Transact-SQL 스크립트를 업데이트합니다.
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = **<5022>**)
FOR DATABASE_MIRRORING (
ROLE = ALL,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
참고
한 노드에서 SQL Server Express Edition을 사용하여 구성 전용 복제본을 호스트하는 경우 ROLE의 유효한 값은 WITNESS뿐입니다. SQL Server Express Edition에서 다음 스크립트를 실행합니다.
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = **<5022>**)
FOR DATABASE_MIRRORING (
ROLE = WITNESS,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES
);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
방화벽의 TCP 포트를 수신기 포트용으로 열어 두어야 합니다.
중요
SQL Server 2017 릴리스의 경우 데이터베이스 미러링 엔드포인트에 지원되는 인증 방법은 CERTIFICATE뿐입니다. WINDOWS 옵션은 향후 릴리스에서 사용할 수 있습니다.
자세한 내용은 데이터베이스 미러링 엔드포인트(SQL Server)를 참조하세요.
AG 만들기
이 섹션의 예제에서는 Transact-SQL을 사용하여 가용성 그룹을 만드는 방법을 설명합니다. SQL Server Management Studio 가용성 그룹 마법사를 사용할 수도 있습니다. 마법사를 사용하여 AG를 만들 때 AG에 복제본(replica) 조인할 때 오류가 반환됩니다. 이 문제를 해결하려면 모든 복제본의 AG에 대한 ALTER, CONTROL 및 VIEW DEFINITIONS 권한을 pacemaker에 부여합니다. 주 복제본에 대한 사용 권한이 부여된 후에 마법사를 통해 AG에 노드를 조인합니다. 단, HA가 제대로 작동하려면 모든 복제본에 대한 사용 권한을 부여합니다.
자동 장애 조치(failover)를 보장하는 고가용성 구성에서는 AG에는 세 개 이상의 복제본이 필요합니다. 고가용성을 지원할 수 있는 구성은 다음 중 하나입니다.
자세한 내용은 가용성 그룹 구성에 대한 고가용성 및 데이터 보호를 참조 하세요.
참고
가용성 그룹에 동기 또는 비동기 복제본을 추가로 포함할 수 있습니다.
Linux에서 고가용성을 위한 AG를 만듭니다. CREATE AVAILABILITY GROUP에 CLUSTER_TYPE = EXTERNAL을 사용합니다.
가용성 그룹:
CLUSTER_TYPE = EXTERNAL.외부 클러스터 엔터티가 AG를 관리하게 지정합니다. Pacemaker는 외부 클러스터 엔터티의 예입니다. AG 클러스터 유형이 external인 경우,
기본 및 보조 복제본(replica) 설정합니다.
FAILOVER_MODE = EXTERNAL복제본이 Pacemaker와 같은 외부 클러스터 관리자와 상호 작용함을 나타냅니다.
다음 Transact-SQL 스크립트는 ag1이라는 고가용성을 위한 AG를 만듭니다. 스크립트는 SEEDING_MODE = AUTOMATIC으로 AG 복제본을 구성합니다. 이렇게 설정하면 SQL Server가 각 보조 서버에 자동으로 데이터베이스를 만듭니다. 사용자 환경에 대해 다음 스크립트를 업데이트합니다. <node1>, <node2> 또는 <node3> 값을 복제본을 호스트하는 SQL Server 인스턴스 이름으로 바꿉니다. <5022>를 데이터 미러링 엔드포인트에 대해 설정한 포트로 바꿉니다. AG를 만들려면 주 복제본을 호스트하는 SQL Server 인스턴스에서 다음 Transact-SQL을 실행합니다.
중요
SQL Server 리소스 에이전트의 현재 구현에서 노드 이름은 인스턴스의 ServerName 속성과 일치해야 합니다. 예를 들어 노드 이름이 node1인 경우 SERVERPROPERTY('ServerName')가 SQL Server 인스턴스에서 node1을 반환하는지 확인합니다. 일치하지 않는 경우 pacemaker 리소스를 만든 후 복제본(replica) 해결 상태로 전환됩니다.
이 규칙이 중요한 시나리오는 정규화된 도메인 이름을 사용하는 경우입니다. 예를 들어 클러스터를 설정하는 동안 node1.yourdomain.com을 노드 이름으로 사용하는 경우 SERVERPROPERTY('ServerName')가 node1뿐만 아니라 node1.yourdomain.com도 반환해야 합니다. 이 문제에 대한 가능한 해결 방법은 다음과 같습니다.
- 호스트 이름을 FQDN으로 바꾸고
sp_dropserver및sp_addserver저장 프로시저를 사용하여 SQL Server의 메타데이터가 변경 내용과 일치하도록 합니다. pcs cluster auth명령에서addr옵션을 사용하여 노드 이름을 SERVERPROPERTY('ServerName') 값과 일치시키고 고정 IP를 노드 주소로 사용합니다.
다음 스크립트 중 하나만 실행합니다.
- 세 가지 동기 복제본(replica) 사용하여 가용성 그룹 만들기
- 두 개의 동기 복제본(replica) 구성 복제본(replica) 사용하여 가용성 그룹 만들기
- 두 개의 동기 복제본(replica) 사용하여 가용성 그룹 만들기
세 가지 동기 복제본(replica) 사용하여 가용성 그룹 만들기
세 가지 동기 복제본(replica) 사용하여 AG를 만듭니다.
CREATE AVAILABILITY GROUP [ag1]
WITH (DB_FAILOVER = ON, CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'<node1>'
WITH (
ENDPOINT_URL = N'tcp://<node1>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node2>'
WITH (
ENDPOINT_URL = N'tcp://<node2>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node3>'
WITH(
ENDPOINT_URL = N'tcp://<node3>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
Important
이전 스크립트를 실행하여 세 개의 동기 복제본(replica) 있는 AG를 만든 후에는 다음 스크립트를 실행하지 마세요.
두 개의 동기 복제본(replica) 구성 복제본(replica) 사용하여 가용성 그룹 만들기
동기 복제본 2개와 구성 복제본 1개가 포함된 AG 만들기
중요
이 아키텍처에서는 모든 버전의 SQL Server에서 세 번째 복제본을 호스트할 수 있습니다. 예를 들어 SQL Server Express Edition에서 세 번째 복제본을 호스트할 수 있습니다. Express Edition에서 유효한 엔드포인트 유형은 WITNESS뿐입니다.
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'<node1>' WITH (
ENDPOINT_URL = N'tcp://<node1>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node2>' WITH (
ENDPOINT_URL = N'tcp://<node2>:<5022>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'<node3>' WITH (
ENDPOINT_URL = N'tcp://<node3>:<5022>',
AVAILABILITY_MODE = CONFIGURATION_ONLY
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
두 개의 동기 복제본(replica) 사용하여 가용성 그룹 만들기
동기 복제본 2개가 포함된 AG 만들기
동기 가용성 모드인 복제본 2개를 포함합니다. 예를 들어 다음 스크립트는 ag1이라는 AG를 만듭니다. node1 및 node2는 동기 모드로 복제본을 호스트하며 자동 시드 및 자동 장애 조치(failover)를 사용합니다.
중요
다음 스크립트는 동기 복제본 2개가 포함된 AG를 만드는 경우에만 실행합니다. 이전 스크립트를 실행한 경우에는 다음 스크립트를 실행하지 마세요.
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'node1' WITH (
ENDPOINT_URL = N'tcp://node1:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
),
N'node2' WITH (
ENDPOINT_URL = N'tcp://node2:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC
);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
SQL Server Management Studio 또는 PowerShell을 사용하여 CLUSTER_TYPE=EXTERNAL로 AG를 구성할 수도 있습니다.
AG에 보조 복제본 조인
Pacemaker 사용자에게 모든 복제본의 가용성 그룹에 대한 ALTER, CONTROL 및 VIEW DEFINITION 권한이 필요합니다. 사용 권한을 부여하려면 가용성 그룹이 생성된 후의 주 복제본과 보조 복제본이 가용성 그룹에 추가된 직후의 각 보조 복제본에서 다음 Transact-SQL을 실행합니다. 스크립트를 실행하기 전에 <pacemakerLogin>을 Pacemaker 사용자 계정 이름으로 바꿉니다. Pacemaker에 대한 로그인이 없는 경우 Pacemaker에 대한 SQL Server 로그인을 만듭니다.
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>
다음 Transact-SQL 스크립트는 ag1이라는 AG에 SQL Server 인스턴스를 조인합니다. 사용자 환경에 대해 스크립트를 업데이트합니다. 보조 복제본을 호스트하는 각 SQL Server 인스턴스에서 다음 Transact-SQL을 실행하여 AG에 참가합니다.
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
가용성 그룹에 데이터베이스 추가
가용성 그룹에 추가하는 데이터베이스가 전체 복구 모델에 있고 유효한 로그 백업이 있는지 확인합니다. 테스트 데이터베이스이거나 새로 만든 데이터베이스인 경우 데이터베이스 백업을 수행합니다. 기본 SQL Server에서 다음 Transact-SQL 스크립트를 실행하여 db1이라는 데이터베이스를 만들고 백업합니다.
CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';
기본 SQL Server 복제본에서 다음 Transact-SQL 스크립트를 실행하여 db1 데이터베이스를 가용성 그룹 ag1에 추가합니다.
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];
데이터베이스가 보조 서버에 생성되었는지 확인
각 보조 SQL Server 복제본에서 다음 쿼리를 실행하여 db1 데이터베이스가 생성되고 동기화되었는지 확인합니다.
SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;
중요
AG를 만든 후에는 고가용성을 위해 Pacemaker와 같은 클러스터 기술과의 통합을 구성해야 합니다. SQL Server 2017(14.x)부터 Ag를 사용하는 읽기 확장 구성의 경우 클러스터를 설정할 필요가 없습니다.
이 문서의 단계를 수행한 경우 아직 클러스터되지 않은 AG가 있습니다. 다음 단계는 클러스터를 추가하는 것입니다. 이 구성은 읽기 확장/부하 분산 시나리오에 유효하며 고가용성을 위해 완료되지 않았습니다. 고가용성을 지원하려면 AG를 클러스터 리소스로 추가해야 합니다. 지침은 관련 콘텐츠를 참조하세요.
설명
Important
클러스터를 구성하고 AG를 클러스터 리소스로 추가한 후에는 Transact-SQL을 사용하여 AG 리소스를 장애 조치(failover)할 수 없습니다. Linux의 SQL Server 클러스터 리소스는 WSFC(Windows Server 장애 조치(failover) 클러스터)에 있을 때처럼 운영 체제와 긴밀하게 결합되지 않습니다. SQL Server 서비스는 클러스터의 존재를 인식하지 못합니다. 모든 오케스트레이션이 클러스터 관리 도구를 통해 수행됩니다. RHEL 또는 Ubuntu에서 pcs를 사용합니다. SLES에서는 crm을 사용합니다.
Important
AG가 클러스터 리소스인 경우 비동기 복제본(replica) 데이터 손실이 있는 강제 장애 조치(failover)가 작동하지 않는 알려진 문제가 현재 릴리스에 있습니다. 이 문제는 이후 릴리스에서 해결될 예정입니다. 동기 복제본에 대한 수동 또는 자동 장애 조치(failover)는 성공합니다.
관련 콘텐츠
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기