비즈니스 연속성 및 데이터베이스 복구 - SQL Server on Linux

아티클
07/15/2024

적용 대상: SQL Server

이 문서에서는 Windows 및 Linux에서 SQL Server의 고가용성 및 재해 복구를 위한 비즈니스 연속성 솔루션에 대한 개요를 제공합니다.

SQL Server를 배포하는 모든 사람들이 공통적으로 해야 할 작업 중 하나는 모든 중요한 SQL Server 인스턴스와 그 안에 포함된 데이터베이스를 비즈니스 및 최종 사용자가 필요로 할 때(예: 9~5시 사이 또는 24시간 내내) 사용할 수 있도록 하는 것입니다. 목표는 중단을 최소화하거나 중단 없이 비즈니스를 계속 운영하는 것입니다. 이러한 개념을 비즈니스 연속성이라고도 합니다.

SQL Server 2017(14.x)은 기존 기능에 새롭거나 향상된 기능을 많이 도입했으며 그 중 일부는 가용성을 위한 것입니다. SQL Server 2017(14.x)에서 가장 크게 추가된 기능은 Linux 배포판에서 SQL Server를 지원하는 것입니다. SQL Server에 있는 새로운 기능의 전체 목록은 다음 문서를 참조하세요.

이 문서는 SQL Server 2017(14.x) 이상 버전의 가용성 시나리오와 새롭고 향상된 가용성 기능을 설명하는 데 중점을 두고 있습니다. 이 시나리오에는 Windows Server 및 Linux에서 SQL Server 배포를 확장할 수 있을 뿐만 아니라 데이터베이스의 읽기 가능한 복사본 수를 늘릴 수 있는 하이브리드 시나리오도 포함됩니다.

이 문서에서는 가상화에서 제공되는 것과 같은 SQL Server 외부의 가용성 옵션을 설명하지 않지만, 여기에 언급된 모든 내용은 퍼블릭 클라우드의 게스트 가상 머신이나 온-프레미스 하이퍼바이저 서버가 호스트하는 게스트 가상 머신 내부의 SQL Server 설치에 적용됩니다.

가용성 기능을 사용하는 SQL Server 시나리오

Always On 가용성 그룹, Always On 장애 조치(failover) 클러스터 인스턴스 및 로그 전달은 가용성 목적뿐만 아니라 다양한 방식으로 사용할 수 있습니다. 가용성 기능을 사용할 수 있는 주요 방법은 네 가지입니다.

고가용성
재해 복구
마이그레이션 및 업그레이드
하나 이상의 데이터베이스에서 읽을 수 있는 복사본 확장

다음 섹션에서는 특정 시나리오에 사용할 수 있는 관련 기능에 대해 설명합니다. 다루지 않는 한 가지 기능은 SQL Server 복제입니다. Always On 내에 가용성 기능으로 공식 지정되지는 않았지만 SQL Server 복제는 특정 시나리오에서 데이터 중복을 위해 종종 사용됩니다. 병합 복제는 SQL Server on Linux에서 지원되지 않습니다. 자세한 내용은 Linux의 SQL Server 복제를 참조하세요.

중요

SQL Server 가용성 기능을 사용하더라도 가용성 솔루션의 가장 근본적인 구성 요소인 충분한 테스트를 거친 강력한 백업 및 복원 전략이 꼭 필요합니다.

고가용성

클라우드의 데이터 센터 또는 단일 지역에 국한된 문제가 발생하는 경우 SQL Server 인스턴스 또는 데이터베이스를 사용할 수 있도록 하는 것이 중요합니다. 이 섹션에서는 SQL Server 가용성 기능이 이러한 작업을 지원하는 방법에 대해 설명합니다. 설명된 모든 기능은 Windows Server 및 Linux에서 둘 다 사용할 수 있습니다.

가용성 그룹

