사서함 데이터베이스 복사본 관리

아티클
04/04/2023

적용 대상: Exchange Server 2013

DAG(데이터베이스 가용성 그룹)를 만들고 구성하고 사서함 서버 구성원으로 채운 후에는 EAC(Exchange 관리 센터) 또는 Exchange 관리 셸을 사용하여 유연하고 세분화된 방식으로 사서함 데이터베이스 복사본을 추가할 수 있습니다.

데이터베이스 복사본 관리

데이터베이스의 복사본이 여러 개 만들어진 후에는 EAC 또는 셸을 사용하여 각 복사본의 상태를 모니터링하고 데이터베이스 복사본과 관련된 다른 관리 작업을 수행할 수 있습니다. 이러한 관리 작업에는 데이터베이스 복사본 일시 중단 또는 다시 시작, 데이터베이스 복사본 시드, 데이터베이스 복사본 모니터링, 데이터베이스 복사본 설정 구성, 데이터베이스 복사본 제거 등이 있습니다.

데이터베이스 복사본 일시 중단 및 다시 시작

계획한 유지 관리 수행 같은 다양한 이유로, 데이터베이스 복사본에 대한 연속 복제 작업을 일시 중단하고 다시 시작해야 할 경우가 있습니다. 또한 시드 등의 일부 관리 작업에서는 먼저 데이터베이스 복사를 일시 중단해야 합니다. 데이터베이스의 경로 또는 그 로그 파일을 변경할 경우 모든 복제 작업을 일시 중단하는 것이 좋습니다. EAC를 사용하거나 셸에서 Suspend-MailboxDatabaseCopy 및 Resume-MailboxDatabaseCopy cmdlet을 실행하여 데이터베이스 복사본 작업을 일시 중단하고 다시 시작할 수 있습니다. 데이터베이스 복사본의 연속 복제 작업을 일시 중단하거나 다시 시작하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본을 다시 시작 또는 일시 중단을 참조하십시오.

데이터베이스 복사본 시드

업데이트라고도 하는 시드는 빈 데이터베이스 또는 프로덕션 데이터베이스의 복사본인 데이터베이스가 활성 데이터베이스와 동일한 DAG에 있는 다른 사서함 서버의 대상 복사 위치에 추가되는 과정을 말합니다. 이는 해당 서버에서 유지 관리되는 복사본에 대한 기준 데이터베이스가 됩니다.

상황에 따라 시드를 자동으로 진행하거나 사용자가 수동으로 시작할 수 있습니다. 데이터베이스 복사본이 추가되면, 이 복사본은 대상 서버와 저장소가 적절히 구성되어 있는 경우 자동으로 시드됩니다. 데이터베이스 복사본을 수동으로 시드하고 복사본을 만들 때 자동 시드를 수행하지 않으려면 Add-MailboxDatabaseCopy cmdlet을 실행할 때 SeedingPostponed 매개 변수를 사용할 수 있습니다.

최초의 시드가 발생한 후 데이터베이스 복사본을 다시 시드해야 하는 일은 거의 없습니다. 그러나 다시 시드해야 할 상황이거나, 시스템에서 자동으로 복사본을 시드하게 하는 대신 데이터베이스 복사본을 수동으로 시드하려면 EAC에서 사서함 데이터베이스 복사본 업데이트 마법사를 사용하거나 셸에서 Update-MailboxDatabaseCopy cmdlet을 사용하여 이 작업을 수행할 수 있습니다. 데이터베이스 복사본을 시드하기 전에 먼저 사서함 데이터베이스 복사본을 일시 중단해야 합니다. 데이터베이스 복사본을 시드하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 업데이트을 참조하십시오.

수동 시드 작업이 완료된 후에는 시드된 사서함 데이터베이스 복사본에 대한 복제가 자동으로 다시 시작됩니다. 복제가 자동으로 다시 시작되지 않게 하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 ManualResume 매개 변수를 사용합니다.

시드 대상 선택

시드 작업을 수행할 때 사서함 데이터베이스 복사본이나 사서함 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그 중 하나, 또는 데이터베이스 복사본과 콘텐츠 인덱스 카탈로그 복사본 둘 다를 시드하도록 선택할 수 있습니다.

사서함 데이터베이스 복사본 업데이트 마법사 및 Update-MailboxDatabaseCopy cmdlet의 기본 동작은 사서함 데이터베이스 복사본과 콘텐츠 인덱스 카탈로그 복사본 모두를 시드하는 것입니다. 콘텐츠 인덱스 카탈로그를 시드하지 않고 사서함 데이터베이스 복사본만 시드하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 DatabaseOnly 매개 변수를 사용합니다. 콘텐츠 인덱스 카탈로그 복사본만 시드하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 CatalogOnly 매개 변수를 사용합니다.

시드 원본 선택

정상 상태인 데이터베이스 복사본을 이 데이터베이스의 추가 복사본에 대한 시드 원본으로 사용할 수 있습니다. 이것은 DAG가 여러 물리적 위치에 확장되어 있는 경우에 특히 유용합니다. 예를 들어 두 구성원(MBX1과 MBX2)은 Oregon 주의 Portland에 있고 두 구성원(MBX3과 MBX4)은 New York 주의 New York에 있는 네 구성원 DAG 배포를 가정해 보겠습니다. DB1이라는 사서함 데이터베이스가 MBX1에서 활성 상태이고 DB1의 수동 복사본이 MBX2 및 MBX3에 있습니다. DB1의 복사본을 MBX4에 추가할 때는 MBX3의 복사본을 시드 원본으로 사용할 수 있습니다. 이렇게 하면 Portland와 New York 간의 WAN 링크를 통한 시드를 피할 수 있습니다.

새 데이터베이스 복사본을 추가할 때 특정 복사본을 시드 원본으로 사용하려면 다음과 같은 작업을 수행합니다.

Add-MailboxDatabaseCopy cmdlet을 실행할 때 SeedingPostponed 매개 변수를 사용하여 데이터베이스 복사본을 추가합니다. SeedingPostponed 매개 변수를 사용하지 않으면 데이터베이스의 활성 복사본을 원본으로 사용하여 데이터베이스 복사본이 명시적으로 시드됩니다.
EAC에서 사서함 데이터베이스 복사 업데이트 마법사의 일부로 사용할 원본 서버를 지정하거나 Update-MailboxDatabaseCopy cmdlet을 실행할 때 SourceServer 매개 변수를 사용하여 시드할 원본 서버를 지정할 수 있습니다. 앞의 예에서는 MBX3을 원본 서버로 지정합니다. SourceServer 매개 변수를 사용하지 않으면 데이터베이스 복사본은 데이터베이스의 활성 복사본에서 명시적으로 시드됩니다.

