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

Exchange Server DAG(데이터베이스 가용성 그룹)를 만들고 구성하고 사서함 서버 구성원으로 채운 후 EAC(Exchange 관리 콘솔) 또는 Exchange 관리 셸을 사용하여 사서함 데이터베이스 복사본을 추가할 수 있습니다.

데이터베이스 복사본 관리

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

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

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

데이터베이스 복사본 시드

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

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

데이터베이스 복사본은 초기 시드 후 다시 시드할 필요가 거의 없습니다. 그러나 다시 시드가 필요하거나 시스템이 복사본을 자동으로 시드하는 대신 데이터베이스 복사본을 수동으로 시드하려는 경우 두 가지 옵션이 있습니다. EAC에서 사서함 데이터베이스 복사 업데이트 마법사를 사용하거나 Exchange 관리 셸에서 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 매개 변수를 사용하지 않는 경우 데이터베이스 복사본은 데이터베이스의 활성 복사본에서 명시적으로 시드됩니다.

시드 및 네트워크

사서함 데이터베이스 복사본을 시드하기 위한 특정 원본 서버를 선택하는 것 외에도 Exchange 관리 셸을 사용하여 사용할 DAG 네트워크를 지정할 수도 있습니다. 시드 작업 중에 DAG 네트워크의 압축 및 암호화 설정을 재정의하는 옵션이 있습니다.

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

• 원본 서버와 대상 서버가 같은 서브넷에 있고 이 서브넷을 포함하는 복제 네트워크가 구성되어 있는 경우 복제 네트워크가 사용됩니다.

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

• 원본 서버와 대상 서버가 서로 다른 데이터 센터에 있는 경우 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.

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

시드 프로세스

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

1. Active Directory의 데이터베이스 속성은 지정된 데이터베이스 및 서버의 유효성을 검사하고 원본 및 대상 서버가 Exchange Server 실행 중인지 확인하기 위해 동일한 DAG의 멤버이며 지정된 데이터베이스가 복구 데이터베이스가 아닌지 확인합니다. 또한 데이터베이스 파일 경로도 읽습니다.

2. 대상 서버의 Microsoft Exchange 복제 서비스에서 다시 시드 확인을 위한 준비 작업이 수행됩니다.

3. 대상 서버의 Microsoft Exchange 복제 서비스가 1단계에서 Active Directory 확인을 위해 읽은 파일 디렉터리에 데이터베이스와 트랜잭션 로그가 있는지 확인합니다.

4. Microsoft Exchange 복제 서비스가 대상 서버로부터 cmdlet을 실행한 관리 인터페이스로 상태 정보를 반환합니다.

5. 모든 사전 검사를 통과하면 작업을 계속할지 확인하는 메시지가 표시됩니다. 작업을 계속하기로 선택하면 프로세스가 계속됩니다. 사전 검사 중 오류가 발생할 경우 오류가 보고되고 작업이 실패합니다.

6. 시드 작업이 대상 서버의 Microsoft Exchange 복제 서비스에서 시작됩니다.

7. Microsoft Exchange 복제 서비스가 활성 데이터베이스 복사본의 데이터베이스 복제를 일시 중단합니다.

8. 데이터베이스에 대한 상태 정보가 시드 상태를 반영하도록 Microsoft Exchange 복제 서비스에 의해 업데이트됩니다.

9. 대상 서버에 대상 데이터베이스 및 로그 파일을 위한 디렉터리가 없으면 새로 만들어집니다.

10. 데이터베이스 시드 요청이 TCP를 사용하여 대상 서버의 Microsoft Exchange 복제 서비스에서 원본 서버의 Microsoft Exchange 복제 서비스로 전달됩니다. 이 요청 및 데이터베이스 시드를 위한 이후 통신은 복제 네트워크로 구성된 DAG 네트워크에서 일어납니다.

11. 원본 서버의 Microsoft Exchange 복제 서비스가 Microsoft Exchange 정보 저장소 인터페이스를 통해 ESE(Extensible Storage Engine) 스트리밍 백업을 시작합니다.

12. Microsoft Exchange 정보 저장소 서비스가 데이터베이스 데이터를 Microsoft Exchange 복제 서비스로 스트리밍합니다.

13. 데이터베이스 데이터가 원본 서버의 Microsoft Exchange 복제 서비스에서 대상 서버의 Microsoft Exchange 복제 서비스로 이동합니다.

14. 대상 서버의 Microsoft Exchange 복제 서비스는 임시 시드라는 주 데이터베이스 디렉터리에 있는 임시 디렉터리에 데이터베이스 복사본을 씁니다.

15. 데이터베이스의 끝에 도달하면 원본 서버의 스트리밍 백업 작업이 끝납니다.