SQL Server 2012(11.x)에 도입된 AG(가용성 그룹)는 데이터베이스의 각 트랜잭션을 다른 인스턴스 또는 특수 상태의 해당 데이터베이스 복사본이 포함된 복제본으로 보내서 데이터베이스 수준의 보호를 제공합니다. AG는 Standard 또는 Enterprise Edition에 배포할 수 있습니다. AG에 참여하는 인스턴스는 독립 실행형이거나 FCI(장애 조치(failover) 클러스터 인스턴스)(다음 섹션 참조)일 수 있습니다. 트랜잭션이 발생하면 복제본으로 전송되기 때문에 복구 지점 및 복구 시간 목표를 낮추기 위한 요구 사항이 있는 경우 AG를 사용하는 것이 좋습니다. 복제본 간의 데이터 이동은 동기식 또는 비동기식일 수 있으며 Enterprise Edition에서는 동기식으로 최대 3개의 복제본(기본 포함)이 허용됩니다. AG에는 주 복제본에 있는 데이터베이스의 완전 읽기/쓰기 복사본이 하나 있고 모든 보조 복제본은 최종 사용자 또는 애플리케이션에서 직접 트랜잭션을 수신할 수 없습니다.

참고

Always On은 SQL Server의 가용성 기능에 대한 포괄적인 용어이며 AG와 FCI가 포함됩니다. Always On은 AG 기능의 이름이 아닙니다.

SQL Server 2022(16.x) 이전에는 AG가 인스턴스 수준 보호가 아닌 데이터베이스 수준 보호만 제공합니다. 트랜잭션 로그에 캡처되지 않거나 데이터베이스에 구성되지 않은 항목은 각 보조 복제본에 수동으로 동기화되어야 합니다. 수동으로 동기화해야 하는 개체의 예로는 인스턴스 수준의 로그인, 연결된 서버 및 SQL Server 에이전트 작업이 있습니다.

SQL Server 2022(16.x)부터 인스턴스 수준 외에도 AG 수준에서 사용자, 로그인, 권한 및 SQL Server 에이전트 작업을 포함한 메타데이터 개체를 관리할 수 있습니다. 자세한 내용은 포함된 가용성 그룹을 참조하세요.

AG에는 수신기라는 또 다른 구성 요소가 있어서 애플리케이션과 최종 사용자가 주 복제본을 호스트하는 SQL Server 인스턴스를 몰라도 연결기 가능하도록 합니다. 각 AG에는 자체 수신기가 있습니다. 수신기 구현은 Windows Server와 Linux에서 약간 다르지만 제공하는 기능과 사용하는 방법은 동일합니다. 아래 다이어그램은 WSFC(Windows Server 장애 조치(failover) 클러스터)를 사용하는 Windows Server 기반 AG를 보여 줍니다. OS 계층에 있는 기본 클러스터는 Linux 또는 Windows Server에 상관없이 가용성을 위해 필요합니다. 이 예제는 WSFC가 기본 클러스터인 두 개의 서버 또는 노드를 포함하는 간단한 구성을 보여 줍니다.

간단한 가용성 그룹의 다이어그램

Standard 및 Enterprise Edition은 복제본에 대한 최댓값이 다릅니다. 기본 가용성 그룹이라고 하는 Standard Edition의 AG는 AG의 데이터베이스가 하나뿐인 두 개의 복제본(주 복제본과 보조 복제본)을 지원합니다. Enterprise Edition은 하나의 AG에 여러 데이터베이스를 구성할 수 있을 뿐 아니라 최대 9개의 복제본(주 1개, 보조 8개)을 가질 수 있습니다. Enterprise Edition은 읽기 가능한 보조 복제본, 보조 복제본에서 백업을 수행하는 기능 등의 다른 선택적 이점도 제공합니다.

참고

SQL Server 2012(11.x)에서 더 이상 사용되지 않는 데이터베이스 미러링은 Linux 버전의 SQL Server에서 사용할 수 없으며 추가되지 않습니다. 데이터베이스 미러링을 아직 사용하는 고객은 데이터베이스 미러링을 대체하는 AG로의 마이그레이션을 계획해야 합니다.