시드 및 네트워크

사서함 데이터베이스 복사본 시드를 위한 특정 원본 서버를 선택할 수 있을 뿐만 아니라, 셸을 사용하여 사용하고자 하는 DAG 네트워크를 지정할 수도 있고 시드 작업 중에 DAG 네트워크의 압축 및 암호화 설정을 다시 정의할 수도 있습니다.

참고

컨텍스트 인덱스 카탈로그를 시드하는 것은 MAPI 네트워크를 통해서만 가능합니다. Update-MailboxDatabaseCopy cmdlet에서 매개 변수를 -Network 사용하는 경우에도 마찬가지입니다.

시드에 사용할 네트워크를 지정하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 Network 매개 변수를 사용하고 사용할 DAG 네트워크를 지정합니다. Network 매개 변수를 사용하지 않는 경우 시스템은 시드 작업에 사용할 네트워크를 선택하는 데 다음과 같은 기본 동작을 사용합니다.

원본 서버와 대상 서버가 같은 서브넷에 있고 이 서브넷을 포함하는 복제 네트워크가 구성되어 있는 경우 복제 네트워크가 사용됩니다.
원본 서버와 대상 서버가 서로 다른 서브넷에 있는 경우 이들 서브넷을 포함하는 복제 네트워크가 구성되어 있더라도 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.
원본 서버와 대상 서버가 서로 다른 데이터 센터에 있는 경우 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.

DAG 수준에서, 암호화 및 압축을 위해 DAG 네트워크가 구성됩니다. 기본 설정은 다른 서브넷의 통신에만 암호화와 압축을 사용하는 것입니다. 원본 및 대상이 서로 다른 서브넷에 있고 DAG가 NetworkCompression 및 NetworkEncryption에 대한 기본값을 사용하여 구성되어 있다면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 NetworkCompressionOverride 및 NetworkEncryptionOverride 매개 변수를 각각 사용하여 이 값을 다시 정의할 수 있습니다.

시드 프로세스

Add-MailboxDatabaseCopy 또는 Update-MailboxDatabaseCopy cmdlet을 사용하여 시드 프로세스를 시작할 경우 다음 작업이 수행됩니다.

지정된 데이터베이스 및 서버를 확인하기 위해, 그리고 원본 및 대상 서버가 Active Directory을 실행 중인지, 둘 다 같은 DAG의 구성원인지, 지정된 데이터베이스가 복구 데이터베이스가 아닌지를 확인하기 위해 Exchange 2013에서 데이터베이스 속성을 읽습니다. 또한 데이터베이스 파일 경로도 읽습니다.
대상 서버의 Microsoft Exchange 복제 서비스에서 다시 시드 확인을 위한 준비 작업이 수행됩니다.
대상 서버의 Microsoft Exchange 복제 서비스가 1단계에서 Active Directory 확인을 위해 읽은 파일 디렉터리에 데이터베이스와 트랜잭션 로그가 있는지 확인합니다.
Microsoft Exchange 복제 서비스가 대상 서버로부터 cmdlet을 실행한 관리 인터페이스로 상태 정보를 반환합니다.
모든 사전 검사를 통과하면 작업을 계속할지 확인하는 메시지가 표시됩니다. 작업을 계속하기로 선택하면 프로세스가 계속됩니다. 사전 검사 중 오류가 발생할 경우 오류가 보고되고 작업이 실패합니다.
시드 작업이 대상 서버의 Microsoft Exchange 복제 서비스에서 시작됩니다.
Microsoft Exchange 복제 서비스가 활성 데이터베이스 복사본의 데이터베이스 복제를 일시 중단합니다.
데이터베이스에 대한 상태 정보가 시드 상태를 반영하도록 Microsoft Exchange 복제 서비스에 의해 업데이트됩니다.
대상 서버에 대상 데이터베이스 및 로그 파일을 위한 디렉터리가 없으면 새로 만들어집니다.
데이터베이스 시드 요청이 TCP를 사용하여 대상 서버의 Microsoft Exchange 복제 서비스에서 원본 서버의 Microsoft Exchange 복제 서비스로 전달됩니다. 이 요청 및 데이터베이스 시드를 위한 이후 통신은 복제 네트워크로 구성된 DAG 네트워크에서 일어납니다.
원본 서버의 Microsoft Exchange 복제 서비스가 Microsoft Exchange 정보 저장소 인터페이스를 통해 ESE(Extensible Storage Engine) 스트리밍 백업을 시작합니다.
Microsoft Exchange 정보 저장소 서비스가 데이터베이스 데이터를 Microsoft Exchange 복제 서비스로 스트리밍합니다.
데이터베이스 데이터가 원본 서버의 Microsoft Exchange 복제 서비스에서 대상 서버의 Microsoft Exchange 복제 서비스로 이동합니다.
대상 서버의 Microsoft Exchange 복제 서비스는 임시 시드라는 주 데이터베이스 디렉터리에 있는 임시 디렉터리에 데이터베이스 복사본을 씁니다.
데이터베이스의 끝에 도달하면 원본 서버의 스트리밍 백업 작업이 끝납니다.
대상 서버에서의 쓰기 작업이 완료되고 데이터베이스가 temp-seeding 디렉터리에서 최종 위치로 이동합니다. temp-seeding 디렉터리가 삭제됩니다.
대상 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스로 요청을 프록시 처리하여 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그가 있는 경우 이를 탑재합니다. 데이터베이스 복사본의 이전 인스턴스의 오래된 기존 카탈로그 파일이 있는 경우 탑재 작업이 실패하고, 이로 인해 원본 서버로부터 카탈로그를 복제해야 합니다. 마찬가지로, 대상 서버에 있는 데이터베이스 복사본의 새 인스턴스에 카탈로그가 없는 경우 카탈로그의 복제본이 필요합니다. Microsoft Exchange 복제 서비스는 원본에서 새 카탈로그가 복사되는 동안 데이터베이스 복사본에 대한 인덱싱을 일시 중단하도록 Microsoft Exchange 검색 서비스에 지시합니다.
대상 서버의 Microsoft Exchange 복제 서비스가 원본 서버의 Microsoft Exchange 복제 서비스로 카탈로그 시드 요청을 보냅니다.
원본 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스에 디렉터리 정보를 요청하고 해당 인덱싱의 일시 중단을 요청합니다.
원본 서버의 Microsoft Exchange 검색 서비스가 검색 카탈로그 디렉터리 정보를 Microsoft Exchange 복제 서비스에 반환합니다.
원본 서버의 Microsoft Exchange 복제 서비스가 디렉터리에서 카탈로그 파일을 읽습니다.
원본 서버의 Microsoft Exchange 복제 서비스가 복제 네트워크 내 연결을 사용하여 대상 서버의 Microsoft Exchange 복제 서비스로 카탈로그 데이터를 이동합니다. 읽기가 완료되면 Microsoft Exchange 복제 서비스는 원본 데이터베이스의 인덱싱을 다시 시작하기 위해 Microsoft Exchange 검색 서비스에 요청을 보냅니다.
디렉터리의 대상 서버에 기존 카탈로그 파일이 있는 경우 대상 서버의 Microsoft Exchange 복제 서비스가 이를 삭제합니다.
대상 서버의 Microsoft Exchange 복제 서비스는 데이터가 완전히 전송될 때까지 CiSeed.Temp 라는 임시 디렉터리에 카탈로그 데이터를 씁니다.
Microsoft Exchange 복제 서비스가 완전한 카탈로그 데이터를 최종 위치로 이동합니다.
대상 서버의 Microsoft Exchange 복제 서비스가 대상 데이터베이스의 검색 인덱싱을 다시 시작합니다.
대상 서버의 Microsoft Exchange 복제 서비스가 완료 상태를 반환합니다.
이 작업의 최종 결과가 cmdlet을 호출한 관리 인터페이스로 전달됩니다.