16. 대상 서버에서의 쓰기 작업이 완료되고 데이터베이스가 temp-seeding 디렉터리에서 최종 위치로 이동합니다. temp-seeding 디렉터리가 삭제됩니다.

17. 대상 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스로 요청을 프록시 처리하여 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그가 있는 경우 이를 탑재합니다. 데이터베이스 복사본의 이전 인스턴스의 오래된 기존 카탈로그 파일이 있는 경우 탑재 작업이 실패하고, 이로 인해 원본 서버로부터 카탈로그를 복제해야 합니다. 마찬가지로, 대상 서버에 있는 데이터베이스 복사본의 새 인스턴스에 카탈로그가 없는 경우 카탈로그의 복제본이 필요합니다. Microsoft Exchange 복제 서비스는 원본에서 새 카탈로그가 복사되는 동안 데이터베이스 복사본에 대한 인덱싱을 일시 중단하도록 Microsoft Exchange 검색 서비스에 지시합니다.

18. 대상 서버의 Microsoft Exchange 복제 서비스가 원본 서버의 Microsoft Exchange 복제 서비스로 카탈로그 시드 요청을 보냅니다.

19. 원본 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스에 디렉터리 정보를 요청하고 해당 인덱싱의 일시 중단을 요청합니다.

20. 원본 서버의 Microsoft Exchange 검색 서비스가 검색 카탈로그 디렉터리 정보를 Microsoft Exchange 복제 서비스에 반환합니다.

21. 원본 서버의 Microsoft Exchange 복제 서비스가 디렉터리에서 카탈로그 파일을 읽습니다.

22. 원본 서버의 Microsoft Exchange 복제 서비스가 복제 네트워크 내 연결을 사용하여 대상 서버의 Microsoft Exchange 복제 서비스로 카탈로그 데이터를 이동합니다. 읽기가 완료되면 Microsoft Exchange 복제 서비스는 원본 데이터베이스의 인덱싱을 다시 시작하기 위해 Microsoft Exchange 검색 서비스에 요청을 보냅니다.

23. 디렉터리의 대상 서버에 기존 카탈로그 파일이 있는 경우 대상 서버의 Microsoft Exchange 복제 서비스가 이를 삭제합니다.

24. 대상 서버의 Microsoft Exchange 복제 서비스는 데이터가 완전히 전송될 때까지 CiSeed.Temp 라는 임시 디렉터리에 카탈로그 데이터를 씁니다.

25. Microsoft Exchange 복제 서비스가 완전한 카탈로그 데이터를 최종 위치로 이동합니다.

26. 대상 서버의 Microsoft Exchange 복제 서비스가 대상 데이터베이스의 검색 인덱싱을 다시 시작합니다.

27. 대상 서버의 Microsoft Exchange 복제 서비스가 완료 상태를 반환합니다.

28. 이 작업의 최종 결과가 cmdlet을 호출한 관리 인터페이스로 전달됩니다.

데이터베이스 복사본 구성

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

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

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

재생 지연 시간

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

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

• 데이터베이스 논리 손상: 데이터베이스 페이지 체크섬이 일치하지만 페이지의 데이터가 논리적으로 잘못되었습니다. 이러한 손상은 ESE가 데이터베이스 페이지 쓰기를 시도할 경우에 발생하며, 운영 체제에서 성공 메시지가 반환되더라도 이 데이터를 디스크에 쓰지 않았거나 잘못된 위치에 쓴 것입니다. 이를 손실 플러시라고 합니다. 데이터 손실로부터 손실 플러시를 방지하기 위해, ESE는 데이터베이스에 페이지 패치 기능(단일 페이지 복원)과 함께 손실 플러시 감지 메커니즘을 포함합니다.

• 논리 손상 저장: 사용자가 예상하지 않는 방식으로 데이터가 추가, 삭제 또는 조작됩니다. 이러한 경우는 일반적으로 타사 애플리케이션에 의해 발생합니다. 일반적으로 사용자가 손상으로 간주한다는 점에서만 손상입니다. Exchange 저장소는 논리 손상을 생성한 트랜잭션을 일련의 유효한 MAPI 작업으로 간주합니다. Exchange Server 소송 보존 기능은 사용자 또는 애플리케이션에 의해 콘텐츠가 영구적으로 삭제되지 않도록 하기 때문에 저장소 논리적 손상으로부터 보호합니다. 그러나 사용자 사서함이 손상되어 손상되기 전 특정 시점으로 데이터베이스를 복원한 다음 사용자 사서함을 내보내서 손상되지 않은 데이터를 검색하는 것이 더 쉬울 수 있는 시나리오가 있을 수 있습니다.

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

지연된 복사본을 사용하기로 선택하면 다음 의미를 알아야 합니다.

• 재생 지연 시간은 관리자가 구성하는 값이며 기본적으로 사용하지 않도록 설정되어 있습니다.