가용성과 관련하여 AG는 자동 또는 수동 장애 조치(failover)를 제공할 수 있습니다. 자동 장애 조치(failover)는 동기 데이터 이동이 구성되어 있고 주 복제본과 보조 복제본의 데이터베이스가 동기화된 상태이면 발생할 수 있습니다. 수신기가 사용되고 애플리케이션에 최신 버전의 .NET Framework(업데이트가 있는 3.5 또는 4.0 이상)이 사용되는 한, 수신기가 사용되는 경우 최종 사용자에게 거의 영향을 미치지 않으면서 장애 조치(failover)가 처리되어야 합니다. 보조 복제본으로 장애 조치하여 새 주 복제본으로 만드는 작업은 자동 또는 수동으로 구성할 수 있으며 일반적으로 초 단위로 측정됩니다.

아래 목록은 Windows Server와 Linux에서 AG의 몇 가지 차이점을 보여 줍니다.

Linux와 Windows Server에서 기본 클러스터가 작동하는 방식의 차이로 인해 AG의 모든 장애 조치(failover)(수동 또는 자동)는 Linux의 클러스터를 통해 수행됩니다. Windows Server 기반 AG 배포에서는 SQL Server를 통해 수동 장애 조치(failover)를 수행해야 합니다. 자동 장애 조치(failover)는 Windows Server와 Linux의 기본 클러스터에서 처리됩니다.
SQL Server on Linux의 경우 AG에 권장되는 구성은 최소 3개의 복제본입니다. 이것은 기본 클러스터링이 작동하는 방식 때문입니다.
Linux에서 각 수신기에서 사용되는 일반 이름은 DNS에 정의되며 Windows Server에서처럼 클러스터에 정의되지 않습니다.

SQL Server 2017(14.x)부터 AG에 대한 몇 가지 새롭고 향상된 기능이 있습니다.

클러스터 유형
REQUIRED_SECONDARIES_TO_COMMIT
Windows Server 기반 구성에 대해 향상된 Microsoft DTC(Distributor Transaction Coordinator) 지원
읽기 전용 데이터베이스에 대한 추가 스케일 아웃 시나리오(이 문서의 뒷부분에서 설명됨)

가용성 그룹 클러스터 유형

Windows Server에 기본 제공되는 클러스터링의 가용성 형태는 장애 조치(failover) 클러스터링이라는 기능을 통해 활성화됩니다. 이를 통해 AG 또는 FCI와 함께 사용되는 WSFC를 만들 수 있습니다. AG 및 FCI에 대한 통합은 SQL Server에 제공되는 클러스터 인식 리소스 DLL에 의해 제공됩니다.

SQL Server on Linux는 여러 클러스터링 기술을 지원합니다. Microsoft는 SQL Server 구성 요소를 지원하고 파트너는 관련 클러스터링 기술을 지원합니다. 예를 들어 Pacemaker와 함께 SQL Server on Linux는 HPE Serviceguard 및 DH2i DxEnterprise를 클러스터 솔루션으로 지원합니다.

Windows 기반 장애 조치(failover) 클러스터 및 Linux 클러스터 솔루션은 유사한 편입니다. 둘 다 개별 서버를 구성으로 결합하여 가용성을 제공하는 방법을 제공하고 리소스, 제약 조건(다르게 구현되는 경우에도), 장애 조치(failover) 등의 개념을 제공합니다.

예를 들어 AG와 자동 장애 조치(failover)와 같은 FCI 구성 양쪽 모두에 대해 Pacemaker를 지원하기 위해 Microsoft는 mssql-server-ha 패키지를 제공합니다. 이것은 Pacemaker용 WSFC의 리소스 DLL과 유사하지만 완전히 동일하지는 않습니다. WSFC와 Pacemaker의 차이 중 하나는 Pacemaker에 네트워크 이름 리소스가 없다는 것입니다. Pacemaker는 WSFC에서 수신기 이름(또는 FCI 이름)을 추상화하는 데 도움이 되는 구성 요소입니다. DNS는 Linux에서 해당 이름 확인을 제공합니다.