데이터베이스 복사본 구성

데이터베이스 복사본이 만들어진 후, 필요한 경우 그 구성 설정을 보거나 수정할 수 있습니다. EAC에서 데이터베이스 복사본의 속성 페이지를 확인하면 일부 구성 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabase 및 Set-MailboxDatabaseCopy cmdlet을 사용하여 재생 지연 시간, 자르기 지연 시간 및 활성화 기본 설정 순서 등의 데이터베이스 복사본 설정을 보거나 구성할 수 있습니다. 데이터베이스 복사본 설정을 보거나 구성하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 속성 구성을 참조하십시오.

재생 지연 및 자르기 지연 옵션 사용

사서함 데이터베이스 복사본은 재생 지연 시간 및 자르기 지연 시간 또는 모두를 분 단위로 구성하여 사용하도록 지원합니다. 재생 지연 시간을 설정하면 데이터베이스 복사본을 특정 시점으로 되돌릴 수 있습니다. 자르기 지연 시간을 설정하면 수동 데이터베이스 복사본의 로그를 사용하여 활성 데이터베이스 복사본의 로그 파일 손실로부터 복구할 수 있습니다. 이러한 기능 모두는 임시 작성 로그 파일을 만들기 때문에 해당 기능을 사용하면 저장소 디자인에 영향을 미칩니다.

재생 지연 시간

재생 지연 시간은 데이터베이스 복사본에 대한 로그 재생을 지연하기 위해 분 단위로 시간을 지정하는 사서함 데이터베이스 복사본의 속성입니다. 재생 지연 타이머는 로그 파일이 수동 복사본에 복제되고 검사를 통과했을 때 시작됩니다. 데이터베이스 복사본에서 로그 재생을 지연하면 데이터베이스를 과거의 특정 시점으로 복구할 수 있습니다. 재생 지연 시간이 0보다 길게 구성된 사서함 데이터베이스 복사본은 지연된 데이터베이스 복사본 또는 간단히 지연된 복사본이라고 합니다.

Exchange 2013에서 데이터베이스 복사본 및 소송 보존 기능을 사용하는 전략은 일반적으로 데이터 손실을 유발하는 다양한 오류에 대한 보호를 제공할 수 있습니다. 그러나 이러한 기능은 드물지만 데이터 손실을 유발할 수 있는 논리적 손상이 발생할 경우 데이터 손실에 대한 보호를 제공할 수 없습니다. 지연된 복사본은 논리적 손상의 경우 데이터 손실을 방지하도록 설계되었습니다. 일반적으로 다음과 같은 두 가지 유형의 논리적 손상이 있습니다.

데이터베이스 논리 손상: 데이터베이스 페이지 체크섬이 일치하지만 페이지의 데이터가 논리적으로 잘못되었습니다. 이러한 손상은 ESE가 데이터베이스 페이지 쓰기를 시도할 경우에 발생하며, 운영 체제에서 성공 메시지가 반환되더라도 이 데이터를 디스크에 쓰지 않았거나 잘못된 위치에 쓴 것입니다. 이를 손실 플러시라고 합니다. 데이터 손실로부터 손실 플러시를 방지하기 위해, ESE는 데이터베이스에 페이지 패치 기능(단일 페이지 복원)과 함께 손실 플러시 감지 메커니즘을 포함합니다.
논리 손상 저장: 사용자가 예상하지 않는 방식으로 데이터가 추가, 삭제 또는 조작됩니다. 이러한 경우는 일반적으로 타사 애플리케이션에 의해 발생합니다. 일반적으로 사용자가 손상으로 간주한다는 점에서만 손상입니다. Exchange 저장소는 논리 손상을 생성한 트랜잭션을 일련의 유효한 MAPI 작업으로 간주합니다. Exchange 2013의 소송 보존 기능은 사용자 또는 애플리케이션에서 콘텐츠를 영구적으로 삭제할 수 없으므로 저장소 논리적 손상으로부터 보호합니다. 그러나 사용자 사서함이 손상되어 손상되기 전 특정 시점으로 데이터베이스를 복원한 다음 사용자 사서함을 내보내서 손상되지 않은 데이터를 검색하는 것이 더 쉬울 수 있는 시나리오가 있을 수 있습니다.

데이터베이스 복사본, 보존 정책, ESE 단일 페이지 복원을 조합하여 함께 사용하는 것은 드물게 발생하지만 매우 치명적인 저장소 논리적 손상인 경우로 제한합니다. 데이터베이스 복사본에 재생 지연(지연된 복사본)을 사용할지 여부는 어떤 타사 응용 프로그램을 사용하는지와 조직에 어떤 저장소 논리적 손상이 발생했었는지에 따라 결정합니다.

지연된 복사본은 특정 시나리오에서 로그 파일을 재생하기 위해 자동 로그 재생을 호출할 때 Exchange 2013에서 직접 처리할 수 있습니다.

디스크 공간 부족 임계값에 도달할 경우
지연된 복사본에 물리적인 손상 부분이 있어 페이지를 패치해야 하는 경우
정상 상태의 사용 가능한 복사본(활성 또는 수동만 포함하며 지연된 데이터베이스 복사본은 계산에서 제외)이 24시간 이상 동안 3개 미만인 경우

페이지 패치는 이 자동 플레이 다운 기능을 통해 지연된 복사본에 사용할 수 있습니다. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다.