• 재생 지연 시간 설정은 기본적으로 0일이며, 최대 설정은 14일입니다.

• 지연된 복사본은 항상 사용 가능한 복사본으로 간주되지 않습니다. 대신, 저장소 논리적 손상으로부터 데이터를 보호하기 위해 재해 복구용으로 설계되었습니다.

• 재생 지연 시간을 크게 설정할수록 데이터베이스 복구 프로세스가 길어집니다. 복구하는 동안 재생해야 할 로그 파일의 수, 하드웨어가 로그 파일을 재생하는 속도에 따라 데이터베이스를 복구하는 데 수시간 또는 수일이 소요될 수도 있습니다.

• 지연된 복사본이 전반적인 재해 복구 전략에 반드시 필요한지 여부를 결정합니다. 재해 복구 전략에 지연된 복사본 사용이 필수적이면 지연된 복사본 여러 개를 사용하고, 만약 지연된 복사본이 하나뿐인 경우에는 RAID(Redundant Array of Independent Disks)를 사용하여 이 복사본을 보호하는 것이 좋습니다. 디스크가 손실되거나 손상이 발생하더라도 지연된 시점이 보존됩니다.

• 지연된 복사본은 ESE 단일 페이지 복원 기능으로 패치할 수 없습니다. 지연된 복사본에 데이터베이스 페이지 손상이 발생하는 경우(예: -1018 오류) 복사본을 다시 설정해야 합니다. 다시 시딩하면 복사본의 지연된 측면이 손실됩니다.

데이터베이스가 모든 로그 파일을 재생하고 데이터베이스 복사를 최신 상태로 만들도록 하려면 지연된 사서함 데이터베이스 복사본을 활성화하고 복구하는 것은 쉬운 프로세스입니다. 특정 시점까지 로그 파일을 재생하려는 경우 로그 파일을 수동으로 조작하고 데이터베이스 유틸리티(Eseutil.exe)를 Exchange Server 실행해야 하기 때문에 프로시전이 더 어렵습니다.

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

자르기 지연 시간

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

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

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

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

• 로그 파일을 성공적으로 백업했거나, 순환 로깅을 사용하도록 설정되어 있어야 합니다.

• 로그 파일이 데이터베이스에 대한 검사점(복구에 필요한 최소 로그 파일) 아래에 있어야 합니다.

• 다른 모든 지연된 복사본에 검사를 마친 로그 파일이 있어야 합니다.

• 다른 모든 복사본(지연된 복사본 제외)은 로그 파일을 재생해야 합니다.

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

• 로그 파일이 데이터베이스의 검사점 아래에 있어야 합니다.

• 로그 파일이 ReplayLagTime + TruncationLagTime보다 오래된 것이어야 합니다.

• 로그 파일이 활성 복사본에서 잘렸어야 합니다.

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

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

잘림 동작은 느슨한 잘림 및 순환 로깅을 사용하는 경우 다릅니다. 각 데이터베이스 복사본이 자체 사용 가능한 디스크 공간을 추적한 다음 사용 가능한 공간이 부족해지면 느슨한 자르기 동작이 적용됩니다.

• 활성 복사본의 경우에는 가장 오래된 지연 복사본, 즉 로그 재생에서 맨 끝에 있는 수동 데이터베이스 복사본이 무시되고 남아 있는 가장 오래된 수동 복사본이 자르기에 사용됩니다. 전역 자르기는 활성 데이터베이스 복사본에서 계산됩니다.

• 수동 복사의 경우 공간이 낮아지면 레지스트리 값 테이블의 뒷부분에 설명된 구성된 매개 변수를 사용하여 로그 파일을 독립적으로 자립니다. 수동 복사본은 활성 복사본에 대한 잘림 결정을 존중하려고 시도합니다. 자르기에서 사용되는 매개 변수의 이름이 MinCopiesToProtect이기는 하지만 Exchange에서는 자르기를 실행할 때 가장 오래된 것으로 확인된 지연 복사본만 무시합니다.

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

순환 로깅을 사용하지 않도록 설정한 경우 느슨한 잘림은 백업이 수행된 경우 백업을 준수하므로 로그가 백업되지 않은 경우 느슨한 잘림으로 제거되지 않습니다.

잘림은 백업이 사용되지 않고 순환 로깅이 사용되는 기본 아키텍처에 권장되는 기능입니다.

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

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

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

데이터베이스 활성화 정책

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

• 하나 이상의 사서함 데이터베이스 복사본을 대체 데이터 센터 또는 대기 데이터 센터로 배포하는 경우

• 복구를 위해 지연된 데이터베이스 복사본을 구성하는 경우

• 유지 관리 또는 서버 업그레이드를 수행하는 경우

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

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

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

