다음을 통해 공유

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

  • 아티클

적용 대상: Exchange Server 2010

마지막으로 수정된 항목: 2010-01-25

데이터베이스 이동성은 저장소 그룹 개념을 없애고 사서함 서버에서Exchange 2010 사서함 데이터베이스를 분리하는 Microsoft Exchange Server 2010의 새로운 아키텍처입니다. 저장소 그룹이 Exchange 2010에서 제거되었으므로 이제 연속 복제는 데이터베이스 수준에서 수행됩니다. Exchange 2010에서는 트랜잭션 로그가 하나 이상의 사서함 서버로 복제되고, 해당 서버에 저장된 하나 이상의 사서함 데이터베이스 복제본에 재생됩니다. Exchange Server 2007 연속 복제에 사용된 여러 개념은 Exchange 2010에서도 그대로 사용됩니다. 여기에는 확산 개념, 자동 데이터베이스 탑재 다이얼 사용, 공용 및 개인 네트워크 사용 등이 포함됩니다.

데이터베이스 복사본 관리

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

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

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

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

데이터베이스 복사 시드

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

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

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

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

시드 대상 선택

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

시드 원본 선택

Exchange 2007에서는 연속 복제가 데이터베이스의 활성 복사본을 복사하여 데이터베이스 복사본을 시드하는 것만 가능했습니다. Exchange 2010에서는 정상 상태인 데이터베이스 복사본을 이 데이터베이스의 추가 복사본에 대한 시드 원본으로 사용할 수 있습니다. 이것은 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 매개 변수를 사용하지 않으면 데이터베이스 복사본은 해당 데이터베이스의 활성 복사본을 원본으로 사용하여 명시적으로 시드됩니다.
  • Update-MailboxDatabaseCopy cmdlet을 실행할 때 SourceServer 매개 변수를 사용하고 시드에 사용할 원본 서버를 지정합니다. (앞의 예에서는 MBX3을 원본 서버로 지정합니다.) SourceServer 매개 변수를 사용하지 않으면 데이터베이스 복사본은 해당 데이터베이스의 활성 복사본을 원본으로 사용하여 명시적으로 시드됩니다.

시드 및 네트워크

사서함 데이터베이스 복사본 시드를 위한 특정 원본 서버를 선택하는 것뿐 아니라, 사용할 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. 지정된 데이터베이스 및 서버를 확인하기 위해, 그리고 원본 및 대상 서버가 Exchange 2010을 실행 중인지, 둘 다 같은 DAG의 구성원인지, 지정된 데이터베이스가 복구 데이터베이스가 아닌지를 확인하기 위해 Active Directory에서 데이터베이스 속성을 읽습니다. 또한 데이터베이스 파일 경로도 읽습니다.
  2. 대상 서버의 Microsoft Exchange 복제 서비스에서 다시 시드 확인을 위한 준비 작업이 수행됩니다.
  3. 대상 서버의 Microsoft Exchange 복제 서비스가 1단계에서 Active Directory 확인을 위해 읽은 파일 디렉터리에 데이터베이스와 트랜잭션 로그가 있는지 확인합니다.
  4. Microsoft Exchange 복제 서비스가 대상 서버로부터 cmdlet을 실행한 관리 인터페이스로 상태 정보를 반환합니다.
  5. 모든 사전 검사를 통과하면 작업을 계속할지 확인하는 메시지가 표시됩니다. 작업을 계속하기로 선택하면 프로세스가 계속됩니다. 사전 검사 중 오류가 발생할 경우 오류가 보고되고 작업이 실패합니다.
  6. 시드 작업이 대상 서버의 Microsoft Exchange 복제 서비스에서 시작됩니다.
  7. Microsoft Exchange 복제 서비스가 활성 데이터베이스 복사본의 데이터베이스 복제를 일시 중단합니다.
  8. 데이터베이스에 대한 상태 정보가 시드 상태를 반영하도록 Microsoft Exchange 복제 서비스에 의해 업데이트됩니다.
  9. 대상 서버에 대상 데이터베이스 및 로그 파일을 위한 디렉터리가 없으면 새로 만들어집니다. 디렉터리가 이미 있고 이 대상 디렉터리에 기존 데이터베이스 파일이나 로그 파일이 있으면 Microsoft Exchange 복제 서비스가 이를 삭제합니다.
  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 복제 서비스는 temp-seeding이라는 주 데이터베이스 디렉터리에 있는 임시 디렉터리에 데이터베이스 복사본을 씁니다.
  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을 호출한 관리 인터페이스로 전달됩니다.