지연된 복사본 재생 동작은 기본적으로 사용하지 않도록 설정되어 있으며 다음 명령을 실행하면 이를 사용하도록 설정할 수 있습니다.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

재생 동작을 사용하도록 설정한 후 복사본 수가 3개 미만이면 재생이 발생합니다. 다음 DWORD 레지스트리 값을 수정하면 기본값 3을 변경할 수 있습니다.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

디스크 공간 부족 임계값에 도달할 경우 재생을 사용하도록 설정하려면 다음 레지스트리 항목을 추가로 구성해야 합니다.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

이러한 레지스트리 설정을 구성한 후에 Microsoft Exchange DAG Management Service를 다시 시작하여 변경 내용을 적용합니다.

예를 들어 지정된 데이터베이스에 4개의 복사본(고가용성 복사본 3개 및 지연된 복사본 1개)이 있고 기본 설정이 ReplayLagManagerNumAvailableCopies에 사용되는 환경을 고려합니다. 지연되지 않은 복사본이 어떤 이유(예: 일시 중단 등)로 인해 작동되지 않으면 지연된 복사본이 24시간 후에 자동으로 로그 파일을 재생합니다.

매개 변수를 사용하지 않고 지연된 복사본을 ReplayLagManagerEnabled 사용하도록 선택하는 경우 다음과 같은 의미에 유의하세요.

재생 지연 시간은 관리자가 구성하는 값이며 기본적으로 사용하지 않도록 설정되어 있습니다.
재생 지연 시간 설정은 기본적으로 0일이며, 최대 설정은 14일입니다.
지연된 복사본은 항상 사용 가능한 복사본으로 간주되지 않습니다. 대신, 저장소 논리적 손상으로부터 데이터를 보호하기 위해 재해 복구용으로 설계되었습니다.
재생 지연 시간을 크게 설정할수록 데이터베이스 복구 프로세스가 길어집니다. 복구하는 동안 재생해야 할 로그 파일의 수, 하드웨어가 로그 파일을 재생하는 속도에 따라 데이터베이스를 복구하는 데 수시간 또는 수일이 소요될 수도 있습니다.
지연된 복사본이 전반적인 재해 복구 전략에 반드시 필요한지 여부를 결정합니다. 재해 복구 전략에 지연된 복사본 사용이 필수적이면 지연된 복사본 여러 개를 사용하고, 만약 지연된 복사본이 하나뿐인 경우에는 RAID(Redundant Array of Independent Disks)를 사용하여 이 복사본을 보호하는 것이 좋습니다. 디스크가 손실되거나 손상이 발생하더라도 지연된 시점이 보존됩니다.
지연된 복사본은 ESE 단일 페이지 복원 기능에 패치되지 않습니다. 지연된 복사본에 데이터베이스 손상(예: a -1018 오류)이 발생하면 복사본의 지연된 부분이 손실되므로 다시 시드해야 합니다.

데이터베이스에서 모든 로그 파일을 재생하고 데이터베이스 복사본을 최신 상태로 만들려는 경우 지연된 사서함 데이터베이스 복사본을 활성화하고 복구하는 프로세스가 간단합니다. 로그 파일을 특정 시점까지 재생하려면 수동으로 로그 파일을 조작하고 Eseutil(Exchange Server Database Utilities) 도구를 실행해야 하기 때문에 작업이 더 복잡해집니다.

지연된 사서함 데이터베이스 복사본을 활성화하는 방법에 대한 자세한 단계는 지연된 사서함 데이터베이스 복사본 활성화를 참조하세요.

자르기 지연 시간

자르기 지연 시간은 로그 파일이 데이터베이스 복사본에 재생된 후 데이터베이스 복사본에 대한 로그 삭제를 지연하기 위해 분 단위로 시간을 지정하는 사서함 데이터베이스 복사본의 속성입니다. 자르기 지연 타이머는 로그 파일이 수동 복사본에 복제되고 검사를 통과한 후 데이터베이스 복사본에 재생되었을 때 시작됩니다. 데이터베이스 복사본에서 로그 파일 자르기를 지연하면 데이터베이스의 활성 복사본에 대한 로그 파일에 영향을 준 오류로부터 복구할 수 있습니다.

데이터베이스 복사본 및 로그 잘라내기

로그 잘림은 Exchange 2010에서와 마찬가지로 Exchange 2013에서도 동일하게 작동합니다. 자르기 동작은 복사본에 대한 재생 지연 시간 및 자르기 지연 시간 설정에 의해 결정됩니다.

지연 설정이 기본값 0(사용하지 않도록 설정)보다 왼쪽에 있는 값을 갖는 경우 데이터베이스 복사본의 로그 파일을 자르려면 다음 조건을 충족해야 합니다.

로그 파일을 성공적으로 백업했거나, 순환 로깅을 사용하도록 설정되어 있어야 합니다.
로그 파일이 데이터베이스에 대한 검사점(복구에 필요한 최소 로그 파일) 아래에 있어야 합니다.
다른 모든 지연된 복사본에 검사를 마친 로그 파일이 있어야 합니다.
지연된 복사본이 아닌 다른 모든 복사본이 로그 파일을 재생했어야 합니다.

지연된 데이터베이스 복사본에 대한 자르기가 수행되려면 다음 조건을 충족해야 합니다.

로그 파일이 데이터베이스의 검사점 아래에 있어야 합니다.
로그 파일이 ReplayLagTime + TruncationLagTime보다 오래된 것이어야 합니다.
로그 파일이 활성 복사본에서 잘렸어야 합니다.

Exchange 2013에서는 수동 복사본이 하나 이상 일시 중단되어 있으면 활성 사서함 데이터베이스 복사본에서 로그를 자르지 않습니다. 계획된 유지 관리 작업이 오래 계속된 경우(예를 들면 며칠) 상당한 양의 로그 파일이 쌓일 수 있습니다. 트랜잭션 로그로 로그 드라이브가 꽉 차지 않게 하려면 해당 수동 데이터베이스 복사본을 일시 중단하는 대신 제거합니다. 계획된 유지 관리가 완료되면 수동 데이터베이스 복사본을 다시 추가할 수 있습니다.

Exchange 2013 SP1(서비스 팩 1)에는 기본적으로 사용하지 않도록 설정되는 느슨한 잘림이라는 새로운 기능이 도입되었습니다. 정상 작동 중에는 데이터베이스의 모든 복사본이 재생(수동 복사본) 또는 수신(지연된 복사본)되었음을 확인할 때까지 각 데이터베이스 복사본에서 다른 데이터베이스 복사본에 전달해야 하는 로그가 유지됩니다. 이는 기본 로그 잘라내기 동작입니다. 데이터베이스 복사본이 특정 사유로 인해 오프라인 상태로 전환되면 데이터베이스의 다른 복사본에서 사용하는 디스크에 로그 파일이 누적되기 시작합니다. 영향을 받는 데이터베이스 복사본이 연장된 기간 동안 오프라인 상태로 유지되면 이로 인해 다른 데이터베이스 복사본의 디스크 공간이 부족해질 수 있습니다.