로그 생성 속도가 높고 작업량이 매우 많은 사서함 데이터베이스에서는 수동 데이터베이스 복사본으로의 복제가 로그 생성 속도를 따라가지 못할 경우 데이터 손실의 가능성이 커집니다. 로그 생성 속도가 높아질 수 있는 한 가지 시나리오는 사서함 이동입니다. Exchange Server 시스템 또는 관리자가 설정한 DataMoveReplicationConstraint 매개 변수 값을 기반으로 데이터베이스 복사 아키텍처의 상태를 확인하기 위해 MRS(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가 실행될 경우 몇 개의 항목이 평가됩니다.

모든 시나리오에서 수동 데이터베이스 복사는 다음 조건을 충족해야 합니다.

• 정상 상태여야 합니다.

• 재생 큐가 재생 지연 시간의 10분 내에 있어야 합니다.

• 복사 큐 길이가 10개 로그 미만이어야 합니다.

• 평균 복사 큐 길이가 10개 로그 미만이어야 합니다. 평균 복사 큐 길이는 응용 프로그램이 데이터베이스 상태를 쿼리한 횟수를 기반으로 계산됩니다.

복제 플러시 확인

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

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

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

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

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

앞의 예제에는 각 데이터베이스의 복사본이 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

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

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

RedistributeActiveDatabases.ps1 스크립트 매개 변수

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에서 데이터베이스 복사본의 상세 정보를 확인하면 복사 큐 길이, 재생 큐 길이, 상태 및 콘텐츠 인덱스 상태 정보를 포함한 다양한 정보를 볼 수 있습니다. Exchange 관리 셸에서 Get-MailboxDatabaseCopyStatus cmdlet을 사용하여 데이터베이스 복사본에 대한 다양한 상태 정보를 볼 수도 있습니다.

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

데이터베이스 복사본 제거

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

데이터베이스 전환

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

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

수동 복사가 활성화되기 전에 수행되는 몇 가지 내부 검사가 있습니다. 경우에 따라 데이터베이스 전환이 차단되거나 취소됩니다. 다른 경우에는 cmdlet을 사용하여 일부 검사를 이동하거나 건너뛸 수 있습니다.

• 데이터베이스 복사본의 상태를 확인합니다. 데이터베이스 복사본이 실패 상태이면 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipHealthChecks 매개 변수를 사용하여 이 동작을 재정의하고 상태 검사를 무시할 수 있습니다. 이 매개 변수를 사용하면 활성 복사본을 실패한 상태의 데이터베이스 복사본으로 이동할 수 있습니다.

• 활성 데이터베이스 복사본이 현재 데이터베이스의 수동 복사본에 대한 시드 원본인지 여부를 검사합니다. 활성 복사본이 현재 시드 원본으로 사용 중인 경우에는 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipActiveCopyChecks 매개 변수를 사용하여 이 동작을 재정의하고 시드 원본 검사를 무시할 수 있습니다. 이 매개 변수를 사용하면 시드 원본으로 사용 중인 활성 복사본을 이동할 수 있습니다. 이 매개 변수를 사용할 경우 시드 작업이 취소되고 실패한 것으로 간주됩니다.

• 데이터베이스 복사본의 복사 큐와 재생 큐 길이를 검사하여 그 값이 구성된 기준 내에 있는지 확인합니다. 또한 데이터베이스 복사본이 시드를 위한 원본으로 현재 사용되고 있지 않은지 확인합니다. 큐 길이에 대한 값이 구성된 기준을 벗어나거나 데이터베이스가 시드를 위한 원본으로 현재 사용 중이면 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipLagChecks 매개 변수를 사용하여 이 동작을 재정의하고 이러한 검사를 무시할 수 있습니다. 이 매개 변수는 구성된 기준을 벗어나는 재생 큐 및 복사 큐가 있는 복사본을 활성화하는 데 사용됩니다.

• 데이터베이스 복사본의 검색 카탈로그 상태(콘텐츠 인덱스)를 확인합니다. 검색 카탈로그가 최신 상태가 아니거나, 비정상 상태이거나, 손상된 경우 전환이 차단됩니다. Move-ActiveMailboxDatabase cmdlet의 SkipClientExperienceChecks 매개 변수를 사용하여 이 동작을 재정의하고 검색 카탈로그 검사를 무시할 수 있습니다. 이 매개 변수는 이 검색이 카탈로그 상태 검사를 건너뛰게 하는 데 사용됩니다. 활성화할 데이터베이스 복사본의 검색 카탈로그가 비정상이거나 사용할 수 없는 상태인 경우 이 매개 변수를 사용하여 카탈로그 상태 검사를 건너뛰고 데이터베이스 복사본을 활성화하면 검색 카탈로그를 다시 크롤링하거나 시드해야 합니다.

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

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