클러스터 스택의 차이로 인해, SQL Server는 WSFC에서 기본적으로 처리하는 일부 메타데이터를 처리해야 하기 때문에 AG에 대한 일부 변경이 필요했습니다. 가장 중요한 변경 내용은 가용성 그룹에 대한 클러스터 유형이 도입된 것입니다. 이 값은 sys.availability_groups의 cluster_type 및 cluster_type_desc 열에 저장됩니다. 클러스터 유형은 세 가지입니다.

WSFC
외부
None

고가용성이 필요한 모든 AG는 SQL Server 2017(14.x) 이상 버전에서 WSFC 또는 Linux 클러스터링 에이전트를 의미하는 기본 클러스터를 사용해야 합니다. 기본 WSFC를 사용하는 Windows Server 기반 AG의 경우 기본 클러스터 유형은 WSFC이며 설정이 필요 없습니다. Linux 기반 AG의 경우 AG를 만들 때 클러스터 유형을 외부로 설정해야 합니다. Linux의 외부 클러스터 솔루션과의 통합은 AG가 만들어진 후에 구성되는 반면 WSFC의 경우 생성 시 완료됩니다.

없음이라는 클러스터 유형은 Windows Server 및 Linux AG 모두에서 사용할 수 있습니다. 클러스터 유형을 없음으로 설정하면 AG에 기본 클러스터가 필요하지 않다는 의미입니다. 즉, SQL Server 2017(14.x)은 클러스터 없이 AG를 지원하는 첫 번째 SQL Server 버전이지만 이 구성은 고가용성 솔루션으로 지원되지 않습니다.

중요

SQL Server 2017(14.x)부터 AG를 만든 후에는 해당 클러스터 유형을 변경할 수 없습니다. 즉, AG를 없음에서 외부 또는 WSFC로 또는 그 반대로 전환할 수 없습니다.

데이터베이스의 읽기 전용 복사본만 추가하려는 경우 또는 AG가 마이그레이션/업그레이드에 제공하는 기능은 필요하지만 기본 클러스터나 복제의 추가 복잡성에 관여하지 않으려는 경우에는 클러스터 유형이 없음인 AG가 완벽한 솔루션이 될 수 있습니다. 자세한 내용은 마이그레이션 및 업그레이드와 읽기 확장을 참조하세요.

아래 스크린샷은 SSMS(SQL Server Management Studio)의 여러 종류의 클러스터 유형에 대한 지원을 보여줍니다. 버전 17.1 이상을 실행해야 합니다. 아래 스크린샷은 버전 17.2입니다.

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

SQL Server 2016(13.x)은 Enterprise Edition에서 동기 복제본 수에 대한 지원을 2에서 3으로 증가 시켰습니다. 하지만 하나의 보조 복제본이 동기화되었지만 다른 복제본에 문제가 있다면 오작동하는 복제본을 기다리거나 그대로 진행하도록 기본 복제본에 알리는 동작을 제어할 방법이 없습니다. 즉 보조 복제본이 동기화된 상태가 아니라도 다시 말해 보조 복제본에 데이터 손실이 발생하더라도 주 복제본은 어느 시점에 쓰기 트래픽을 계속 받게 됩니다. SQL Server 2017(14.x)부터 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT와의 동기 복제본이 있을 때 발생하는 동작을 제어할 수 있습니다. 이 옵션은 다음과 같이 작동합니다.

세 가지 값 0, 1 및 2를 사용할 수 있습니다.
이 값은 동기화해야 하는 보조 복제본의 수이며 데이터 손실, AG 가용성 및 장애 조치(failover)에 영향을 미칩니다.
WSFC 및 클러스터 유형이 없음인 경우 기본값은 0이며 수동으로 1 또는 2로 설정할 수 있습니다.
클러스터 유형이 외부인 경우 기본적으로 클러스터 메커니즘에 의해 이 값이 설정되며 수동으로 재정의할 수 있습니다. 동기 복제본이 3개인 경우, 기본값은 1입니다.