느슨한 자르기가 사용하도록 설정된 경우에는 자르기 동작이 달라집니다. 각 데이터베이스 복사본이 자체 사용 가능한 디스크 공간을 추적한 다음 사용 가능한 공간이 부족해지면 느슨한 자르기 동작이 적용됩니다. 활성 복사본의 경우에는 가장 오래된 지연 복사본, 즉 로그 재생에서 맨 끝에 있는 수동 데이터베이스 복사본이 무시되고 남아 있는 가장 오래된 수동 복사본이 자르기에 사용됩니다. 전역 자르기는 활성 데이터베이스 복사본에서 계산됩니다. 수동 복사본은 활성 복사본에 대한 자르기 결정을 사용합니다. 자르기에서 사용되는 매개 변수의 이름이 MinCopiesToProtect이기는 하지만 Exchange에서는 자르기를 실행할 때 가장 오래된 것으로 확인된 지연 복사본만 무시합니다. 수동 복사본의 경우에는 공간이 부족해지면 아래에 설명되어 있는 구성된 매개 변수를 사용하여 로그 파일을 독립적으로 자릅니다.

오프라인 데이터베이스가 다시 온라인 상태가 되면 다른 정상 복사본에서 삭제된 로그 파일이 누락되고 데이터베이스 복사 상태가 FailedAndSuspended가 됩니다. 이 이벤트에서 Autoreseed가 구성된 경우 영향을 받는 복사본의 크기가 자동으로 다시 지정됩니다. Autoreseed가 구성되지 않은 경우 관리자가 데이터베이스 복사본을 수동으로 시드해야 합니다.

필요한 정상 상태 복사본 수, 사용 가능한 디스크 공간 임계값 및 유지할 로그 수는 모두 구성 가능한 매개 변수입니다. 기본적으로 사용 가능한 디스크 공간 임계값은 204,800MB(200GB)이고 유지할 로그 수는 수동 복사본에 필요한 100,000개(100GB) 및 활성 복사본에 필요한 10,000개(10GB)입니다.

느슨한 잘라내기를 사용하도록 설정하고 느슨한 잘라내기 매개 변수를 구성하려면 각 DAG 구성원에 대한 Windows 레지스트리를 편집하면 됩니다. 구성할 수 있는 세 가지 레지스트리 값이 있습니다. 이 값은 모두 아래에 HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation저장됩니다. DWORD 값 뒤의 BackupInformation 키는 기본적으로 존재하지 않으며 수동으로 만들어야 합니다. BackupInformation 아래의 DWORD 레지스트리 값은 다음 표에서 설명되어 있습니다.

레지스트리 값	설명	기본값
LooseTruncation_MinCopiesToProtect	이 키는 느슨한 잘림을 사용하도록 설정하는 데 사용됩니다. 데이터베이스의 활성 복사본에서 느슨한 잘림으로부터 보호하기 위한 수동 복사본 수를 나타냅니다. 이 키의 값을 0으로 설정하면 느슨한 잘림이 비활성화됩니다.	0
LooseTruncation_MinDiskFreeSpaceThresholdInMB	느슨한 자르기를 트리거하는 사용 가능한 디스크 공간(MB) 임계값입니다. 사용 가능한 디스크 공간이 이 값 아래로 떨어지면 느슨한 잘라내기가 트리거됩니다.	이 레지스트리 값을 구성하지 않으면 느슨한 자르기에 사용되는 기본값은 200GB입니다.
LooseTruncation_MinLogsToProtect	로그를 자를 정상 상태 복사본에서 유지할 로그 파일의 최소 개수입니다. 이 레지스트리 값을 구성하면 구성된 값이 활성 복사본과 수동 복사본에 모두 적용됩니다.	이 레지스트리 값을 구성하지 않으면 활성 데이터베이스 복사본에 대한 기본값 100,000개와 활성 데이터베이스 복사본에 대한 기본값 10,000개가 사용됩니다.

레지스트리 값을 사용하는 LooseTruncation_MinLogsToProtect 경우 활성 및 수동 데이터베이스 복사본의 동작이 다릅니다. 활성 데이터베이스 복사본에서 보호된 수동 복사본 및 활성 복사본의 필수 범위 앞에 유지되는 추가 로그의 수입니다. 수동 데이터베이스 복사본에서 이 로그는 사용 가능한 최신 로그에서 유지 관리되는 로그 수입니다. 이 숫자의 10분의 1은 이 수동 복사본의 필수 범위 이전에 로그를 유지하는 데도 사용됩니다. 필요한 범위가 일반적으로 매우 크기 때문에 지연된 데이터베이스 복사본이 너무 많은 공간을 차지하지 않도록 하기 위해 두 가지 제한이 적용됩니다.

데이터베이스 활성화 정책

사서함 데이터베이스 복사본을 만들거나 오류 발생 시 시스템에서 해당 복사본을 자동으로 활성화하지 않으려는 경우가 있을 수 있습니다.

하나 이상의 사서함 데이터베이스 복사본을 대체 데이터 센터 또는 대기 데이터 센터로 배포하는 경우
복구를 위해 지연된 데이터베이스 복사본을 구성하는 경우
서버의 유지 관리 또는 업그레이드를 수행하는 경우

앞에 나온 각 시나리오에서, 시스템에 의해 자동으로 활성화되지 않아야 할 데이터베이스 복사본이 있습니다. 시스템이 사서함 데이터베이스 복사본을 자동으로 활성화하지 않게 하기 위해, 활성화가 차단(일시 중단)되도록 복사본을 구성할 수 있습니다. 이렇게 하면 시스템은 로그 전달 및 재생을 통해 데이터베이스의 현재 상태를 유지하면서 시스템이 복사본을 자동으로 활성화하고 사용하는 것을 방지합니다. 활성화가 차단된 복사본은 관리자가 수동으로 활성화해야 합니다. Set-MailboxServer cmdlet 또는 Set-MailboxDatabaseCopy cmdlet을 사용하여 DatabaseCopyAutoActivationPolicy 매개 변수를 Blocked로 설정하여 전체 서버에 대한 데이터베이스 활성화 정책을 구성할 수 있습니다.

데이터베이스 활성화 정책 구성에 대한 자세한 내용은 사서함 데이터베이스 복사본에 대 한 정품 인증 정책 구성 항목을 참조하십시오.

