이 글에서는 고가용성(HA) 및 재해 복구(DR) 솔루션인 로그 전달(Log Shipping)을 이미 Microsoft® SQL Server® AlwaysOn으로 구성된 기존 데이터베이스에 설정하는 방법을 단계별로 소개합니다.
개요
AlwaysOn 가용성 그룹(Availability Group, AG)은 데이터베이스 미러링에 대한 엔터프라이즈급 대안을 제공하는 고가용성·재해 복구 솔루션입니다. SQL Server 2012(11.x)에서 처음 도입된 AlwaysOn AG는 엔터프라이즈 사용자 데이터베이스 세트의 가용성을 극대화합니다.
AG는 함께 장애 조치(fail over)되는 개별 사용자 데이터베이스 세트, 즉 '가용성 데이터베이스'를 위한 장애 조치 환경을 지원하며, 읽기-쓰기가 가능한 하나의 주(Primary) 데이터베이스 세트와 최대 8개의 해당 보조(Secondary) 데이터베이스 세트를 지원합니다. 선택 사항으로 보조 데이터베이스를 읽기 전용 액세스나 일부 백업 작업에 활용할 수도 있습니다.
SQL Server 로그 전달은 주 서버 인스턴스의 주 데이터베이스에서 트랜잭션 로그 백업을 자동으로 생성하여, 분리된 하나 이상의 보조 서버 인스턴스에 있는 보조 데이터베이스로 전송하는 기능입니다. 트랜잭션 로그 백업은 각 보조 데이터베이스에 개별적으로 적용됩니다.
AlwaysOn 환경에서 로그 전달이 필요한 이유
주 복제본 서버와 보조 복제본 간에 AlwaysOn이 구성되어 있고, 주 데이터 센터에서 AlwaysOn을 사용 중이라고 가정해 보겠습니다. 다음과 같은 상황에서는 DR 사이트까지 WSFC(Windows Server 장애 조치 클러스터) 구성을 확장할 수 없으므로 로그 전달을 활용해야 할 수 있습니다.
- 서로 다른 사이트 간의 WSFC 구성을 인프라 또는 운영 인력이 유지 관리할 수 없는 경우
- DR 사이트의 대상 서버가 이미 다른 WSFC 구성에 속해 있어 현재 WSFC에 포함시킬 수 없는 경우
- RPO(복구 시점 목표)와 RTO(복구 시간 목표)에 대한 SLA가 수동 오류로부터의 빠른 복구를 요구하며, 이것이 HA·DR 전략 중 한 인스턴스에서 트랜잭션 로그 백업을 지연 적용해 복원하는 방식으로만 실현 가능한 경우
따라서 DR 사이트에 위치한 대상 서버에 로그 전달을 통해, 메인 사이트의 현재 주 복제본에서 수행한 백업의 트랜잭션 로그를 공급해야 합니다.
로그 전달 사용을 위한 필수 조건
로그 전달을 구성하기 전에 다음 필수 조건을 충족하는지 확인하세요.
- 주 데이터베이스는 전체(Full) 또는 대량 로그(Bulk-logged) 복구 모델을 사용해야 합니다. 단순(Simple) 복구 모델로 전환하면 로그 전달이 작동하지 않습니다.
- 로그 전달을 구성하기 전에 트랜잭션 로그 백업을 보조 서버가 접근할 수 있도록 공유 경로를 생성해야 합니다.
- 로그 전달 저장 프로시저를 실행하려면 sysadmin 고정 서버 역할의 멤버여야 합니다.
- 백업 공유 경로에는 SQL Server 서비스 계정에 대한 읽기/쓰기 권한이 있어야 합니다.
로그 전달 DR 솔루션 구성 예제
이 예제에서는 아래 그림과 같이 PRIMEHEAD라는 주 복제본 서버와 HEAD2라는 보조 복제본 간에 AlwaysOn이 이미 구성되어 있다고 가정합니다.
다음 섹션에서는 이미 AlwaysOn AG에 포함된 데이터베이스에 로그 전달을 구성하는 절차를 단계별로 설명합니다.
1단계
AdventureWork2014 데이터베이스에 대해 PRIMEHEAD와 DR 서버인 HEAD3 사이에 로그 전달을 구성합니다.
데이터베이스에 로그 전달을 구성하는 동안 AdventureWork2014 데이터베이스의 전체 백업을 수행하고 HEAD3에 NORECOVERY 옵션으로 복원합니다. 또한 LSCopy(로그 전달) 작업이 사용할 로그 백업을 저장하기 위한 공유 폴더를 PRIMEHEAD에 생성해야 합니다.
2단계
PRIMEHEAD에서 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 속성(Properties)을 선택한 뒤, 왼쪽 메뉴에서 트랜잭션 로그 전달(Transaction Log Shipping) 옵션을 클릭합니다. 그런 다음 아래 그림과 같이 '이 데이터베이스를 로그 전달 구성의 주 데이터베이스로 사용' 체크박스를 선택합니다.
3단계
백업 설정(Backup Settings)을 클릭하여 LS Backup 옵션을 구성합니다. 아래 그림과 같이 LS Backup을 위한 네트워크 공유 경로를 선택합니다.
4단계
이 단계에서 LS Backup 일정을 요구 사항에 맞게 조정할 수도 있습니다. 하지만 이 시나리오에서는 기본 설정을 그대로 사용합니다.
5단계
DR 서버를 추가하려면 아래 그림과 같이 추가(Add)를 클릭합니다.
6단계
연결(Connect)을 클릭하여 DR 서버인 HEAD3에 연결합니다.
7단계
보조 데이터베이스 초기화(Initialize Secondary Database) 탭에서 세 번째 옵션을 선택합니다. 데이터베이스가 이미 HEAD3에서 초기화되었기 때문입니다.
8단계
파일 복사(Copy Files) 탭을 클릭하고, '복사된 파일의 대상 폴더' 입력란에 트랜잭션 로그 백업이 복사될 경로를 입력합니다. 이 시나리오에서는 C:\LSCopyAlwaysOn 경로를 사용합니다.
9단계
트랜잭션 로그 복원(Restore Transaction Log) 탭의 '백업 복원 시 데이터베이스 상태'에서 복구 안 함(No recovery mode) 또는 대기 모드(Standby mode) 중 하나를 선택합니다.
이 예제에서는 복구 안 함 모드를 선택했으며, 이 경우 DR 데이터베이스에는 접근할 수 없습니다. 반면 대기 모드를 선택하면 DR 데이터베이스를 최종 사용자에게 읽기 전용으로 제공할 수 있습니다.
10단계
확인(OK)을 클릭하여 로그 전달을 시작합니다.
아래와 같은 화면이 표시됩니다.
11단계
로그 전달 상태를 확인하려면 DR 서버인 HEAD3 인스턴스를 마우스 오른쪽 버튼으로 클릭하고 보고서 → 표준 보고서 → 트랜잭션 로그 전달 상태를 선택합니다. 아래와 같은 화면이 나타나면 로그 전달이 정상적으로 작동하고 있는 것입니다.
PRIMEHEAD와 HEAD2 사이에 AG 장애 조치가 발생하면, AG 특성을 고려하여 로그 전달을 다시 구성할 때까지 로그 전달이 중단됩니다.
이때 HEAD2에서 HEAD3로 로그 전달을 추가로 구성하면, 향후 AG 복제본 간에 장애 조치가 발생하더라도 로그 전달 기능에는 영향을 주지 않습니다. 어떤 복제본이 주 역할을 수행하든 로그 백업은 항상 동일한 경로나 위치에서 수행되기 때문입니다.
장애 조치를 진행하기 전에 먼저 다음 단계를 완료해야 합니다.
- 주 복제본에서 LS 백업 작업을 실행한 후 해당 작업을 비활성화합니다.
- 보조 복제본에서 LS 복사 및 복원 작업을 실행한 후 해당 작업들을 비활성화합니다.
이렇게 하려면 아래 그림과 같이 AG를 마우스 오른쪽 버튼으로 클릭하고 장애 조치(failover) 옵션을 선택합니다.
다음 T-SQL 명령을 사용하여 AG 장애 조치를 수동으로 트리거할 수도 있습니다.
USE master;
GO
ALTER AVAILABILITY GROUP [AGName] FAILOVER
GO
장애 조치가 완료되면 다음과 같은 창이 표시됩니다.
12단계
PRIMEHEAD와 HEAD2 간의 AG 장애 조치 후 현재 주 인스턴스는 HEAD2입니다.
동일한 절차에 따라 현재 주 서버(노드)인 HEAD2에서 DR 서버인 HEAD3로 로그 전달을 구성합니다. 로그 전달 구성 시에는 PRIMEHEAD와 HEAD3 사이의 LS 구성에서 사용했던 것과 동일한 공유 경로인 \\Avail2017\lsbackup을 선택해야 합니다.
13단계
현재 주 서버인 HEAD2와 HEAD3 간의 로그 전달 구성이 완료되면 HEAD2에 LS 백업 작업이 생성되고, HEAD3에는 새로운 LS 복사 및 LS 복원 작업 세트가 생성됩니다.
다시 한 번 AG 복제본 간 장애 조치를 진행합니다. 이번에도 장애 조치 전에 다음 단계를 반드시 완료해야 합니다.
- 주 복제본(HEAD2)에서 LS 백업 작업을 실행한 후 비활성화합니다.
- 보조 복제본(HEAD3)에서 LS 복사 및 복원 작업을 실행한 후 비활성화합니다.
14단계
최종 장애 조치 이후에는 PRIMEHEAD가 현재 주 복제본, HEAD2가 보조 복제본, HEAD3가 DR 서버가 됩니다. 이제 주·보조 양쪽 서버에 LS 백업 작업이 존재하므로, 현재 주 복제본에서만 로그 백업이 수행되도록 PRIMEHEAD와 HEAD2 양쪽의 LS 백업 작업을 수정해야 합니다.
이를 위해 작업 1단계(job step 1)에 다음 코드를 추가합니다.
Declare @dbname as varchar(20)
Set @dbname='AdventureWorks2014'
If sys.fn_hadr_backup_is_preferred_replica (@dbname)<>1
begin
RAISERROR (50005,-- Message id,
16, -- Severity,
1, --State,
N'This is not the primary server backup is rolled back');
end
아래 그림은 이 과정을 보여줍니다.
위 변경을 적용하면 LS 백업 작업이 보조 서버에서는 실패하지만 주 서버에서는 정상적으로 실행되는 것을 확인할 수 있습니다.
15단계
DR 서버인 HEAD3에는 두 세트의 LS 복사·복원 작업이 존재하므로, 한 번에 한 세트의 작업만 실행되도록 해야 합니다. HEAD2와 HEAD3 간 로그 전달 구성 시 생성된 작업 세트는 활성화 상태로 유지하고, 나머지 작업 세트는 비활성화합니다.
자세한 내용은 아래 그림을 참고하세요.
이제 기존 AlwaysOn AG에 포함된 데이터베이스에 대한 로그 전달 구성이 성공적으로 완료되었습니다. 어느 서버가 주 서버 역할을 수행하든 로그 전달은 항상 동기화 상태를 유지합니다.
참고: 프로덕션 환경에서 테스트 없이 변경을 적용하는 것은 강력히 권장하지 않습니다. 프로덕션 환경에 이 솔루션을 구현하기 전에 반드시 테스트 환경에서 먼저 구성을 검증하세요.
검증 방법
- 현재 주 복제본에서 백업 작업이 성공적으로 실행되고 있는지 확인합니다.
- 백업 경로가 공유 경로와 동일한지 확인합니다.
- HEAD2에서 HEAD3로의 LS 구성 시 생성된 복사 및 복원 작업이 DR 서버에서 정상적으로 실행되는지 확인합니다.
- 표준 보고서 섹션에서 트랜잭션 로그 전달 상태를 확인합니다.
결론
고가용성 데이터베이스에 로그 전달을 구성하면 다른 데이터 센터에 DR 서버를 구축할 수 있습니다. 이러한 구성은 재해 발생 시 매우 유용하며, 다른 데이터 센터의 서버에 문제가 생기더라도 최소한의 수작업만으로 비즈니스 연속성을 유지할 수 있게 해 줍니다.
전문가의 관리·구성 서비스로 환경 최적화하기
Rackspace Application Services(RAS) 전문가들은 폭넓은 애플리케이션 포트폴리오 전반에서 다음과 같은 전문 및 관리형 서비스를 제공합니다.
- e커머스 및 디지털 경험 플랫폼
- ERP(Enterprise Resource Planning)
- 비즈니스 인텔리전스
- Salesforce CRM(Customer Relationship Management)
- 데이터베이스
- 이메일 호스팅 및 생산성 솔루션
Rackspace가 제공하는 것:
- 편견 없는 전문성: 즉각적인 가치를 제공하는 기능에 집중하여 현대화 여정을 간소화하고 안내합니다.
- Fanatical Experience™: '프로세스 우선, 기술 차선(Process first. Technology second.®)' 접근 방식과 전담 기술 지원을 결합해 포괄적인 솔루션을 제공합니다.
- 타의 추종을 불허하는 포트폴리오: 풍부한 클라우드 경험을 바탕으로 올바른 클라우드에 올바른 기술을 선택하고 배포할 수 있도록 돕습니다.
- 애자일한 제공: 고객의 여정 단계에 맞춰 함께하며, 우리의 성공을 고객의 성공과 일치시킵니다.
지금 바로 채팅으로 시작해 보세요.