Linux에서 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT의 값은 클러스터의 AG 리소스에 구성됩니다. Windows에서는 Transact-SQL을 통해 설정됩니다.

필요한 수의 보조 복제본이 없으면 이것이 해결될 때까지 주 복제본을 사용할 수 없기 때문에 값이 0보다 높으면 데이터 보호 수준이 높아집니다. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT은 장애 조치(failover) 동작에도 영향을 주는데 이것은 필요한 수의 보조 복제본이 적절한 상태가 아니면 자동 장애 조치(failover)가 발생할 수 없기 때문입니다. Linux에서 값이 0이면 자동 장애 조치(failover)를 허용하지 않으므로 Linux에서 자동 장애 조치(failover)와 함께 동기를 사용할 경우 자동 장애 조치(failover)를 수행하려면 값을 0보다 높게 설정해야 합니다. Windows Server의 0은 SQL Server 2016(13.x) 및 이전 버전의 동작입니다.

향상된 Microsoft DTC(Distributed Transaction Coordinator) 지원

SQL Server 2016(13.x) 이전에는 DTC를 사용하는 분산 트랜잭션이 필요한 애플리케이션에 대해 SQL Server에서 가용성을 얻는 유일한 방법은 FCI를 배포하는 것이었습니다. 분산 트랜잭션은 다음 두 가지 방법 중 하나로 수행할 수 있습니다.

동일한 SQL Server 인스턴스에서 둘 이상의 데이터베이스에 걸쳐있는 트랜잭션
둘 이상의 SQL Server 인스턴스에 걸쳐 있거나 SQL Server 이외의 데이터 원본과 관련된 트랜잭션

SQL Server 2016(13.x)에서는 후자의 시나리오를 처리하는 AG를 사용하여 DTC를 부분적으로 지원합니다. SQL Server 2017(14.x)은 DTC를 사용하여 두 시나리오를 모두 지원함으로써 기능 완수합니다.

SQL Server 2017(14.x) 이상 버전에서는 AG를 만든 후에도 DTC 지원이 추가될 수 있습니다. SQL Server 2016(13.x)에서는 AG를 만들 때만 AG에 대한 DTC 지원을 사용할 수 있었습니다.

장애 조치(Failover) 클러스터 인스턴스

클러스터형 설치는 버전 6.5부터 SQL Server의 기능입니다. FCI는 SQL Server의 전체 설치에 대해 가용성을 제공하는 입증된 방법이며 인스턴스로 알려져 있습니다. 즉, 기본 서버에 문제가 발생할 경우 데이터베이스, SQL Server 에이전트 작업, 연결된 서버 등 인스턴스 내부의 모든 항목이 다른 서버로 이동됩니다. 모든 FCI는 네트워킹을 통해 제공되는 경우에도 일종의 공유 스토리지가 필요합니다. FCI의 리소스는 주어진 시간에 한 노드에서만 실행하고 소유할 수 있습니다. 아래 다이어그램에서 클러스터의 첫 번째 노드는 FCI를 소유하며 이는 스토리지에 실선으로 표시된 공유 스토리지 리소스를 소유하는 것을 의미합니다.

장애 조치(failover) 클러스터 인스턴스 다이어그램

장애 조치(failover) 후에는 아래 다이어그램과 같이 소유권이 변경됩니다.

장애 조치(failover) 클러스터 인스턴스, 장애 조치(failover) 후 다이어그램