연속 복제에서 사서함 이동의 영향

로그 생성 속도가 높고 작업량이 매우 많은 사서함 데이터베이스에서는 수동 데이터베이스 복사본으로의 복제가 로그 생성 속도를 따라가지 못할 경우 데이터 손실의 가능성이 커집니다. 로그 생성 속도가 높아질 수 있는 한 가지 시나리오는 사서함 이동입니다. Exchange 2013에는 시스템 또는 관리자가 설정한 DataMoveReplicationConstraint 매개 변수 값을 기반으로 데이터베이스 복사 아키텍처의 상태를 확인하기 위해 MRS(Microsoft Exchange Mailbox Replication Service)와 같은 서비스에서 사용하는 데이터 보장 API가 포함되어 있습니다. 데이터 보장 API는 다음과 같은 용도로 사용할 수 있습니다.

복제 상태 확인: 필수 구성 요소 수의 데이터베이스 복사본을 사용할 수 있는지 확인합니다.
복제 플러시 확인: 필수 로그 파일이 필수 구성 요소의 데이터베이스 복사본 수에 대해 재생되었는지 확인합니다.

API가 실행되면 호출 응용 프로그램에 다음과 같은 상태 정보를 반환합니다.

다시 시도: 데이터베이스에 대해 조건을 검사하지 못하게 하는 일시적인 오류가 있음을 의미합니다.
만족: 데이터베이스가 필요한 조건을 충족하거나 데이터베이스가 복제되지 않음을 의미합니다.
NotSatisfied: 데이터베이스가 필요한 조건을 충족하지 않음을 의미합니다. 또한 NotSatisfied 응답이 반환된 이유에 대한 정보가 호출 응용 프로그램에 제공됩니다.

사서함 데이터베이스에 대한 DataMoveReplicationConstraint 매개 변수 값은 요청의 일부로 평가해야 하는 데이터베이스 복사본 수를 결정합니다. DataMoveReplicationConstraint 매개 변수에는 다음과 같은 가능한 값이 있습니다.

None: 사서함 데이터베이스를 만들 때 이 값은 기본적으로 설정됩니다. 이 값을 설정하면 데이터 보장 API 조건은 무시됩니다. 이 설정은 복제되지 않은 사서함 데이터베이스에만 사용해야 합니다.
SecondCopy: 사서함 데이터베이스의 두 번째 복사본을 추가할 때 기본값입니다. 이 값을 설정한 경우 최소 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족해야 합니다.
SecondDatacenter: 이 값을 설정하면 다른 Active Directory 사이트의 수동 데이터베이스 복사본이 하나 이상 데이터 보장 API 조건을 충족해야 합니다.
AllDatacenters: 이 값을 설정하면 각 Active Directory 사이트에서 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족해야 합니다.
AllCopies: 이 값을 설정하면 사서함 데이터베이스의 모든 복사본이 데이터 보장 API 조건을 충족해야 합니다.

복제 상태 확인

데이터베이스 복사본 인프라의 상태를 평가하기 위해 데이터 보장 API가 실행될 경우 몇 개의 항목이 평가됩니다.

DataMoveReplicationConstraint 매개 변수가 로 설정된 경우...	그런 다음, 지정된 데이터베이스의 경우...	조건
`SecondCopy`	복제된 데이터베이스에 대한 하나 이상의 수동 데이터베이스 복사본이 다음 열의 조건을 충족해야 합니다.	수동 데이터베이스 복사본은 정상 상태여야 합니다. 재생 큐가 재생 지연 시간의 10분 내에 있어야 합니다. 복사 큐 길이가 10개 로그 미만이어야 합니다. 평균 복사 큐 길이가 10개 로그 미만이어야 합니다. 평균 복사 큐 길이는 응용 프로그램이 데이터베이스 상태를 쿼리한 횟수를 기반으로 계산됩니다.
`SecondDatacenter`	다른 Active Directory 사이트에서 최소 하나 이상의 수동 데이터베이스 복사본이 다음 열의 조건을 충족해야 합니다.
`AllDatacenters`	활성 복사본이 탑재되어야 하며 각 Active Directory 사이트의 수동 복사본이 다음 열의 조건을 충족해야 합니다.
`AllCopies`	활성 복사본이 탑재되어야 하며 모든 수동 데이터베이스 복사본이 다음 열의 조건을 충족해야 합니다.

복제 플러시 확인

데이터 보장 API는 필수 데이터베이스 복사본 수가 필요한 트랜잭션 로그를 재생했는지 확인하는 데도 사용할 수 있습니다. 이를 확인하려면 마지막 로그 재생 타임스탬프를 호출 서비스의 커밋 타임스탬프(대개의 경우 필요한 데이터가 포함된 마지막 로그 파일의 타임스탬프)에 5초를 더한(시스템 시간 시계 편차를 처리하기 위해) 값과 비교합니다. 재생 타임스탬프가 커밋 타임스탬프보다 크면 DataMoveReplicationConstraint 매개 변수가 충족됩니다. 재생 타임스탬프가 커밋 타임스탬프보다 작으면 DataMoveReplicationConstraint 가 충족되지 않습니다.

DAG 내의 복제 데이터베이스 간에 많은 수의 사서함을 이동하기 전에 다음 사항에 따라 각 사서함 데이터베이스에서 DataMoveReplicationConstraint 매개 변수를 구성하는 것이 좋습니다.

배포하는 경우...	DataMoveReplicationConstraint를 ...로 설정합니다.
데이터베이스 복사본이 없는 사서함 데이터베이스	`None`
단일 Active Directory 사이트 내의 DAG	`SecondCopy`
확장된 Active Directory 사이트를 사용하는 여러 데이터 센터의 DAG	`SecondCopy`
두 Active Directory 사이트에 걸쳐 있는 DAG, 각 사이트마다 고가용성 데이터베이스 복사본이 있음	`SecondDatacenter`
두 Active Directory 사이트에 걸쳐 있는 DAG, 두 번째 사이트에 지연된 데이터베이스 복사본만 있음	`SecondCopy` 이렇게 설정하는 이유는 로그 파일이 데이터베이스 복사본으로 재생되기 전에는 데이터 보장 API가 데이터의 커밋을 보증하지 않기 때문이며, 지연된 데이터베이스 복사본 ReplayLagTime 시간이 30분 미만인 경우 외에는 지연된 데이터베이스 복사본의 특성으로 인해 이와 같은 제약 조건에서는 이동 요청이 실패합니다.
세 개 이상의 Active Directory 사이트에 걸쳐 있는 DAG, 각 사이트는 고가용성 데이터베이스 복사본을 포함	`AllDatacenters`