데이터베이스 복사본 구성

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

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

사서함 데이터베이스 복사본은 재생 지연 시간 및 자르기 지연 시간 또는 모두를 분 단위로 구성하여 사용하도록 지원합니다. 재생 지연 시간을 설정하면 데이터베이스 복사본을 특정 시점으로 되돌릴 수 있습니다. 자르기 지연 시간을 설정하면 수동 데이터베이스 복사본의 로그를 사용하여 활성 데이터베이스 복사본의 로그 파일 손실로부터 복구할 수 있습니다.

재생 지연 시간

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

Exchange 2010의 데이터베이스 복사본과 법적 보유 기능을 사용하는 전략은 일반적으로 데이터 손실을 초래할 수 있는 오류로부터 데이터를 보호합니다. 그러나 이러한 기능은 드물기는 하지만 논리적 손상으로 데이터가 손실되는 경우에는 데이터를 보호할 수 없습니다. 지연된 복사본은 논리적 손상으로부터 데이터 손실을 막기 위해 설계되었으며, 논리적 손상에는 일반적으로 두 가지 유형이 있습니다.

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

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

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

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

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

지연된 사서함 데이터베이스 복사본을 활성화하는 자세한 단계는 지연된 사서함 데이터베이스 복사본 활성화를 참조하십시오.

자르기 지연 시간

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

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

Exchange 2010의 로그 잘라내기는 Exchange 2007에서와 동일한 방식으로 작동합니다. 자르기 동작은 복사본에 대한 재생 지연 시간 및 자르기 지연 시간 설정에 의해 결정됩니다.

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

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

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

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

데이터베이스 활성화 정책

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

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

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

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

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

데이터베이스 복사본은 데이터베이스의 활성 복사본에 영향을 주는 오류가 발생할 경우 첫 번째 방어 수단입니다. 따라서 필요할 때 사용할 수 있으려면 데이터베이스 복사본의 상태를 모니터링하는 것이 중요합니다. EMC에서 데이터베이스 복사본의 속성 페이지를 확인하면 일부 상태 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabaseCopyStatus cmdlet을 사용하여 데이터베이스 복사본의 다양한 상태 정보를 볼 수도 있습니다.

데이터베이스 복사본 모니터링에 대한 자세한 내용은 고가용성 및 사이트 복구 모니터링를 참조하십시오.

데이터베이스 복사본 제거

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

데이터베이스 전환

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

EMC의 데이터베이스 복사본 탭에서 복사본 상태 열을 확인하여 어떤 사서함 서버가 현재 사서함 데이터베이스 마스터인지 신속하게 알아볼 수 있습니다. 활성 복사본만 탑재 상태를 갖게 됩니다. 다른 모든 데이터베이스 복사본은 데이터베이스 복사본의 현재 복제 상태를 표시합니다. EMC에서 사서함 데이터베이스 마스터 이동 마법사를 사용하거나 셸에서 Move-ActiveMailboxDatabase cmdlet을 사용하여 전환을 수행할 수 있습니다.

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

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

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

데이터베이스 복사본 전환을 수행하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 활성화를 참조하십시오. 데이터베이스 전환에 대한 자세한 내용은 전환 및 장애 조치를 참조하십시오.