FCI에서는 데이터 손실이 거의 없지만 데이터 복사본이 하나이기 때문에 기본 공유 스토리지는 단일 실패 지점입니다. FCI는 중복 데이터베이스 복사본을 확보하기 위해 종종 AG나 로그 전달과 같은 다른 가용성 방법과 결합됩니다. 추가로 배포된 방법은 FCI와 물리적으로 분리된 스토리지를 사용해야 합니다. FCI가 다른 노드로 장애 조치(failover)되면 노드를 중지하고 다른 노드에서 시작하기 때문에 서버의 전원을 껐다 켜는 것과는 다릅니다. FCI는 정상 복구 프로세스를 거칩니다. 즉 롤포워드가 필요한 트랜잭션은 롤포워드가 수행되며 불완전한 트랜잭션은 롤백됩니다. 따라서 데이터베이스는 장애 또는 수동 장애 조치(failover) 시간의 데이터 지점과 일관성을 유지하기 때문에 데이터 손실이 없습니다. 데이터베이스는 복구가 완료된 후에만 사용할 수 있으며 복구 시간은 다양한 요인에 따라 달라지며 일반적으로 AG의 장애 조치 시간보다 길어집니다. AG를 장애 조치하면 데이터베이스를 사용할 수 있도록 만드는 데 필요한 추가 작업(task)(예: SQL Server 에이전트 작업(job)을 사용하도록 설정)이 있을 수 있습니다.

AG와 마찬가지로 FCI는 기본 클러스터의 어느 노드에서 호스트 하는지를 추상화합니다. FCI는 항상 같은 이름을 유지합니다. 애플리케이션과 최종 사용자는 노드에 절대 연결하지 않으며 FCI에 할당된 고유한 이름이 사용됩니다. FCI는 주 또는 보조 복제본을 호스트하는 인스턴스 중 하나로 AG에 참여할 수 있습니다.

아래 목록은 Windows Server와 Linux에서 FCI의 몇 가지 차이점을 보여줍니다.

Windows Server에서 FCI는 설치 프로세스의 일부입니다. Linux의 FCI는 SQL Server를 설치한 후에 구성됩니다.
Linux에서는 호스트당 SQL Server를 하나만 설치할 수 있으므로 모든 FCI가 기본 인스턴스가 됩니다. Windows Server는 WSFC당 최대 25개의 FCI를 지원합니다.
Linux에서 FCI가 사용하는 일반 이름은 DNS에 정의되어 있으며 FCI용으로 생성된 리소스와 동일해야 합니다.

로그 전달

복구 시점 및 복구 시간 목표가 보다 유연하거나 데이터베이스가 업무상 중요하지 않은 경우에는 로그 전달이 SQL Server의 입증된 또 다른 가용성 기능이 될 수 있습니다. SQL Server의 기본 백업을 기반으로 로그 전달 프로세스는 트랜잭션 로그 백업을 자동으로 생성하고, 이것을 웜 대기라는 하나 이상의 인스턴스에 복사하고, 트랜잭션 로그 백업을 해당 대기 항목에 자동으로 적용합니다. 로그 전달은 SQL Server 에이전트 작업을 사용하여 트랜잭션 로그 백업을 백업, 복사 및 적용하는 프로세스를 자동화합니다.

로그 전달 다이어그램

일부 용량에서 로그 전달을 사용하는 가장 큰 이점은 사람의 실수를 처리하는 것입니다. 트랜잭션 로그 적용은 지연될 수 있습니다. 따라서 누군가 WHERE 절 없이 UPDATE 등의 명령을 보내면 대기에 변경 사항이 전달되지 않아서 주 시스템을 복구하는 동안 대기로 전환될 수 있습니다. 로그 전달은 구성하기 쉽지만 기본 대기에서 웜 대기로 전환하는 것(역할 변경이라고 함)은 항상 수동입니다. 역할 변경은 Transact-SQL을 통해 시작되며 AG와 마찬가지로 트랜잭션 로그에 캡처되지 않은 모든 개체는 수동으로 동기화해야 합니다. 단일 AG에는 여러 데이터베이스가 포함될 수 있지만 로그 전달은 데이터베이스별로 구성해야 합니다.

AG 또는 FCI와 달리 로그 전달에는 애플리케이션이 처리할 수 있어야 하는 역할 변경에 대한 추상화가 없습니다. DNS 별칭(CNAME)과 같은 기술을 사용할 수 있지만 전환 후 DNS를 새로 고치는 데 걸리는 시간과 같은 장단점이 있습니다.