데이터베이스 복사본 균형 조정

DAG의 고유한 특성으로 인해 데이터베이스 전환 및 장애 조치(failover)의 결과로 활성 사서함 데이터베이스 복사본은 DAG의 수명 동안 여러 번 호스트를 변경합니다. 결과적으로 DAG는 활성 사서함 데이터베이스 복사본 배포 측면에서 불균형하게 될 수 있습니다. 다음 표에서는 활성 데이터베이스 복사본이 균등하게 배포되지 않은 각 데이터베이스의 복사본 4개가 포함된 4개의 데이터베이스(각 서버에서 총 16개의 데이터베이스)가 있는 DAG의 예를 보여 줍니다.

활성 복사본이 불균형하게 배포된 DAG

서버	의 수 활성 데이터베이스	의 수 수동 데이터베이스	의 수 탑재된 데이터베이스	기본 설정 카운트 목록
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

앞의 예제에는 각 데이터베이스의 복사본이 4개 있으므로 활성화 기본 설정(1, 2, 3 또는 4)에 대해 가능한 값은 4개뿐입니다. 기본 설정 수 목록 열에는 이러한 각 값이 있는 데이터베이스 수의 수가 표시됩니다. 예를 들어 EX3에는 활성화 기본 설정이 1인 데이터베이스 복사본 13개, 활성화 기본 설정이 2인 복사본 2개, 활성화 기본 설정이 3인 복사본 1개, 활성화 기본 설정이 4인 복사본이 없습니다.

표시된 것처럼, 이 DAG는 각 DAG 구성원이 호스트하는 활성 데이터베이스 수, 각 DAG 구성원이 호스트하는 수동 데이터베이스 수 또는 호스트된 데이터베이스의 활성화 기본 설정 카운트를 고려하여 균형이 조정되지 않았습니다.

RedistributeActiveDatabases.ps1 스크립트를 사용하여 활성 사서함 데이터베이스 복사본을 DAG 간에 균형 조정할 수 있습니다. DAG의 각 서버에서 탑재된 데이터베이스 수가 동일하게 되도록 하기 위해 이 스크립트는 해당 복사본 간에 데이터베이스를 이동합니다. 또한 필요한 경우 이 스크립트는 사이트 간에 활성 데이터베이스를 균형 있게 조정하려고 시도합니다.

이 스크립트는 DAG 내에서 활성 데이터베이스 복사본을 균형 있게 조정하기 위한 두 가지 옵션을 제공합니다.

BalanceDbsByActivationPreference: 이 옵션을 지정하면 스크립트는 Active Directory 사이트에 관계없이 데이터베이스를 가장 선호하는 복사본(활성화 기본 설정 기준)으로 이동하려고 시도합니다.
BalanceDbsBySiteAndActivationPreference: 이 옵션을 지정하면 스크립트는 활성 데이터베이스를 가장 선호하는 복사본으로 이동하면서 각 Active Directory 사이트 내에서 활성 데이터베이스의 균형을 유지하려고 시도합니다.

첫 번째 옵션으로 스크립트를 실행하면 다음 표에서와 같이 위의 불균형한 DAG가 균형 있게 조정됩니다.

활성 복사본이 균형 있게 배포된 DAG

서버	의 수 활성 데이터베이스	의 수 수동 데이터베이스	의 수 탑재된 데이터베이스	기본 설정 카운트 목록
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

위의 표에서와 같이 이 DAG는 이제 각 서버의 활성 및 수동 데이터베이스 수와 서버 간에 활성화 기본 설정을 고려하여 균형 있게 조정되었습니다.

다음 표에서는 RedistributeActiveDatabases.ps1 스크립트에 사용할 수 있는 매개 변수를 보여 줍니다.

RedistributeActiveDatabases.ps1 스크립트 매개 변수

매개 변수	설명
DagName	균형을 다시 조정하려는 DAG 이름을 지정합니다. 이 매개 변수를 생략하면 로컬 서버가 구성원으로 속한 DAG가 사용됩니다.
BalanceDbsByActivationPreference	스크립트가 Active Directory 사이트와 관계없이 데이터베이스를 가장 선호하는 복사본으로 이동하도록 지정합니다.
BalanceDbsBySiteAndActivationPreference	스크립트가 활성 데이터베이스를 가장 선호하는 복사본으로 이동하면서 각 Active Directory 사이트 내에서 활성 데이터베이스의 균형을 유지하도록 지정합니다.
ShowFinalDatabaseDistribution	재배포가 완료되면 현재 데이터베이스 배포 보고서가 표시되도록 지정합니다.
AllowedDeviationFromMeanPercentage	백분율로 표시되는 사이트 간에 활성 데이터베이스의 허용되는 변형을 지정합니다. 기본값은 20%입니다. 예를 들어 세 개의 사이트 간에 배포된 99개의 데이터베이스가 있는 경우 적절한 배포는 각 사이트에서 33개의 데이터베이스입니다. 허용되는 편차가 20%인 경우 스크립트가 데이터베이스를 균형 있게 조정하려고 시도하므로 각 사이트에는 이 수의 10% 정도가 있어야 합니다. 33의 10%는 3.3이며 4로 반올림됩니다. 따라서 스크립트는 각 사이트에 29개에서 37개의 데이터베이스가 있도록 시도합니다.
ShowDatabaseCurrentActives	스크립트가 데이터베이스를 이동한 방법 및 가장 선호되는 복사본에서 데이터베이스가 지금 활성화되어 있는지 여부를 자세히 나타내는 각 데이터베이스의 보고서를 생성하도록 지정합니다.
ShowDatabaseDistributionByServer	스크립트가 데이터베이스 배포를 나타내는 각 서버의 보고서를 생성하도록 지정합니다.
RunOnlyOnPAM	스크립트가 현재 PAM 역할이 있는 DAG 구성원에서만 실행되도록 지정합니다. 스크립트가 PAM에서 실행되고 있는지 확인합니다. PAM에서 실행되고 있지 않은 경우 스크립트가 종료됩니다.
LogEvents	스크립트가 작업 요약을 포함하여 이벤트(MsExchangeRepl 이벤트 4115)를 기록하도록 지정합니다.
IncludeNonReplicatedDatabases	스크립트가 활성 데이터베이스를 다시 배포하는 방법 결정 시 복제되지 않은 데이터베이스(복사본이 없는 데이터베이스)를 포함하도록 지정합니다. 복제되지 않은 데이터베이스는 이동될 수 없지만 복제된 데이터베이스 배포에 영향을 줄 수 있습니다.
확인	Confirm 스위치를 사용하면 이 스크립트를 실행할 때 기본적으로 나타나는 확인 메시지를 표시하지 않을 수 있습니다. 확인 메시지를 표시하지 않으려면 -Confirm:$False 구문을 사용합니다. 구문에 콜론(: )을 포함해야 합니다.

