이 게시물은 기존 Microsoft® SQL Server® AlwaysOn 구성 데이터베이스를 사용하여 재해 복구(DR) 솔루션인 로그 전달을 설정하는 방법에 대해 설명합니다.
소개
AlwaysOn AG(가용성 그룹) 기능은 데이터베이스 미러링에 대한 엔터프라이즈 수준의 대안을 제공하는 고가용성 및 재해 복구 솔루션입니다. SQL Server 2012(11.x)에 도입된 AlwaysOn AG는 엔터프라이즈에 대한 사용자 데이터베이스 집합의 가용성을 극대화합니다. AG는 함께 장애 조치되는 가용성 데이터베이스라고 하는 개별 사용자 데이터베이스 집합에 대한 장애 조치 환경을 지원합니다. 또한 읽기-쓰기 기본 데이터베이스 세트와 해당 보조 데이터베이스 세트 1~8개를 지원합니다. 선택적으로 AG는 보조 데이터베이스를 읽기 전용 액세스 및 일부 백업 작업에 사용할 수 있도록 만들 수 있습니다.
SQL Server 로그 전달을 사용하면 기본 서버 인스턴스의 기본 데이터베이스에서 별도의 보조 서버 인스턴스에 있는 하나 이상의 보조 데이터베이스로 트랜잭션 로그 백업을 자동으로 보낼 수 있습니다. 트랜잭션 로그 백업은 각 보조 데이터베이스에 개별적으로 적용됩니다.
AlwaysOn 로그 전달이 필요한 이유
기본 복제본 서버와 보조 복제본 사이에 AlwaysOn 설정을 구성했으며 기본 데이터 센터에서 AlwaysOn을 사용한다고 가정해 보겠습니다. 필요한 WSFC(Windows Server 장애 조치 클러스터) 구성을 DR 사이트로 확장할 수 없는 경우 로그 전달을 사용해야 할 수 있습니다. 이유는 다음과 같습니다.
- 인프라 또는 직원이 서로 다른 사이트 간에 WSFC 구성을 유지할 수 없습니다.
- WSFC 구성의 DR 사이트에 있는 대상 서버는 이미 다른 WSFC 구성의 일부이기 때문에 활용할 수 없습니다.
- RPO(복구 시점 목표) 및 RTO(복구 시간 목표)에 대한 SLA(서비스 수준 계약)는 수동 오류로부터 빠른 복구를 강제합니다. 이는 고가용성의 한 인스턴스에서 트랜잭션 로그 백업을 복원하는 지연된 복구를 통해서만 실현할 수 있습니다. (HA) 및 DR 전략.
따라서 현재 Primary의 메인 사이트에서 수행된 백업에서 트랜잭션 로그를 전달하기 위해 로그 전달을 사용하여 DR 사이트에 있는 대상 서버를 제공해야 합니다.
로그 전달을 사용하기 위한 전제 조건
로그 전달을 설정하기 전에 다음 전제 조건을 충족하는지 확인하십시오.
- 기본 데이터베이스는 전체 또는 대량 로그 복구 모델을 사용해야 합니다. 데이터베이스를 단순 복구로 전환하면 로그 전달 기능이 중지됩니다.
- 로그 전달을 구성하기 전에 보조 서버에서 트랜잭션 로그 백업을 사용할 수 있도록 공유 경로를 만들어야 합니다.
- 로그 전달 저장 프로시저에는 sysadminfixed 서버 역할의 구성원 자격이 필요합니다.
- 백업 공유 경로에는 SQLServer 서비스 계정에 대한 읽기 및 쓰기 권한이 있어야 합니다.
로그 전달 DR 솔루션 구성 예시
이 예에서는 다음 이미지와 같이 PRIMEHEAD라는 기본 복제본 서버와 HEAD2라는 보조 복제본 사이에 이미 AlwasyOn을 설정했습니다.
이 섹션에서는 이미 AlwaysOn AG의 일부인 데이터베이스에서 로그 전달을 구성하는 단계별 솔루션을 제공합니다.
1단계
AdventureWork2014에 대한 로그 전달 구성 PRIMEHEAD와 DR 서버 HEAD3 간의 데이터베이스입니다.
데이터베이스에서 로그 전달을 구성하는 동안 AdventureWork2014 데이터베이스를 복구하지 않고 HEAD3에 복원합니다. LSCopy
의 로그 백업을 저장하려면 PRIMEHEAD에 공유 폴더를 만들어야 합니다. (로그 전달) 작업 사용.
2단계
데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다. , 트랜잭션 로그 전달을 클릭합니다. PRIMEHEAD의 왼쪽에 있는 옵션입니다. 그런 다음 강조 표시된 로그 전달 구성에서 기본 데이터베이스로 사용을 클릭합니다. 다음 이미지와 같이 확인란:
3단계
백업 설정을 클릭합니다. LS 백업 구성 옵션. 다음 이미지와 같이 LS Backup의 네트워크 공유 경로를 선택합니다.
4단계
이때 필요에 따라 LS 백업을 예약할 수도 있습니다. 그러나 이 시나리오에서는 기본 설정을 사용합니다.
5단계
DR 서버를 추가하려면 추가를 클릭하세요. 다음 이미지와 같이:
6단계
연결을 클릭합니다. 다음 이미지와 같이 DR 서버인 HEAD3에 연결합니다.
7단계
보조 데이터베이스 초기화에서 탭에서 데이터베이스가 이미 HEAD3에서 초기화되었으므로 세 번째 옵션을 선택하십시오.
8단계
파일 복사를 클릭합니다. 탭. 복사된 파일의 대상 폴더 상자에 트랜잭션 로그 백업이 복사되는 경로를 입력합니다. 이 시나리오의 경우 C:\LSCopyAlwaysOn을 사용합니다. 다음 이미지와 같이 경로에 대해:
9단계
트랜잭션 로그 복원에서 탭, 백업 복원 시 데이터베이스 상태 아래 , 복구 모드 없음을 선택합니다. 또는 대기 모드 , 다음 이미지와 같이:
이 예에서는 복구 모드 없음을 선택했습니다. , 이는 DRdatabase에 액세스할 수 없음을 의미합니다. 대기 모드를 선택하면 , DR 데이터베이스는 최종 사용자가 읽기 전용 모드로 사용할 수 있습니다.
10단계
확인을 클릭합니다. 로그 전달을 시작합니다.
다음 화면이 표시됩니다.
11단계
로그 전달 상태를 확인하려면 DR 서버, HEAD3, 인스턴스를 마우스 오른쪽 버튼으로 클릭하고 보고서->표준 보고서->트랜잭션 로그 전달 상태를 선택합니다. . 다음 화면이 나타나면 로그 전달이 정상이며 예상대로 작동하는 것입니다.
PRIMEHEAD와 HEAD2 사이에 AG 장애 조치가 발생하면 AG 사양을 고려하여 구성할 때까지 로그 전달이 중단됩니다.
이제 HEAD2에서 HEAD3으로 로그 전달을 구성할 수 있습니다. 그러면 향후 AG 복제본 간에 장애 조치가 있어도 로그 전달 기능에 영향을 미치지 않습니다. 로그 백업은 기본 복제본이 무엇인지에 관계없이 항상 동일한 경로 또는 위치에서 발생합니다.
복제본 간에 장애 조치를 시작해야 합니다. 장애 조치를 시작하기 전에 다음 단계를 완료하십시오.
-
주 복제본에서 LS 백업 작업을 실행하고 작업을 비활성화합니다.
-
보조 복제본에서 LS 복사 및 복원 작업을 실행한 다음 비활성화합니다.
이렇게 하려면 AG를 마우스 오른쪽 버튼으로 클릭하고 다음 이미지와 같이 장애 조치 옵션을 선택합니다.
다음 T-SQL 명령을 사용하여 AG 장애 조치를 수동으로 트리거하여 이를 수행할 수도 있습니다.
USE master;
GO
ALTER AVAILABILITY GROUP [AGName] FAILOVER
GO
장애 조치가 완료된 후 다음 창이 표시됩니다.
12단계
PRIMEHEAD와 HEAD2 간의 AG 장애 조치 후 현재 기본 인스턴스는 HEAD2입니다.
동일한 단계에 따라 현재 기본 서버 또는 노드인 HEAD2에서 DR 서버인 HEAD3으로 로그 전달을 구성합니다. 로그 전달을 구성하는 동안 PRIMEHEAD와 HEAD3(\Avail2017\lsbackup) 간에 LS 구성 중에 사용한 것과 동일한 공유 경로를 선택합니다. .
13단계
HEAD2, 현재 기본 및 HEAD3 간의 로그 전달이 완료된 후 HEAD2에 LS 백업 작업이 생성되고 HEAD3에 다른 LS 복사 및 LS 복원 작업 세트가 생성됩니다.
다시 한 번 AG 복제본 간에 장애 조치를 시작합니다. 장애 조치를 시작하기 전에 다음 단계를 완료해야 합니다.
-
기본(HEAD2)에서 LS 백업 작업을 실행하고 작업을 비활성화합니다.
-
보조(HEAD3)에서 LS 복사 및 복원 작업을 실행한 다음 비활성화합니다.
14단계
최종 장애 조치 후 현재 기본 서버는 PRIMEHEAD, HEAD2는 보조 복제본, HEAD3은 DR 서버입니다. LS 백업 작업은 기본 및 보조 서버 모두에 존재하므로 현재 기본 서버에서만 로그 백업을 수행하도록 PRIMEHEAD 및 HEAD2 모두에서 LS 백업 작업을 수정해야 합니다.
이렇게 하려면 작업 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의 일부인 데이터베이스에서 로그 전달을 성공적으로 구성했습니다. 어떤 서버가 기본 서버로 작동하든 상관없이 로그 전달은 동기화됩니다.
참고 :테스트 없이 프로덕션 환경에서 변경하지 않는 것이 좋습니다. 프로덕션 환경에서 이 솔루션을 구현하기 전에 먼저 테스트 환경에서 이 구성을 구현하세요.
검증:
a) 백업 작업이 현재 주 복제본에서 성공적으로 실행되고 있는지 확인합니다.b) 백업 경로는 공유 경로와 동일해야 합니다.c) HEAD2에서 HEAD3으로 LS 구성 중에 생성된 복사 및 복원 작업이 제대로 실행되어야 합니다. DR 서버에서.d) 표준 보고서 섹션에서 트랜잭션 로그 전달 상태를 확인합니다.
결론
고가용성 데이터베이스에서 로그 전달을 구성하면 다른 데이터 센터에 aDR 서버를 설정할 수 있습니다. 이 설정은 재해 발생 시 도움이 되며 다른 데이터 센터의 서버가 영향을 받는 경우에도 최소한의 수동 작업으로 비즈니스에 영향을 미치지 않도록 합니다.
피드백 탭을 사용하여 의견을 남기거나 질문하십시오.
전문가 관리, 관리 및 구성으로 환경 최적화
Rackspace의 애플리케이션 서비스(RAS) 전문가는 광범위한 애플리케이션 포트폴리오에서 다음과 같은 전문적이고 관리되는 서비스를 제공합니다.
- 전자상거래 및 디지털 경험 플랫폼
- 전사적 자원 관리(ERP)
- 비즈니스 인텔리전스
- Salesforce CRM(고객 관계 관리)
- 데이터베이스
- 이메일 호스팅 및 생산성
우리는 다음을 제공합니다:
- 편향 없는 전문성 :즉각적인 가치를 제공하는 기능에 중점을 두고 현대화 여정을 간소화하고 안내합니다.
- 광신적인 경험 ™:프로세스를 먼저 결합합니다. 기술 두 번째.®전담 기술 지원을 통해 포괄적인 솔루션을 제공하는 접근 방식.
- 타의 추종을 불허하는 포트폴리오 :광범위한 클라우드 경험을 적용하여 올바른 클라우드에서 올바른 기술을 선택하고 배포할 수 있도록 지원합니다.
- 민첩한 전달 :귀하의 여정에서 귀하를 만나고 귀하의 성공에 맞춰 귀하의 성공을 맞춥니다.
시작하려면 지금 채팅하세요.