RedistributeActiveDatabases.ps1 예

이 예는 기본 설정 카운트 목록을 포함하여 DAG에 대한 현재 데이터베이스 배포를 보여 줍니다.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

이 예는 입력을 요청하지 않고 활성 기본 설정을 사용하여 DAG에서 활성 사서함 데이터베이스 복사본을 다시 배포하고 균형 있게 조정합니다.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

이 예는 활성 기본 설정을 사용하여 DAG에서 활성 사서함 데이터베이스 복사본을 다시 배포하고 균형 있게 조정하며 배포 요약을 생성합니다.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

데이터베이스 복사본 모니터링

데이터베이스 복사본은 데이터베이스의 활성 복사본에 영향을 주는 오류가 발생할 경우 첫 번째 방어 수단입니다. 따라서 필요할 때 사용할 수 있으려면 데이터베이스 복사본의 상태를 모니터링하는 것이 중요합니다. EAC에서 데이터베이스 복사본의 상세 정보를 확인하면 복사 큐 길이, 재생 큐 길이, 상태 및 콘텐츠 인덱스 상태 정보를 포함한 다양한 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabaseCopyStatus cmdlet을 사용하여 데이터베이스 복사본의 다양한 상태 정보를 볼 수도 있습니다.

데이터베이스 복사본 모니터링에 대한 자세한 내용은 데이터베이스 가용성 그룹 모니터링을 참조하세요.

데이터베이스 복사본 제거

EAC를 사용하거나 셸에서 Remove-MailboxDatabaseCopy cmdlet을 사용하여 데이터베이스 복사본을 언제든지 제거할 수 있습니다. 데이터베이스 복사본을 제거한 후에는 데이터베이스 복사본을 제거하고 있는 서버에서 모든 데이터베이스 및 트랜잭션 로그 파일을 수동으로 삭제해야 합니다. 데이터베이스 복사본을 제거하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본을 제거 합니다.를 참조하십시오.

데이터베이스 전환

데이터베이스의 활성 복사본을 호스트하는 사서함 서버를 사서함 데이터베이스 마스터라고 합니다. 수동 데이터베이스 복사본을 활성화하는 프로세스는 데이터베이스의 사서함 데이터베이스 마스터를 변경시키고 수동 복사본을 새로운 활성 복사본으로 전환합니다. 이 프로세스를 데이터베이스 전환이라고 합니다. 데이터베이스 전환에서는 데이터베이스의 활성 복사본이 특정 사서함 서버에서 분리되고, 해당 데이터베이스의 수동 복사본이 새 활성 사서함 데이터베이스로 다른 사서함 서버에 탑재됩니다. 전환을 수행할 때 새 사서함 데이터베이스 마스터에서 데이터베이스 탑재 다이얼 설정을 다시 정의할 수 있습니다.

EAC의 데이터베이스 복사본 탭에서 오른쪽 열을 확인하여 어떤 사서함 서버가 현재 사서함 데이터베이스 마스터인지 신속하게 알아볼 수 있습니다. EAC에서 활성화 링크를 사용하거나 셸에서 Move-ActiveMailboxDatabase cmdlet을 사용하여 전환을 수행할 수 있습니다.

수동 복사본을 활성화하기 전에 수행될 몇몇 내부 검사가 있습니다.

데이터베이스 복사본의 상태를 확인합니다. 데이터베이스 복사본이 실패 상태이면 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipHealthChecks 매개 변수를 사용하여 이 동작을 재정의하고 상태 검사를 무시할 수 있습니다. 이 매개 변수는 활성 복사본을 실패 상태인 데이터베이스 복사본으로 이동하는 데 사용됩니다.
활성 데이터베이스 복사본이 현재 데이터베이스의 수동 복사본에 대한 시드 원본인지 여부를 검사합니다. 활성 복사본이 현재 시드 원본으로 사용 중인 경우에는 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipActiveCopyChecks 매개 변수를 사용하여 이 동작을 재정의하고 시드 원본 검사를 무시할 수 있습니다. 이 매개 변수를 사용하면 시드 원본으로 사용 중인 활성 복사본을 이동할 수 있습니다. 이 매개 변수를 사용할 경우 시드 작업이 취소되고 실패한 것으로 간주됩니다.
데이터베이스 복사본의 복사 큐와 재생 큐 길이를 검사하여 그 값이 구성된 기준 내에 있는지 확인합니다. 또한 데이터베이스 복사본이 시드를 위한 원본으로 현재 사용되고 있지 않은지 확인합니다. 큐 길이에 대한 값이 구성된 기준을 벗어나거나 데이터베이스가 시드를 위한 원본으로 현재 사용 중이면 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipLagChecks 매개 변수를 사용하여 이 동작을 재정의하고 이러한 검사를 무시할 수 있습니다. 이 매개 변수는 구성된 기준을 벗어나는 재생 큐 및 복사 큐가 있는 복사본을 활성화하는 데 사용됩니다.
데이터베이스 복사본의 검색 카탈로그 상태(콘텐츠 인덱스)를 확인합니다. 검색 카탈로그가 최신 상태가 아니거나, 비정상 상태이거나, 손상된 경우 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipClientExperienceChecks 매개 변수를 사용하여 이 동작을 재정의하고 검색 카탈로그 검사를 무시할 수 있습니다. 이 매개 변수는 이 검색이 카탈로그 상태 검사를 건너뛰게 하는 데 사용됩니다. 활성화할 데이터베이스 복사본의 검색 카탈로그가 비정상이거나 사용할 수 없는 상태인 경우 이 매개 변수를 사용하여 카탈로그 상태 검사를 건너뛰고 데이터베이스 복사본을 활성화하면 검색 카탈로그를 다시 크롤링하거나 시드해야 합니다.

데이터베이스 전환을 수행할 때 현재 활성화되어 있는 수동 데이터베이스 복사본을 호스트하는 서버에 구성된 탑재 다이얼 설정을 다시 정의할 수 있습니다. Move-ActiveMailboxDatabase cmdlet의 MountDialOverride 매개 변수를 사용하면 대상 서버에 자체 탑재 다이얼 설정을 재정의하고 MountDialOverride 매개 변수에 지정된 설정을 사용하도록 지시합니다.

데이터베이스 복사본 전환을 수행하는 방법의 자세한 단계는 사서함 데이터베이스 복사본 활성화 항목을 참조하십시오.

다음을 통해 공유