사서함 데이터베이스 복사본 관리Managing mailbox database copies

적용 대상: Exchange Server 2013Applies to: Exchange Server 2013

사서함 서버 구성원으로 DAG (데이터베이스 사용 가능 그룹)를 만들고 구성 하 고 채운 후 EAC (Exchange 관리 센터) 또는 Exchange 관리 셸을 사용 하 여 사서함 데이터베이스 복사본을 유연 하 고 세밀 한 방식으로 추가할 수 있습니다.After a database availability group (DAG) has been created, configured, and populated with Mailbox server members, you can use the Exchange admin center (EAC) or the Exchange Management Shell to add mailbox database copies in a flexible and granular way.

데이터베이스 복사본 관리Managing database copies

데이터베이스의 복사본이 여러 개 만들어진 후에는 EAC 또는 셸을 사용하여 각 복사본의 상태를 모니터링하고 데이터베이스 복사본과 관련된 다른 관리 작업을 수행할 수 있습니다. 이러한 관리 작업에는 데이터베이스 복사본 일시 중단 또는 다시 시작, 데이터베이스 복사본 시드, 데이터베이스 복사본 모니터링, 데이터베이스 복사본 설정 구성, 데이터베이스 복사본 제거 등이 있습니다.After multiple copies of a database are created, you can use the EAC or the Shell to monitor the health and status of each copy and to perform other management tasks associated with database copies. Some of the management tasks you may need to perform include suspending or resuming a database copy, seeding a database copy, monitoring database copies, configuring database copy settings, and removing a database copy.

데이터베이스 복사본 일시 중단 및 다시 시작Suspending and resuming database copies

계획한 유지 관리 수행 같은 다양한 이유로, 데이터베이스 복사본에 대한 연속 복제 작업을 일시 중단하고 다시 시작해야 할 경우가 있습니다. 또한 시드 등의 일부 관리 작업에서는 먼저 데이터베이스 복사를 일시 중단해야 합니다. 데이터베이스의 경로 또는 그 로그 파일을 변경할 경우 모든 복제 작업을 일시 중단하는 것이 좋습니다. EAC를 사용하거나 셸에서 Suspend-MailboxDatabaseCopyResume-MailboxDatabaseCopy cmdlet을 실행하여 데이터베이스 복사본 작업을 일시 중단하고 다시 시작할 수 있습니다. 데이터베이스 복사본의 연속 복제 작업을 일시 중단하거나 다시 시작하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본을 다시 시작 또는 일시 중단을 참조하십시오.For a variety of reasons, such as performing planned maintenance, it may be necessary to suspend and resume continuous replication activity for a database copy. In addition, some administrative tasks, such as seeding, require you to first suspend a database copy. We recommend that all replication activity be suspended when the path for the database or its log files is being changed. You can suspend and resume database copy activity by using the EAC, or by running the Suspend-MailboxDatabaseCopy and Resume-MailboxDatabaseCopy cmdlets in the Shell. For detailed steps about how to suspend or resume continuous replication activity for a database copy, see Suspend or resume a mailbox database copy.

데이터베이스 복사본 시드Seeding a database copy

업데이트라고도 하는 시드는 빈 데이터베이스 또는 프로덕션 데이터베이스의 복사본인 데이터베이스가 활성 데이터베이스와 동일한 DAG에 있는 다른 사서함 서버의 대상 복사 위치에 추가되는 과정을 말합니다. 이는 해당 서버에서 유지 관리되는 복사본에 대한 기준 데이터베이스가 됩니다.Seeding, also known as updating, is the process in which a database, either a blank database or a copy of the production database, is added to the target copy location on another Mailbox server in the same DAG as the active database. This becomes the baseline database for the copy maintained by that server.

상황에 따라 시드를 자동으로 진행하거나 사용자가 수동으로 시작할 수 있습니다.Depending on the situation, seeding can be an automatic process or a manual process that you initiate. 데이터베이스 복사본이 추가되면, 이 복사본은 대상 서버와 저장소가 적절히 구성되어 있는 경우 자동으로 시드됩니다.When a database copy is added, the copy will be automatically seeded, provided that the target server and its storage are properly configured. 데이터베이스 복사본을 수동으로 시드해야 하 고 복사본을 만들 때 자동 시드가 발생 하지 않게 하려면 update-mailboxdatabasecopy cmdlet을 실행할 때 SeedingPostponed 매개 변수를 사용 하면 됩니다.If you want to manually seed a database copy and don't want automatic seeding to occur when creating the copy, you can use the SeedingPostponed parameter when running the Add-MailboxDatabaseCopy cmdlet.

최초의 시드가 발생한 후 데이터베이스 복사본을 다시 시드해야 하는 일은 거의 없습니다. 그러나 다시 시드해야 할 상황이거나, 시스템에서 자동으로 복사본을 시드하게 하는 대신 데이터베이스 복사본을 수동으로 시드하려면 EAC에서 사서함 데이터베이스 복사본 업데이트 마법사를 사용하거나 셸에서 Update-MailboxDatabaseCopy cmdlet을 사용하여 이 작업을 수행할 수 있습니다. 데이터베이스 복사본을 시드하기 전에 먼저 사서함 데이터베이스 복사본을 일시 중단해야 합니다. 데이터베이스 복사본을 시드하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 업데이트을 참조하십시오.Database copies rarely need to be reseeded after the initial seeding has occurred. But if reseeding is necessary, or if you want to manually seed a database copy instead of having the system automatically seed the copy, these tasks can be performed by using the Update Mailbox Database Copy wizard in the EAC or by using the Update-MailboxDatabaseCopy cmdlet in the Shell. Before seeding a database copy, you must first suspend the mailbox database copy. For detailed steps about how to seed a database copy, see Update a mailbox database copy.

수동 시드 작업이 완료된 후에는 시드된 사서함 데이터베이스 복사본에 대한 복제가 자동으로 다시 시작됩니다.After a manual seed operation has completed, replication for the seeded mailbox database copy is automatically resumed. 복제가 자동으로 다시 시작되지 않게 하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 ManualResume 매개 변수를 사용합니다.If you don't want replication to automatically resume, you can use the ManualResume parameter when running the Update-MailboxDatabaseCopy cmdlet.

시드 대상 선택Choosing what to seed

시드 작업을 수행할 때 사서함 데이터베이스 복사본이나 사서함 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그 중 하나, 또는 데이터베이스 복사본과 콘텐츠 인덱스 카탈로그 복사본 둘 다를 시드하도록 선택할 수 있습니다.When performing a seed operation, you can choose to seed the mailbox database copy, the content index catalog for the mailbox database copy, or both the database copy and the content index catalog copy.

사서함 데이터베이스 복사본 업데이트 마법사 및 Update-MailboxDatabaseCopy cmdlet의 기본 동작은 사서함 데이터베이스 복사본과 콘텐츠 인덱스 카탈로그 복사본 모두를 시드하는 것입니다.The default behavior of the Update Mailbox Database Copy wizard and the Update-MailboxDatabaseCopy cmdlet is to seed both the mailbox database copy and the content index catalog copy. 콘텐츠 인덱스 카탈로그를 시드 하지 않고 사서함 데이터베이스 복사본만 시드 하려면 update-mailboxdatabasecopy cmdlet을 실행할 때 databaseonly 매개 변수를 사용 합니다.To seed just the mailbox database copy without seeding the content index catalog, use the DatabaseOnly parameter when running the Update-MailboxDatabaseCopy cmdlet. 콘텐츠 인덱스 카탈로그 복사본만 시드하려면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 CatalogOnly 매개 변수를 사용합니다.To seed just the content index catalog copy, use the CatalogOnly parameter when running the Update-MailboxDatabaseCopy cmdlet.

시드 원본 선택Selecting the seeding source

정상 상태인 데이터베이스 복사본을 이 데이터베이스의 추가 복사본에 대한 시드 원본으로 사용할 수 있습니다. 이것은 DAG가 여러 물리적 위치에 확장되어 있는 경우에 특히 유용합니다. 예를 들어 두 구성원(MBX1과 MBX2)은 Oregon 주의 Portland에 있고 두 구성원(MBX3과 MBX4)은 New York 주의 New York에 있는 네 구성원 DAG 배포를 가정해 보겠습니다. DB1이라는 사서함 데이터베이스가 MBX1에서 활성 상태이고 DB1의 수동 복사본이 MBX2 및 MBX3에 있습니다. DB1의 복사본을 MBX4에 추가할 때는 MBX3의 복사본을 시드 원본으로 사용할 수 있습니다. 이렇게 하면 Portland와 New York 간의 WAN 링크를 통한 시드를 피할 수 있습니다.Any healthy database copy can be used as the seeding source for an additional copy of that database. This is particularly useful when you have a DAG that has been extended across multiple physical locations. For example, consider a four-member DAG deployment, where two members (MBX1 and MBX2) are located in Portland, Oregon and two members (MBX3 and MBX4) are located in New York, New York. A mailbox database named DB1 is active on MBX1 and there are passive copies of DB1 on MBX2 and MBX3. When adding a copy of DB1 to MBX4, you have the option of using the copy on MBX3 as the source for seeding. In doing so, you avoid seeding over the wide area network (WAN) link between Portland and New York.

새 데이터베이스 복사본을 추가할 때 특정 복사본을 시드 원본으로 사용하려면 다음과 같은 작업을 수행합니다.To use a specific copy as a source for seeding when adding a new database copy, you would do the following:

  • Update-mailboxdatabasecopy cmdlet을 실행 하 여 데이터베이스 복사본을 추가할 때 SeedingPostponed 매개 변수를 사용 합니다.Use the SeedingPostponed parameter when running the Add-MailboxDatabaseCopy cmdlet to add the database copy. SeedingPostponed 매개 변수를 사용 하지 않으면 데이터베이스 복사본은 데이터베이스의 활성 복사본을 원본으로 사용 하 여 명시적으로 시드 됩니다.If the SeedingPostponed parameter isn't used, the database copy will be explicitly seeded using the active copy of the database as the source.

  • EAC에서 사서함 데이터베이스 복사본 업데이트 마법사의 일부로 사용할 원본 서버를 지정 하거나, update-mailboxdatabasecopy cmdlet을 실행 하 여 원하는 원본 서버를 지정할 수 ** 있습니다. 시드.You can specify the source server you want to use as part of the Update Mailbox Database Copy wizard in the EAC, or you can use the SourceServer parameter when running the Update-MailboxDatabaseCopy cmdlet to specify the desired source server for seeding. 앞의 예에서는 MBX3을 원본 서버로 지정합니다.In the preceding example, you would specify MBX3 as the source server. SourceServer 매개 변수를 사용하지 않으면 데이터베이스 복사본은 데이터베이스의 활성 복사본에서 명시적으로 시드됩니다.If the SourceServer parameter isn't used, the database copy will be explicitly seeded from the active copy of the database.

시드 및 네트워크Seeding and networks

사서함 데이터베이스 복사본 시드를 위한 특정 원본 서버를 선택할 수 있을 뿐만 아니라, 셸을 사용하여 사용하고자 하는 DAG 네트워크를 지정할 수도 있고 시드 작업 중에 DAG 네트워크의 압축 및 암호화 설정을 다시 정의할 수도 있습니다.In addition to selecting a specific source server for seeding a mailbox database copy, you can also use the Shell to specify which DAG networks to use, and optionally override the DAG network's compression and encryption settings during the seed operation.

참고

컨텍스트 인덱스를 시드 하려면 MAPI 네트워크를 통해서만 가능 합니다.Seeding a context index catalog is only possible over a MAPI network. 이는 Update-mailboxdatabasecopy cmdlet의 매개 변수를 -Network 사용 하는 경우에도 마찬가지입니다.This is true even if you use the -Network parameter in the Update-MailboxDatabaseCopy cmdlet.

시드에 사용할 네트워크를 지정 하려면 update-mailboxdatabasecopy cmdlet을 실행할 때 Network 매개 변수를 사용 하 고 사용할 DAG 네트워크를 지정 합니다.To specify the networks you want to use for seeding, use the Network parameter when running the Update-MailboxDatabaseCopy cmdlet and specify the DAG networks that you want to use. Network 매개 변수를 사용 하지 않으면 시스템은 시드 작업에 사용할 네트워크를 선택할 때 다음과 같은 기본 동작을 사용 합니다.If you don't use the Network parameter, the system uses the following default behavior for selecting a network to use for the seeding operation:

  • 원본 서버와 대상 서버가 같은 서브넷에 있고 이 서브넷을 포함하는 복제 네트워크가 구성되어 있는 경우 복제 네트워크가 사용됩니다.If the source server and target server are on the same subnet and a replication network has been configured that includes the subnet, the replication network will be used.

  • 원본 서버와 대상 서버가 서로 다른 서브넷에 있는 경우 이들 서브넷을 포함하는 복제 네트워크가 구성되어 있더라도 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.If the source server and target server are on different subnets, even if a replication network that contains those subnets has been configured, the client (MAPI) network will be used for seeding.

  • 원본 서버와 대상 서버가 서로 다른 데이터 센터에 있는 경우 클라이언트 (MAPI) 네트워크가 시드에 사용됩니다.If the source server and target server are in different datacenters, the client (MAPI) network will be used for seeding.

DAG 수준에서, 암호화 및 압축을 위해 DAG 네트워크가 구성됩니다.At the DAG level, DAG networks are configured for encryption and compression. 기본 설정은 다른 서브넷의 통신에만 암호화와 압축을 사용하는 것입니다.The default settings are to use encryption and compression only for communications on different subnets. 원본 및 대상이 서로 다른 서브넷에 있고 DAG가 NetworkCompressionNetworkEncryption에 대한 기본값을 사용하여 구성되어 있다면 Update-MailboxDatabaseCopy cmdlet을 실행할 때 NetworkCompressionOverrideNetworkEncryptionOverride 매개 변수를 각각 사용하여 이 값을 다시 정의할 수 있습니다.If the source and target are on different subnets and the DAG is configured with the default values for NetworkCompression and NetworkEncryption, you can override these values by using the NetworkCompressionOverride and NetworkEncryptionOverride parameters, respectively, when running the Update-MailboxDatabaseCopy cmdlet.

시드 프로세스Seeding process

Add-MailboxDatabaseCopy 또는 Update-MailboxDatabaseCopy cmdlet을 사용하여 시드 프로세스를 시작할 경우 다음 작업이 수행됩니다.When you initiate a seeding process by using the Add-MailboxDatabaseCopy or Update-MailboxDatabaseCopy cmdlets, the following tasks are performed:

  1. 지정된 데이터베이스 및 서버를 확인하기 위해, 그리고 원본 및 대상 서버가 Active Directory을 실행 중인지, 둘 다 같은 DAG의 구성원인지, 지정된 데이터베이스가 복구 데이터베이스가 아닌지를 확인하기 위해 Exchange 2013에서 데이터베이스 속성을 읽습니다. 또한 데이터베이스 파일 경로도 읽습니다.Database properties from Active Directory are read to validate the specified database and servers, and to verify that the source and target servers are running Exchange 2013, they are both members of the same DAG, and that the specified database isn't a recovery database. The database file paths are also read.

  2. 대상 서버의 Microsoft Exchange 복제 서비스에서 다시 시드 확인을 위한 준비 작업이 수행됩니다.Preparations occur for reseed checks from the Microsoft Exchange Replication service on the target server.

  3. 대상 서버의 Microsoft Exchange 복제 서비스가 1단계에서 Active Directory 확인을 위해 읽은 파일 디렉터리에 데이터베이스와 트랜잭션 로그가 있는지 확인합니다.The Microsoft Exchange Replication service on the target server checks for the presence of database and transaction log files in the file directories read by the Active Directory checks in step 1.

  4. Microsoft Exchange 복제 서비스가 대상 서버로부터 cmdlet을 실행한 관리 인터페이스로 상태 정보를 반환합니다.The Microsoft Exchange Replication service returns the status information from the target server to the administrative interface from where the cmdlet was run.

  5. 모든 사전 검사를 통과하면 작업을 계속할지 확인하는 메시지가 표시됩니다. 작업을 계속하기로 선택하면 프로세스가 계속됩니다. 사전 검사 중 오류가 발생할 경우 오류가 보고되고 작업이 실패합니다.If all preliminary checks have passed, you're prompted to confirm the operation before continuing. If you confirm the operation, the process continues. If an error is encountered during the preliminary checks, the error is reported and the operation fails.

  6. 시드 작업이 대상 서버의 Microsoft Exchange 복제 서비스에서 시작됩니다.The seed operation is started from the Microsoft Exchange Replication service on the target server.

  7. Microsoft Exchange 복제 서비스가 활성 데이터베이스 복사본의 데이터베이스 복제를 일시 중단합니다.The Microsoft Exchange Replication service suspends database replication for the active database copy.

  8. 데이터베이스에 대한 상태 정보가 시드 상태를 반영하도록 Microsoft Exchange 복제 서비스에 의해 업데이트됩니다.The state information for the database is updated by the Microsoft Exchange Replication service to reflect a status of Seeding.

  9. 대상 서버에 대상 데이터베이스 및 로그 파일을 위한 디렉터리가 없으면 새로 만들어집니다.If the target server doesn't already have the directories for the target database and log files, they are created.

  10. 데이터베이스 시드 요청이 TCP를 사용하여 대상 서버의 Microsoft Exchange 복제 서비스에서 원본 서버의 Microsoft Exchange 복제 서비스로 전달됩니다. 이 요청 및 데이터베이스 시드를 위한 이후 통신은 복제 네트워크로 구성된 DAG 네트워크에서 일어납니다.A request to seed the database is passed from the Microsoft Exchange Replication service on the target server to the Microsoft Exchange Replication service on the source server using TCP. This request and the subsequent communications for seeding the database occur on a DAG network that has been configured as a replication network.

  11. 원본 서버의 Microsoft Exchange 복제 서비스가 Microsoft Exchange 정보 저장소 인터페이스를 통해 ESE(Extensible Storage Engine) 스트리밍 백업을 시작합니다.The Microsoft Exchange Replication service on the source server initiates an Extensible Storage Engine (ESE) streaming backup via the Microsoft Exchange Information Store service interface.

  12. Microsoft Exchange 정보 저장소 서비스가 데이터베이스 데이터를 Microsoft Exchange 복제 서비스로 스트리밍합니다.The Microsoft Exchange Information Store service streams the database data to the Microsoft Exchange Replication service.

  13. 데이터베이스 데이터가 원본 서버의 Microsoft Exchange 복제 서비스에서 대상 서버의 Microsoft Exchange 복제 서비스로 이동합니다.The database data is moved from the source server's Microsoft Exchange Replication service to the target server's Microsoft Exchange Replication service.

  14. 대상 서버의 Microsoft Exchange 복제 서비스가 데이터베이스 복사본을 기본 데이터베이스 디렉터리 ( temp 시드) 에 있는 임시 디렉터리에 씁니다.The Microsoft Exchange Replication service on the target server writes the database copy to a temporary directory located in the main database directory called temp-seeding.

  15. 데이터베이스의 끝에 도달하면 원본 서버의 스트리밍 백업 작업이 끝납니다.The streaming backup operation on the source server ends when the end of the database is reached.

  16. 대상 서버에서의 쓰기 작업이 완료되고 데이터베이스가 temp-seeding 디렉터리에서 최종 위치로 이동합니다. temp-seeding 디렉터리가 삭제됩니다.The write operation on the target server completes, and the database is moved from the temp-seeding directory to the final location. The temp-seeding directory is deleted.

  17. 대상 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스로 요청을 프록시 처리하여 데이터베이스 복사본의 콘텐츠 인덱스 카탈로그가 있는 경우 이를 탑재합니다. 데이터베이스 복사본의 이전 인스턴스의 오래된 기존 카탈로그 파일이 있는 경우 탑재 작업이 실패하고, 이로 인해 원본 서버로부터 카탈로그를 복제해야 합니다. 마찬가지로, 대상 서버에 있는 데이터베이스 복사본의 새 인스턴스에 카탈로그가 없는 경우 카탈로그의 복제본이 필요합니다. Microsoft Exchange 복제 서비스는 원본에서 새 카탈로그가 복사되는 동안 데이터베이스 복사본에 대한 인덱싱을 일시 중단하도록 Microsoft Exchange 검색 서비스에 지시합니다.On the target server, the Microsoft Exchange Replication service proxies a request to the Microsoft Exchange Search service to mount the content index catalog for the database copy, if it exists. If there are existing out-of-date catalog files from a previous instance of the database copy, the mount operation fails, which triggers the need to replicate the catalog from the source server. Likewise, if the catalog doesn't exist on a new instance of the database copy on the target server, a copy of the catalog is required. The Microsoft Exchange Replication service directs the Microsoft Exchange Search service to suspend indexing for the database copy while a new catalog is copied from the source.

  18. 대상 서버의 Microsoft Exchange 복제 서비스가 원본 서버의 Microsoft Exchange 복제 서비스로 카탈로그 시드 요청을 보냅니다.The Microsoft Exchange Replication service on the target server sends a seed catalog request to the Microsoft Exchange Replication service on the source server.

  19. 원본 서버에서, Microsoft Exchange 복제 서비스가 Microsoft Exchange 검색 서비스에 디렉터리 정보를 요청하고 해당 인덱싱의 일시 중단을 요청합니다.On the source server, the Microsoft Exchange Replication service requests the directory information from the Microsoft Exchange Search service and requests that indexing be suspended.

  20. 원본 서버의 Microsoft Exchange 검색 서비스가 검색 카탈로그 디렉터리 정보를 Microsoft Exchange 복제 서비스에 반환합니다.The Microsoft Exchange Search service on the source server returns the search catalog directory information to the Microsoft Exchange Replication service.

  21. 원본 서버의 Microsoft Exchange 복제 서비스가 디렉터리에서 카탈로그 파일을 읽습니다.The Microsoft Exchange Replication service on the source server reads the catalog files from the directory.

  22. 원본 서버의 Microsoft Exchange 복제 서비스가 복제 네트워크 내 연결을 사용하여 대상 서버의 Microsoft Exchange 복제 서비스로 카탈로그 데이터를 이동합니다. 읽기가 완료되면 Microsoft Exchange 복제 서비스는 원본 데이터베이스의 인덱싱을 다시 시작하기 위해 Microsoft Exchange 검색 서비스에 요청을 보냅니다.The Microsoft Exchange Replication service on the source server moves the catalog data to the Microsoft Exchange Replication service on the target server using a connection across the replication network. After the read is complete, the Microsoft Exchange Replication service sends a request to the Microsoft Exchange Search service to resume indexing of the source database.

  23. 디렉터리의 대상 서버에 기존 카탈로그 파일이 있는 경우 대상 서버의 Microsoft Exchange 복제 서비스가 이를 삭제합니다.If there are any existing catalog files on the target server in the directory, the Microsoft Exchange Replication service on the target server deletes them.

  24. 대상 서버의 Microsoft Exchange 복제 서비스가 카탈로그 데이터를 완벽 하 게 전송할 때까지 Temp 라는 임시 디렉터리에 기록 합니다 .The Microsoft Exchange Replication service on the target server writes the catalog data to a temporary directory called CiSeed.Temp until the data is completely transferred.

  25. Microsoft Exchange 복제 서비스가 완전한 카탈로그 데이터를 최종 위치로 이동합니다.The Microsoft Exchange Replication service moves the complete catalog data to the final location.

  26. 대상 서버의 Microsoft Exchange 복제 서비스가 대상 데이터베이스의 검색 인덱싱을 다시 시작합니다.The Microsoft Exchange Replication service on the target server resumes search indexing on the target database.

  27. 대상 서버의 Microsoft Exchange 복제 서비스가 완료 상태를 반환합니다.The Microsoft Exchange Replication service on the target server returns a completion status.

  28. 이 작업의 최종 결과가 cmdlet을 호출한 관리 인터페이스로 전달됩니다.The final result of the operation is passed to the administrative interface from which the cmdlet was called.

데이터베이스 복사본 구성Configuring database copies

데이터베이스 복사본이 만들어진 후, 필요한 경우 그 구성 설정을 보거나 수정할 수 있습니다. EAC에서 데이터베이스 복사본의 속성 페이지를 확인하면 일부 구성 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabaseSet-MailboxDatabaseCopy cmdlet을 사용하여 재생 지연 시간, 자르기 지연 시간 및 활성화 기본 설정 순서 등의 데이터베이스 복사본 설정을 보거나 구성할 수 있습니다. 데이터베이스 복사본 설정을 보거나 구성하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본 속성 구성을 참조하십시오.After a database copy is created, you can view and modify its configuration settings when needed. You can view some configuration information by examining the Properties page for a database copy in the EAC. You can also use the Get-MailboxDatabase and Set-MailboxDatabaseCopy cmdlets in the Shell to view and configure database copy settings, such as replay lag time, truncation lag time, and activation preference order. For detailed steps about how to view and configure database copy settings, see Configure mailbox database copy properties.

재생 지연 및 자르기 지연 옵션 사용Using replay lag and truncation lag options

사서함 데이터베이스 복사본은 재생 지연 시간자르기 지연 시간 또는 모두를 분 단위로 구성하여 사용하도록 지원합니다. 재생 지연 시간을 설정하면 데이터베이스 복사본을 특정 시점으로 되돌릴 수 있습니다. 자르기 지연 시간을 설정하면 수동 데이터베이스 복사본의 로그를 사용하여 활성 데이터베이스 복사본의 로그 파일 손실로부터 복구할 수 있습니다. 이러한 기능 모두는 임시 작성 로그 파일을 만들기 때문에 해당 기능을 사용하면 저장소 디자인에 영향을 미칩니다.Mailbox database copies support the use of a replay lag time and a truncation lag time, both of which are configured in minutes. Setting a replay lag time enables you to take a database copy back to a specific point in time. Setting a truncation lag time enables you to use the logs on a passive database copy to recover from the loss of log files on the active database copy. Because both of these features result in the temporary buildup of log files, using either of them will affect your storage design.

재생 지연 시간Replay lag time

재생 지연 시간은 데이터베이스 복사본에 대한 로그 재생을 지연하기 위해 분 단위로 시간을 지정하는 사서함 데이터베이스 복사본의 속성입니다. 재생 지연 타이머는 로그 파일이 수동 복사본에 복제되고 검사를 통과했을 때 시작됩니다. 데이터베이스 복사본에서 로그 재생을 지연하면 데이터베이스를 과거의 특정 시점으로 복구할 수 있습니다. 재생 지연 시간이 0보다 길게 구성된 사서함 데이터베이스 복사본은 지연된 데이터베이스 복사본 또는 간단히 지연된 복사본이라고 합니다.Replay lag time is a property of a mailbox database copy that specifies the amount of time, in minutes, to delay log replay for the database copy. The replay lag timer starts when a log file has been replicated to the passive copy and has successfully passed inspection. By delaying the replay of logs to the database copy, you have the capability to recover the database to a specific point in time in the past. A mailbox database copy configured with a replay lag time greater than 0 is referred to as a lagged mailbox database copy, or simply, a lagged copy.

Exchange 2013의 데이터베이스 복사본과 소송 보존 기능을 사용하는 전략은 일반적으로 데이터 손실을 초래할 수 있는 오류로부터 데이터를 보호합니다. 그러나 이러한 기능은 드물기는 하지만 논리적 손상으로 데이터가 손실되는 경우에는 데이터를 보호할 수 없습니다. 지연된 복사본은 논리적 손상으로부터 데이터 손실을 막기 위해 설계되었으며, 논리적 손상에는 일반적으로 두 가지 유형이 있습니다.A strategy that uses database copies and the litigation hold features in Exchange 2013 can provide protection against a range of failures that would ordinarily cause data loss. However, these features can't provide protection against data loss in the event of logical corruption, which although rare, can cause data loss. Lagged copies are designed to prevent loss of data in the case of logical corruption. Generally, there are two types of logical corruption:

  • 데이터베이스 논리적 손상: 데이터베이스 페이지 체크섬이 일치 하지만 페이지의 데이터가 논리적으로 잘못 되었습니다.Database logical corruption: The database pages checksum matches, but the data on the pages is wrong logically. 이러한 손상은 ESE가 데이터베이스 페이지 쓰기를 시도할 경우에 발생하며, 운영 체제에서 성공 메시지가 반환되더라도 이 데이터를 디스크에 쓰지 않았거나 잘못된 위치에 쓴 것입니다.This can occur when ESE attempts to write a database page and even though the operating system returns a success message, the data is either never written to the disk or it's written to the wrong place. 이를 손실 플러시라고 합니다.This is referred to as a lost flush. 데이터 손실로부터 손실 플러시를 방지하기 위해, ESE는 데이터베이스에 페이지 패치 기능(단일 페이지 복원)과 함께 손실 플러시 감지 메커니즘을 포함합니다.To prevent lost flushes from losing data, ESE includes a lost flush detection mechanism in the database along with a page patching feature (single page restore).

  • 저장소 논리적 손상: 사용자가 기대 하지 않는 방식으로 데이터를 추가, 삭제 또는 조작 합니다.Store logical corruption: Data is added, deleted, or manipulated in a way that the user doesn't expect. 이러한 경우는 일반적으로 타사 응용 프로그램에 의해 발생 합니다.These cases are generally caused by third-party applications. 일반적으로 사용자가 해당 개체를 손상으로 보기 때문에 손상이 발생 합니다.It's generally only corruption in the sense that the user views it as corruption. Exchange 저장소는 논리적 손상을 생성 한 트랜잭션이 유효한 MAPI 작업의 계열로 간주 합니다.The Exchange store considers the transaction that produced the logical corruption to be a series of valid MAPI operations. Exchange 2013의 소송 보존 기능은 저장소 논리적 손상 (사용자 또는 응용 프로그램에 의해 콘텐츠가 영구적으로 삭제 되는 것을 방지 함)을 보호 합니다.The litigation hold feature in Exchange 2013 provides protection from store logical corruption (because it prevents content from being permanently deleted by a user or application). 그러나 사용자 사서함이 손상 된 것 처럼 손상 되기 전에 데이터베이스를 복원 하는 것이 더 쉬울 수 있으며, 사용자 사서함을 내보내 손실 되지 않은 데이터를 검색할 수 있는 경우가 있습니다.However, there may be scenarios where a user mailbox becomes so corrupted that it would be easier to restore the database to a point in time prior to the corruption, and then export the user mailbox to retrieve uncorrupted data.

데이터베이스 복사본, 보존 정책, ESE 단일 페이지 복원을 조합하여 함께 사용하는 것은 드물게 발생하지만 매우 치명적인 저장소 논리적 손상인 경우로 제한합니다. 데이터베이스 복사본에 재생 지연(지연된 복사본)을 사용할지 여부는 어떤 타사 응용 프로그램을 사용하는지와 조직에 어떤 저장소 논리적 손상이 발생했었는지에 따라 결정합니다.The combination of database copies, hold policy, and ESE single page restore leaves only the rare but catastrophic store logical corruption case. Your decision on whether to use a database copy with a replay lag (a lagged copy) will depend on which third-party applications you use and your organization's history with store logical corruption.

지연 된 복사본은 다음과 같은 특정 시나리오에서 자동 로그 재생을 호출 하 여 로그 파일을 재생 하는 경우 Exchange 2013에서 자체적으로 처리할 수 있습니다.Lagged copies can care for themselves in Exchange 2013 when you invoke automatic log replay to play down the log files in certain scenarios:

  • 디스크 공간 부족 임계값에 도달할 경우When a low disk space threshold is reached

  • 지연된 복사본에 물리적인 손상 부분이 있어 페이지를 패치해야 하는 경우When the lagged copy has physical corruption and needs to be page patched

  • 정상 상태의 사용 가능한 복사본(활성 또는 수동만 포함하며 지연된 데이터베이스 복사본은 계산에서 제외)이 24시간 이상 동안 3개 미만인 경우When there are fewer than three available healthy copies (active or passive only; lagged database copies are not counted) for more than 24 hours

페이지 패치는이 자동 재생 기능을 통해 지연 된 복사본에 사용할 수 있습니다.Page patching is available for lagged copies through this automatic play down feature. 시스템이 지연된 복사본에 대한 페이지 패치가 필요하다고 감지하면 페이지 패치를 수행하기 위해 자동으로 로그가 지연된 복사본으로 재생됩니다.If the system detects that page patching is required for a lagged copy, the logs are automatically replayed into the lagged copy to perform page patching. 지연된 복사본은 낮은 디스크 공간 임계값에 도달한 경우와 지연된 복사본이 특정 기간 동안 유일하게 사용할 수 있는 복사본으로 감지된 경우에도 이 자동 재생 기능을 호출합니다.Lagged copies also invoke this auto replay feature when a low disk space threshold has been reached, and when the lagged copy has been detected as the only available copy for a specific period of time.

지연된 복사본 재생 동작은 기본적으로 사용하지 않도록 설정되어 있으며 다음 명령을 실행하면 이를 사용하도록 설정할 수 있습니다.Lagged copy play down behavior is disabled by default, and can be enabled by running the following command.

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

재생 동작을 사용하도록 설정한 후 복사본 수가 3개 미만이면 재생이 발생합니다. 다음 DWORD 레지스트리 값을 수정하면 기본값 3을 변경할 수 있습니다.After being enabled, play down occurs when there are fewer than three copies. You can change the default value of 3, by modifying the following DWORD registry value.

HKLM\Software\Microsoft\set-exchangeserver\v 15의\Replay\매개\변수 ReplayLagManagerNumAvailableCopiesHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

디스크 공간 부족 임계값에 도달할 경우 재생을 사용하도록 설정하려면 다음 레지스트리 항목을 추가로 구성해야 합니다.To enable play down for low disk space thresholds, you must configure the following registry entry.

HKLM\Software\Microsoft\set-exchangeserver\v 15의\Replay\매개\변수 ReplayLagLowSpacePlaydownThresholdInMBHKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

이러한 레지스트리 설정을 구성한 후에 Microsoft Exchange DAG Management Service를 다시 시작하여 변경 내용을 적용합니다.After configuring either of these registry settings, restart the Microsoft Exchange DAG Management service for the changes to take effect.

예를 들어 지정 된 데이터베이스에 4 개의 복사본 (고가용성 복사본 및 1 지연 된 복사본)이 있고 기본 설정이 ReplayLagManagerNumAvailableCopies에 사용 되는 환경을 가정해 봅니다.As an example, consider an environment where a given database has 4 copies (3 highly available copies and 1 lagged copy), and the default setting is used for ReplayLagManagerNumAvailableCopies. 지연되지 않은 복사본이 어떤 이유(예: 일시 중단 등)로 인해 작동되지 않으면 지연된 복사본이 24시간 후에 자동으로 로그 파일을 재생합니다.If a non-lagged copy is out-of-service for any reason (for example, it is suspended, etc.) then the lagged copy will automatically play down its log files in 24 hours.

ReplayLagManagerEnabled 매개 변수를 사용 하지 않고 지연 된 복사본을 사용 하도록 선택 하는 경우에는 다음과 같은 의미를 알고 있어야 합니다.If you choose to use lagged copies without enabling the ReplayLagManagerEnabled parameter, be aware of the following implications:

  • 재생 지연 시간은 관리자가 구성하는 값이며 기본적으로 사용하지 않도록 설정되어 있습니다.The replay lag time is an administrator-configured value, and by default, it's disabled.

  • 재생 지연 시간 설정은 기본적으로 0일이며, 최대 설정은 14일입니다.The replay lag time setting has a default setting of 0 days, and a maximum setting of 14 days.

  • 지연된 복사본은 항상 사용 가능한 복사본으로 간주되지 않습니다. 대신, 저장소 논리적 손상으로부터 데이터를 보호하기 위해 재해 복구용으로 설계되었습니다.Lagged copies aren't considered highly available copies. Instead, they are designed for disaster recovery purposes, to protect against store logical corruption.

  • 재생 지연 시간을 크게 설정할수록 데이터베이스 복구 프로세스가 길어집니다. 복구하는 동안 재생해야 할 로그 파일의 수, 하드웨어가 로그 파일을 재생하는 속도에 따라 데이터베이스를 복구하는 데 수시간 또는 수일이 소요될 수도 있습니다.The greater the replay lag time set, the longer the database recovery process. Depending on the number of log files that need to replayed during recovery, and the speed at which your hardware can replay them, it may take several hours or more to recover a database.

  • 지연된 복사본이 전반적인 재해 복구 전략에 반드시 필요한지 여부를 결정합니다. 재해 복구 전략에 지연된 복사본 사용이 필수적이면 지연된 복사본 여러 개를 사용하고, 만약 지연된 복사본이 하나뿐인 경우에는 RAID(Redundant Array of Independent Disks)를 사용하여 이 복사본을 보호하는 것이 좋습니다. 디스크가 손실되거나 손상이 발생하더라도 지연된 시점이 보존됩니다.We recommend that you determine whether lagged copies are critical for your overall disaster recovery strategy. If using them is critical to your strategy, we recommend using multiple lagged copies, or using a redundant array of independent disks (RAID) to protect a single lagged copy, if you don't have multiple lagged copies. If you lose a disk or if corruption occurs, you don't lose your lagged point in time.

  • 지연된 복사본은 ESE 단일 페이지 복원 기능에 패치되지 않습니다. 지연된 복사본에 데이터베이스 손상(예: a -1018 오류)이 발생하면 복사본의 지연된 부분이 손실되므로 다시 시드해야 합니다.Lagged copies aren't patchable with the ESE single page restore feature. If a lagged copy encounters database page corruption (for example, a -1018 error), it will have to be reseeded (which will lose the lagged aspect of the copy).

데이터베이스에서 모든 로그 파일을 재생하고 데이터베이스 복사본을 최신 상태로 만들려는 경우 지연된 사서함 데이터베이스 복사본을 활성화하고 복구하는 프로세스가 간단합니다. 로그 파일을 특정 시점까지 재생하려면 수동으로 로그 파일을 조작하고 Eseutil(Exchange Server Database Utilities) 도구를 실행해야 하기 때문에 작업이 더 복잡해집니다.Activating and recovering a lagged mailbox database copy is an easy process if you want the database to replay all log files and make the database copy current. If you want to replay log files up to a specific point in time, it's a more difficult operation because you manually manipulate log files and run Exchange Server Database Utilities (Eseutil.exe).

지연 된 사서함 데이터베이스 복사본을 활성화 하는 방법에 대 한 자세한 단계는 activate a 지연 된 mailbox database copy를 참조 하십시오.For detailed steps about how to activate a lagged mailbox database copy, see Activate a lagged mailbox database copy.

자르기 지연 시간Truncation lag time

자르기 지연 시간은 로그 파일이 데이터베이스 복사본에 재생된 후 데이터베이스 복사본에 대한 로그 삭제를 지연하기 위해 분 단위로 시간을 지정하는 사서함 데이터베이스 복사본의 속성입니다. 자르기 지연 타이머는 로그 파일이 수동 복사본에 복제되고 검사를 통과한 후 데이터베이스 복사본에 재생되었을 때 시작됩니다. 데이터베이스 복사본에서 로그 파일 자르기를 지연하면 데이터베이스의 활성 복사본에 대한 로그 파일에 영향을 준 오류로부터 복구할 수 있습니다.Truncation lag time is a property of a mailbox database copy that specifies the amount of time, in minutes, to delay log deletion for the database copy after the log file has been replayed into the database copy. The truncation lag timer starts when a log file has been replicated to the passive copy, successfully passed inspection, and has been successfully replayed into the copy of the database. By delaying the truncation of log files from the database copy, you have the capability to recover from failures that affect the log files for the active copy of the database.

데이터베이스 복사본 및 로그 잘라내기Database copies and log truncation

Exchange 2010에서와 마찬가지로 로그 자르기는 Exchange 2013 에서도 동일 하 게 작동 합니다.Log truncation works the same in Exchange 2013 as it did in Exchange 2010. 자르기 동작은 복사본에 대한 재생 지연 시간 및 자르기 지연 시간 설정에 의해 결정됩니다.Truncation behavior is determined by the replay lag time and truncation lag time settings for the copy.

지연 설정이 기본값 0(사용하지 않도록 설정)보다 왼쪽에 있는 값을 갖는 경우 데이터베이스 복사본의 로그 파일을 자르려면 다음 조건을 충족해야 합니다.The following criteria must be met for a database copy's log file to be truncated when lag settings are left at their default values of 0 (disabled):

  • 로그 파일을 성공적으로 백업했거나, 순환 로깅을 사용하도록 설정되어 있어야 합니다.The log file must have been successfully backed up, or circular logging must be enabled.

  • 로그 파일이 데이터베이스에 대한 검사점(복구에 필요한 최소 로그 파일) 아래에 있어야 합니다.The log file must be below the checkpoint (the minimum log file required for recovery) for the database.

  • 다른 모든 지연된 복사본에 검사를 마친 로그 파일이 있어야 합니다.All other lagged copies must have inspected the log file.

  • 지연된 복사본이 아닌 다른 모든 복사본이 로그 파일을 재생했어야 합니다.All other copies (not lagged copies) must have replayed the log file.

지연된 데이터베이스 복사본에 대한 자르기가 수행되려면 다음 조건을 충족해야 합니다.The following criteria must be met for truncation to occur for a lagged database copy:

  • 로그 파일이 데이터베이스의 검사점 아래에 있어야 합니다.The log file must be below the checkpoint for the database.

  • 로그 파일이 ReplayLagTime + TruncationLagTime보다 오래된 것이어야 합니다.The log file must be older than ReplayLagTime + TruncationLagTime.

  • 로그 파일이 활성 복사본에서 잘렸어야 합니다.The log file must have been truncated on the active copy.

Exchange 2013에서는 수동 복사본이 하나 이상 일시 중단되어 있으면 활성 사서함 데이터베이스 복사본에서 로그를 자르지 않습니다. 계획된 유지 관리 작업이 오래 계속된 경우(예를 들면 며칠) 상당한 양의 로그 파일이 쌓일 수 있습니다. 트랜잭션 로그로 로그 드라이브가 꽉 차지 않게 하려면 해당 수동 데이터베이스 복사본을 일시 중단하는 대신 제거합니다. 계획된 유지 관리가 완료되면 수동 데이터베이스 복사본을 다시 추가할 수 있습니다.In Exchange 2013 log truncation doesn't occur on an active mailbox database copy when one or more passive copies are suspended. If planned maintenance activities are going to take an extended period of time (for example, several days), you may have considerable log file buildup. To prevent the log drive from filling up with transaction logs, you can remove the affected passive database copy instead of suspending it. When the planned maintenance is completed, you can re-add the passive database copy.

Exchange 2013 SP1 (서비스 팩 1)에는 기본적으로 사용 하지 않도록 설정 된 느슨한 자르기라는 새로운 기능이 도입 되었습니다.Exchange 2013 Service Pack 1 (SP1) introduces a new feature called loose truncation, which is disabled by default. 정상 작동 중에는 데이터베이스의 모든 복사본이 재생(수동 복사본) 또는 수신(지연된 복사본)되었음을 확인할 때까지 각 데이터베이스 복사본에서 다른 데이터베이스 복사본에 전달해야 하는 로그가 유지됩니다.During normal operations, each database copy keeps logs that need to be shipped to other database copies until all copies of a database confirm they have replayed (passive copies) or received (lagged copies) the log files. 이는 기본 로그 잘라내기 동작입니다.This is default log truncation behavior. 데이터베이스 복사본이 특정 사유로 인해 오프라인 상태로 전환되면 데이터베이스의 다른 복사본에서 사용하는 디스크에 로그 파일이 누적되기 시작합니다.If a database copy goes offline for some reason, the log files begin accumulating on the disks used by the other copies of the database. 영향을 받는 데이터베이스 복사본이 연장된 기간 동안 오프라인 상태로 유지되면 이로 인해 다른 데이터베이스 복사본의 디스크 공간이 부족해질 수 있습니다.If the affected database copy remains offline for an extended period, this can cause the other database copies to run out of disk space.

느슨한 자르기가 사용하도록 설정된 경우에는 자르기 동작이 달라집니다. 각 데이터베이스 복사본이 자체 사용 가능한 디스크 공간을 추적한 다음 사용 가능한 공간이 부족해지면 느슨한 자르기 동작이 적용됩니다. 활성 복사본의 경우에는 가장 오래된 지연 복사본, 즉 로그 재생에서 맨 끝에 있는 수동 데이터베이스 복사본이 무시되고 남아 있는 가장 오래된 수동 복사본이 자르기에 사용됩니다. 전역 자르기는 활성 데이터베이스 복사본에서 계산됩니다. 수동 복사본은 활성 복사본에 대한 자르기 결정을 사용합니다. 자르기에서 사용되는 매개 변수의 이름이 MinCopiesToProtect이기는 하지만 Exchange에서는 자르기를 실행할 때 가장 오래된 것으로 확인된 지연 복사본만 무시합니다. 수동 복사본의 경우에는 공간이 부족해지면 아래에 설명되어 있는 구성된 매개 변수를 사용하여 로그 파일을 독립적으로 자릅니다.When loose truncation is enabled, the truncation behavior is different. Each database copy tracks its own free disk space and applies loose truncation behavior if free space gets low. For the active copy, the oldest straggler (the passive database copy that is farthest behind in log replay) is ignored and truncation respects the oldest remaining passive copies. The active database copy is where global truncation is calculated. The passive copies will attempt to respect the truncation decision made on the active copy. Despite the implication of the name MinCopiesToProtect, Exchange will only ignore the oldest known straggler at the time truncation is run. For a passive copy, if space gets low, it will independently truncate its log files using the configured parameters described below.

오프라인 데이터베이스가 다시 온라인 상태로 전환되면 다른 정상 상태의 복사본에서 삭제된 로그 파일이 누락되고 해당 데이터베이스 복사본 상태가 FailedAndSuspended로 됩니다. 이 경우 Autoreseed가 구성되어 있으면 영향을 받는 복사본이 자동으로 다시 시드되고, Autoreseed가 구성되어 있지 않으면 데이터베이스 복사본을 관리자가 수동으로 시드해야 합니다.When the offline database is brought back online, it will be missing log files that have been deleted from the other healthy copies, and its database copy status will be FailedAndSuspended. In this event, if Autoreseed is configured, the affected copy will be automatically reseeded. If Autoreseed is not configured, the database copy will need to be manually seeded by an administrator.

필요한 정상 상태 복사본 수, 사용 가능한 디스크 공간 임계값 및 유지할 로그 수는 모두 구성 가능한 매개 변수입니다. 기본적으로 사용 가능한 디스크 공간 임계값은 204,800MB(200GB)이고 유지할 로그 수는 수동 복사본에 필요한 100,000개(100GB) 및 활성 복사본에 필요한 10,000개(10GB)입니다.The required number of healthy copies, the free disk space threshold, and the number of logs to keep are all configurable parameters. By default, the free disk space threshold is 204800 MB (200 GB), and the number of logs to keep is 100,000 (100 GB) for passive copies, and 10,000 (10 GB) for active copies.

느슨한 잘라내기를 사용하도록 설정하고 느슨한 잘라내기 매개 변수를 구성하려면 각 DAG 구성원에 대한 Windows 레지스트리를 편집하면 됩니다.Enabling loose truncation and configuring loose truncation parameters is performed by editing the Windows registry on each DAG member. 구성할 수 있는 세 가지 레지스트리 값은\모두 HKLM Software\Microsoft\set-exchangeserver\v 15의\backupinformation에 저장 됩니다.There are three registry values that can be configured, that are all stored under HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. DWORD 값 뒤의 BackupInformation 키는 기본적으로 존재하지 않으며 수동으로 만들어야 합니다.The BackupInformation key the following DWORD values do not exist by default and must be manually created. BackupInformation 아래의 DWORD 레지스트리 값은 다음 표에서 설명되어 있습니다.The DWORD registry values under BackupInformation are described in the following table:

레지스트리 값Registry Value 설명Description 기본값Default Value

LooseTruncation_MinCopiesToProtectLooseTruncation_MinCopiesToProtect

이 키는 느슨한 자르기를 사용하도록 설정하는 데 사용되며, 데이터베이스 활성 복사본에 대한 느슨한 자르기에서 보호할 수동 복사본 수를 나타냅니다. 이 키의 값을 0으로 설정하면 느슨한 잘라내기가 사용하지 않도록 설정됩니다.This key is used to enable loose truncation. It represents the number of passive copies to protect from loose truncation on the active copy of a database. Setting the value of this key to 0 disables loose truncation.

0

LooseTruncation_MinDiskFreeSpaceThresholdInMBLooseTruncation_MinDiskFreeSpaceThresholdInMB

느슨한 자르기를 트리거하는 사용 가능한 디스크 공간(MB) 임계값입니다. 사용 가능한 디스크 공간이 이 값 아래로 떨어지면 느슨한 잘라내기가 트리거됩니다.Available disk space (in MB) threshold for triggering loose truncation. If free disk space falls below this value, loose truncation is triggered.

이 레지스트리 값을 구성하지 않으면 느슨한 자르기에 사용되는 기본값은 200GB입니다.If this registry value is not configured, the default value used by loose truncation is 200 GB.

LooseTruncation_MinLogsToProtectLooseTruncation_MinLogsToProtect

로그를 자를 정상 상태 복사본에서 유지할 로그 파일의 최소 개수입니다. 이 레지스트리 값을 구성하면 구성된 값이 활성 복사본과 수동 복사본에 모두 적용됩니다.The minimum number of log files to retain on healthy copies whose logs are being truncated. If this registry value is configured, then the configured value applies to both active and passive copies.

이 레지스트리 값을 구성하지 않으면 활성 데이터베이스 복사본에 대한 기본값 100,000개와 활성 데이터베이스 복사본에 대한 기본값 10,000개가 사용됩니다.If this registry value is not configured, then default values of 100,000 for passive database copies and 10,000 for active database copies is used.

LooseTruncation_minlogstoprotect 레지스트리 값을 사용 하는 경우 활성 및 수동 데이터베이스 복사본의 동작이 서로 다릅니다.When using the LooseTruncation_MinLogsToProtect registry value, note that the behavior is different for active and passive database copies. 활성 데이터베이스 복사본에서이 값은 보호 되는 수동 복사본에 필요한 것 보다 이전에 보존 되는 추가 로그 및 활성 복사본의 필수 범위에 해당 합니다. 수동 데이터베이스 복사본에서 사용 가능한 최신 로그에서 유지 관리 되는 로그의 수입니다.On the active database copy, this is the number of extra logs that are retained preceding those that are required by the protected passive copies and the required range of the active copy.On a passive database copy, this is the number of logs maintained from the latest available log. 이 숫자의 1/10은이 수동 복사본의 필수 범위 이전에 로그를 유지 관리 하는 데도 사용 됩니다.One tenth of this number is also used to maintain logs prior to the required range of this passive copy. 필요한 범위가 매우 크기 때문에 지연 된 데이터베이스 복사본이 너무 많은 공간을 차지 하지 않도록 하기 위해 두 가지 제한이 있습니다.The two limits are in place to ensure that lagged database copies don't take up too much space, since their required range is typically very large.

데이터베이스 활성화 정책Database activation policy

사서함 데이터베이스 복사본을 만들거나 오류 발생 시 시스템에서 해당 복사본을 자동으로 활성화하지 않으려는 경우가 있을 수 있습니다.There are scenarios in which you may want to create a mailbox database copy and prevent the system from automatically activating that copy in the event of a failure, for example:

  • 하나 이상의 사서함 데이터베이스 복사본을 대체 데이터 센터 또는 대기 데이터 센터로 배포하는 경우If you deploy one or more mailbox database copies to an alternate or standby datacenter.

  • 복구를 위해 지연된 데이터베이스 복사본을 구성하는 경우If you configure a lagged database copy for recovery purposes.

  • 서버의 유지 관리 또는 업그레이드를 수행하는 경우If you are performing maintenance or an upgrade of a server.

앞에 나온 각 시나리오에서, 시스템에 의해 자동으로 활성화되지 않아야 할 데이터베이스 복사본이 있습니다.In each of the preceding scenarios, you have database copies that you don't want the system to activate automatically. 시스템이 사서함 데이터베이스 복사본을 자동으로 활성화하지 않게 하기 위해, 활성화가 차단(일시 중단)되도록 복사본을 구성할 수 있습니다.To prevent the system from automatically activating a mailbox database copy, you can configure the copy to be blocked (suspended) for activation. 이렇게 하면 시스템은 로그 전달 및 재생을 통해 데이터베이스의 현재 상태를 유지하면서 시스템이 복사본을 자동으로 활성화하고 사용하는 것을 방지합니다.This allows the system to maintain the currency of the database through log shipping and replay, but prevents the system from automatically activating and using the copy. 활성화가 차단된 복사본은 관리자가 수동으로 활성화해야 합니다.Copies blocked for activation must be manually activated by an administrator. Update-mailboxdatabasecopy cmdlet을 사용 하 여 DatabaseCopyAutoActivationPolicy 를 설정 하 여 set-mailboxserver cmdlet 또는 개별 데이터베이스 복사본을 사용 하 여 전체 서버에 대 한 데이터베이스 활성화 정책을 구성할 수 있습니다. 매개 변수를 차단 합니다.You can configure the database activation policy for an entire server by using the Set-MailboxServer cmdlet or an individual database copy by using the Set-MailboxDatabaseCopy cmdlet to set the DatabaseCopyAutoActivationPolicy parameter to Blocked.

데이터베이스 활성화 정책 구성에 대한 자세한 내용은 사서함 데이터베이스 복사본에 대 한 정품 인증 정책 구성 항목을 참조하십시오.For more information about configuring database activation policy, see Configure activation policy for a mailbox database copy.

연속 복제에서 사서함 이동의 영향Effect of mailbox moves on continuous replication

로그 생성 속도가 높고 작업량이 매우 많은 사서함 데이터베이스에서는 수동 데이터베이스 복사본으로의 복제가 로그 생성 속도를 따라가지 못할 경우 데이터 손실의 가능성이 커집니다.On a very busy mailbox database with a high log generation rate, there is a greater chance for data loss if replication to the passive database copies can't keep up with log generation. 로그 생성 속도가 높아질 수 있는 한 가지 시나리오는 사서함 이동입니다.One scenario that can introduce a high log generation rate is mailbox moves. Exchange 2013에는 Microsoft Exchange 사서함 복제 서비스 (MRS)와 같은 서비스에서 DataMoveReplicationConstraint 매개 변수 값을 기반으로 데이터베이스 복사본 아키텍처 상태를 확인 하는 데 사용 하는 데이터 보장 API가 포함 되어 있습니다. 이는 시스템 또는 관리자에 의해 설정 된 것입니다.Exchange 2013 includes a Data Guarantee API that's used by services such as the Microsoft Exchange Mailbox Replication service (MRS) to check the health of the database copy architecture based on the value of the DataMoveReplicationConstraint parameter that was set by the system or an administrator. 데이터 보장 API는 다음과 같은 용도로 사용할 수 있습니다.Specifically, the Data Guarantee API can be used to:

  • 복제 상태 검사: 필수 데이터베이스 복사본 수를 사용할 수 있는지 확인 합니다.Check replication health: Confirms that the prerequisite number of database copies is available.

  • 복제 플러시 검사: 필수 데이터베이스 복사본 수에 대해 필요한 로그 파일이 재생 되었는지 확인 합니다.Check replication flush: Confirms that the required log files have been replayed against the prerequisite number of database copies.

API가 실행되면 호출 응용 프로그램에 다음과 같은 상태 정보를 반환합니다.When executed, the API returns the following status information to the calling application:

  • Retry: 일시적인 오류가 발생 하 여 조건을 데이터베이스에 대해 확인할 수 없음을 나타냅니다.Retry: Signifies that there are transient errors that prevent a condition from being checked against the database.

  • 만족: 데이터베이스가 필수 조건을 충족 하거나 데이터베이스가 복제 되지 않음을 나타냅니다.Satisfied: Signifies that the database meets the required conditions or the database isn't replicated.

  • Notsatisfied: 데이터베이스가 필요한 조건을 충족 하지 않는다는 것을 나타냅니다.NotSatisfied: Signifies that the database doesn't meet the required conditions. 또한 NotSatisfied 응답이 반환된 이유에 대한 정보가 호출 응용 프로그램에 제공됩니다.In addition, information is provided to the calling application as to why the NotSatisfied response was returned.

사서함 데이터베이스에 대 한 DataMoveReplicationConstraint 매개 변수의 값에 따라 요청의 일부로 평가 해야 하는 데이터베이스 복사본의 수가 결정 됩니다.The value of the DataMoveReplicationConstraint parameter for the mailbox database determines how many database copies should be evaluated as part of the request. DataMoveReplicationConstraint 매개 변수에는 다음과 같은 값을 사용할 수 있습니다.The DataMoveReplicationConstraint parameter has the following possible values:

  • None   사서함 데이터베이스를 만들 때이 값은 기본적으로 설정 됩니다.None   When you create a mailbox database, this value is set by default. 이 값을 설정하면 데이터 보장 API 조건은 무시됩니다.When this value is set, the Data Guarantee API conditions are ignored. 이 설정은 복제되지 않은 사서함 데이터베이스에만 사용해야 합니다.This setting should be used only for mailbox databases that aren't replicated.

  • SecondCopy   사서함 데이터베이스의 두 번째 복사본을 추가할 때이 값은 기본값입니다.SecondCopy   This is the default value when you add the second copy of a mailbox database. 이 값을 설정한 경우 최소 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족해야 합니다.When this value is set, at least one passive database copy must meet the Data Guarantee API conditions.

  • SecondDatacenter   이 값을 설정한 경우 다른 Active Directory 사이트에 있는 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족 해야 합니다.SecondDatacenter   When this value is set, at least one passive database copy in another Active Directory site must meet the Data Guarantee API conditions.

  • AllDatacenters   이 값을 설정한 경우 각 Active Directory 사이트에 있는 하나 이상의 수동 데이터베이스 복사본이 데이터 보장 API 조건을 충족 해야 합니다.AllDatacenters   When this value is set, at least one passive database copy in each Active Directory site must meet the Data Guarantee API conditions.

  • AllCopies   이 값을 설정 하면 사서함 데이터베이스의 모든 복사본이 데이터 보장 API 조건을 충족 해야 합니다.AllCopies   When this value is set, all copies of the mailbox database must meet the Data Guarantee API conditions.

복제 상태 확인Check Replication Health

데이터베이스 복사본 인프라의 상태를 평가하기 위해 데이터 보장 API가 실행될 경우 몇 개의 항목이 평가됩니다.When the Data Guarantee API is executed to evaluate the health of the database copy infrastructure, several items are evaluated.

DataMoveReplicationConstraint 매개 변수가 다음으로 설정 된 경우If the DataMoveReplicationConstraint parameter is set to... 그런 다음 지정 된 데이터베이스에 대해 ...Then, for a given database... 조건Conditions

SecondCopy

복제된 데이터베이스에 대한 하나 이상의 수동 데이터베이스 복사본이 다음 열의 조건을 충족해야 합니다.At least one passive database copy for a replicated database must meet the conditions in the next column.

수동 데이터베이스 복사본은The passive database copy must:

  • 정상 상태여야 합니다.Be healthy.

  • 재생 큐가 재생 지연 시간의 10분 내에 있어야 합니다.Have a replay queue within 10 minutes of the replay lag time.

  • 복사 큐 길이가 10개 로그 미만이어야 합니다.Have a copy queue length less than 10 logs.

  • 평균 복사 큐 길이가 10개 로그 미만이어야 합니다. 평균 복사 큐 길이는 응용 프로그램이 데이터베이스 상태를 쿼리한 횟수를 기반으로 계산됩니다.Have an average copy queue length less than 10 logs. The average copy queue length is computed based on the number of times the application has queried the database status.

SecondDatacenter

다른 Active Directory 사이트에서 최소 하나 이상의 수동 데이터베이스 복사본이 다음 열의 조건을 충족해야 합니다.At least one passive database copy in another Active Directory site must meet the conditions in the next column.

AllDatacenters

활성 복사본이 탑재되어야 하며 각 Active Directory 사이트의 수동 복사본이 다음 열의 조건을 충족해야 합니다.The active copy must be mounted, and a passive copy in each Active Directory site must meet the conditions in the next column.

AllCopies

활성 복사본이 탑재되어야 하며 모든 수동 데이터베이스 복사본이 다음 열의 조건을 충족해야 합니다.The active copy must be mounted, and all passive database copies must meet the conditions in the next column.

복제 플러시 확인Check Replication Flush

데이터 보장 API는 필수 데이터베이스 복사본 수가 필요한 트랜잭션 로그를 재생했는지 확인하는 데도 사용할 수 있습니다.The Data Guarantee API can also be used to validate that a prerequisite number of database copies have replayed the required transaction logs. 이를 확인하려면 마지막 로그 재생 타임스탬프를 호출 서비스의 커밋 타임스탬프(대개의 경우 필요한 데이터가 포함된 마지막 로그 파일의 타임스탬프)에 5초를 더한(시스템 시간 시계 편차를 처리하기 위해) 값과 비교합니다.This is verified by comparing the last log replayed timestamp with that of the calling service's commit timestamp (in most cases, this is the timestamp of the last log file that contains required data) plus an additional five seconds (to deal with system time clock skews or drift). 재생 타임 스탬프가 커밋 타임 스탬프 보다 크면 DataMoveReplicationConstraint 매개 변수가 충족 됩니다.If the replay timestamp is greater than the commit timestamp, the DataMoveReplicationConstraint parameter is satisfied. 재생 타임 스탬프가 커밋 타임 스탬프 보다 작으면 DataMoveReplicationConstraint 가 충족 되지 않습니다.If the replay timestamp is less than the commit timestamp, the DataMoveReplicationConstraint isn't satisfied.

DAG 내의 복제 데이터베이스 간에 많은 수의 사서함을 이동 하기 전에 다음에 따라 각 사서함 데이터베이스에 대해 DataMoveReplicationConstraint 매개 변수를 구성 하는 것이 좋습니다.Before moving large numbers of mailboxes to or from replication databases within a DAG, we recommend that you configure the DataMoveReplicationConstraint parameter on each mailbox database according to the following:

배포 하는 경우If you're deploying... DataMoveReplicationConstraint 설정 대상 ...Set DataMoveReplicationConstraint to...

데이터베이스 복사본이 없는 사서함 데이터베이스Mailbox databases that don't have any database copies

None

단일 Active Directory 사이트 내의 DAGA DAG within a single Active Directory site

SecondCopy

확장된 Active Directory 사이트를 사용하는 여러 데이터 센터의 DAGA DAG in multiple datacenters using a stretched Active Directory site

SecondCopy

두 Active Directory 사이트에 걸쳐 있는 DAG, 각 사이트마다 고가용성 데이터베이스 복사본이 있음A DAG that spans two Active Directory sites, and you will have highly available database copies in each site

SecondDatacenter

두 Active Directory 사이트에 걸쳐 있는 DAG, 두 번째 사이트에 지연된 데이터베이스 복사본만 있음A DAG that spans two Active Directory sites, and you will have only lagged database copies in the second site

SecondCopy

이렇게 설정하는 이유는 로그 파일이 데이터베이스 복사본으로 재생되기 전에는 데이터 보장 API가 데이터의 커밋을 보증하지 않기 때문이며, 지연된 데이터베이스 복사본 ReplayLagTime 시간이 30분 미만인 경우 외에는 지연된 데이터베이스 복사본의 특성으로 인해 이와 같은 제약 조건에서는 이동 요청이 실패합니다.This is because the Data Guarantee API won't guarantee data being committed until the log file is replayed into the database copy, and due to the nature of the database copy being lagged, this constraint will fail the move request, unless the lagged database copy ReplayLagTime value is less than 30 minutes.

세 개 이상의 Active Directory 사이트에 걸쳐 있는 DAG, 각 사이트는 고가용성 데이터베이스 복사본을 포함A DAG that spans three or more Active Directory sites, and each site will contain highly available database copies

AllDatacenters

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

DAG의 고유한 특성으로 인해 데이터베이스 전환 및 장애 조치(failover)의 결과로 활성 사서함 데이터베이스 복사본은 DAG의 수명 동안 여러 번 호스트를 변경합니다. 결과적으로 DAG는 활성 사서함 데이터베이스 복사본 배포 측면에서 불균형하게 될 수 있습니다. 다음 표에서는 활성 데이터베이스 복사본이 균등하게 배포되지 않은 각 데이터베이스의 복사본 4개가 포함된 4개의 데이터베이스(각 서버에서 총 16개의 데이터베이스)가 있는 DAG의 예를 보여 줍니다.Due to the inherent nature of DAGs, as the result of database switchovers and failovers, active mailbox database copies will change hosts several times throughout a DAG's lifetime. As a result, DAGs can become unbalanced in terms of active mailbox database copy distribution. The following table shows an example of a DAG that has four databases with four copies of each database (for a total of 16 databases on each server) with an uneven distribution of active database copies.

활성 복사본이 불균형하게 배포된 DAGDAG with unbalanced active copy distribution

ServerServer 활성 데이터베이스 수Number of active databases 수동 데이터베이스 수Number of passive databases 탑재된 데이터베이스 수Number of mounted databases 분리된 데이터베이스 수Number of dismounted databases 기본 설정 카운트 목록Preference count list

E X 1EX1

5 5

11 11

5 5

0

4, 4, 3, 54, 4, 3, 5

E X 2EX2

1 1

15 15

1 1

0

1, 8, 6, 11, 8, 6, 1

E X 3EX3

12 12

4 4

12 12

0

13, 2, 1, 013, 2, 1, 0

EX4EX4

1 1

15 15

1 1

0

1, 1, 5, 91, 1, 5, 9

위 예에서는 각 데이터베이스의 4개의 복사본이 있습니다. 따라서 활성화 기본 설정(1, 2, 3 또는 4)에 대한 4개의 가능한 값이 있습니다. 기본 설정 카운트 목록 열에서는 이러한 값 각각이 포함된 데이터베이스 수의 카운트를 보여 줍니다. 예를 들어 EX3에서는 활성화 기본 설정이 1인 13개의 데이터베이스 복사본, 활성화 기본 설정이 2인 2개의 복사본, 활성화 기본 설정이 3인 1개의 복사본이 있으며 활성화 기본 설정이 4인 복사본은 없습니다.In the preceding example, there are four copies of each database, and therefore, only four possible values for activation preference (1, 2, 3, or 4). The Preference count list column shows the count of the number of databases with each of these values. For example, on EX3, there are 13 database copies with an activation preference of 1, two copies with an activation preference of 2, one copy with an activation preference of 3, and no copies with an activation preference of 4.

표시된 것처럼, 이 DAG는 각 DAG 구성원이 호스트하는 활성 데이터베이스 수, 각 DAG 구성원이 호스트하는 수동 데이터베이스 수 또는 호스트된 데이터베이스의 활성화 기본 설정 카운트를 고려하여 균형이 조정되지 않았습니다.As you can see, this DAG isn't balanced in terms of the number of active databases hosted by each DAG member, the number of passive databases hosted by each DAG member, or the activation preference count of the hosted databases.

RedistributeActiveDatabases.ps1 스크립트를 사용하여 활성 사서함 데이터베이스 복사본을 DAG 간에 균형 조정할 수 있습니다. DAG의 각 서버에서 탑재된 데이터베이스 수가 동일하게 되도록 하기 위해 이 스크립트는 해당 복사본 간에 데이터베이스를 이동합니다. 또한 필요한 경우 이 스크립트는 사이트 간에 활성 데이터베이스를 균형 있게 조정하려고 시도합니다.You can use the RedistributeActiveDatabases.ps1 script to balance the active mailbox databases copies across a DAG. This script moves databases between their copies in an attempt to have an equal number of mounted databases on each server in DAG. If required, the script also attempts to balance active databases across sites.

이 스크립트는 DAG 내에서 활성 데이터베이스 복사본을 균형 있게 조정하기 위한 두 가지 옵션을 제공합니다.The script provides two options for balancing active database copies within a DAG:

  • BalanceDbsByActivationPreference:이 옵션을 지정 하면 스크립트는 Active Directory 사이트에 관계 없이 가장 선호 되는 복사본 (활성화 기본 설정 기준)으로 데이터베이스를 이동 하려고 시도 합니다.BalanceDbsByActivationPreference: When this option is specified, the script attempts to move databases to their most preferred copy (based on activation preference) without regard to the Active Directory site.

  • BalanceDbsBySiteAndActivationPreference:이 옵션을 지정 하면 스크립트에서 활성 데이터베이스를 가장 선호 되는 복사본으로 이동 하려고 하지만, 각 active Directory 사이트 내에서 활성 데이터베이스의 균형도 조정 하려고 시도 합니다.BalanceDbsBySiteAndActivationPreference: When this option is specified, the script attempts to move active databases to their most preferred copy, while also trying to balance active databases within each Active Directory site.

첫 번째 옵션으로 스크립트를 실행하면 다음 표에서와 같이 위의 불균형한 DAG가 균형 있게 조정됩니다.After running the script with the first option, the preceding unbalanced DAG becomes balanced, as shown in the following table.

활성 복사본이 균형 있게 배포된 DAGDAG with balanced active copy distribution

ServerServer 활성 데이터베이스 수Number of active databases 수동 데이터베이스 수Number of passive databases 탑재된 데이터베이스 수Number of mounted databases 분리된 데이터베이스 수Number of dismounted databases 기본 설정 카운트 목록Preference count list

E X 1EX1

4 4

12 12

4 4

0

4, 4, 4, 44, 4, 4, 4

E X 2EX2

4 4

12 12

4 4

0

4, 4, 4, 44, 4, 4, 4

E X 3EX3

4 4

12 12

4 4

0

4, 4, 4, 44, 4, 4, 4

EX4EX4

4 4

12 12

4 4

0

4, 4, 4, 44, 4, 4, 4

위의 표에서와 같이 이 DAG는 이제 각 서버의 활성 및 수동 데이터베이스 수와 서버 간에 활성화 기본 설정을 고려하여 균형 있게 조정되었습니다.As shown in the preceding table, this DAG is now balanced in terms of number of active and passive databases on each server and activation preference across the servers.

다음 표에서는 RedistributeActiveDatabases.ps1 스크립트에 사용할 수 있는 매개 변수를 보여 줍니다.The following table lists the available parameters for the RedistributeActiveDatabases.ps1 script.

RedistributeActiveDatabases.ps1 스크립트 매개 변수RedistributeActiveDatabases.ps1 script parameters

매개 변수Parameter 설명Description

DagNameDagName

균형을 다시 조정하려는 DAG 이름을 지정합니다. 이 매개 변수를 생략하면 로컬 서버가 구성원으로 속한 DAG가 사용됩니다.Specifies the name of the DAG you want to rebalance. If this parameter is omitted, the DAG of which the local server is a member is used.

BalanceDbsByActivationPreferenceBalanceDbsByActivationPreference

스크립트가 Active Directory 사이트에 관계 없이 가장 선호 되는 복사본으로 데이터베이스를 이동 하도록 지정 합니다.Specifies that the script should move databases to their most preferred copy without regard to the Active Directory site.

BalanceDbsBySiteAndActivationPreferenceBalanceDbsBySiteAndActivationPreference

스크립트에서 활성 데이터베이스를 가장 선호 되는 복사본으로 이동 하 되, 각 Active Directory 사이트 내에서 활성 데이터베이스의 균형을 조정 하려고 시도 하도록 지정 합니다.Specifies that the script should attempt to move active databases to their most preferred copy, while also trying to balance active databases within each Active Directory site.

Show\ 데이터베이스 배포ShowFinalDatabaseDistribution

재배포가 완료되면 현재 데이터베이스 배포 보고서가 표시되도록 지정합니다.Specifies that a report of current database distribution be displayed after redistribution is complete.

AllowedDeviationFromMeanPercentageAllowedDeviationFromMeanPercentage

백분율로 표시되는 사이트 간에 활성 데이터베이스의 허용되는 변형을 지정합니다. 기본값은 20%입니다. 예를 들어 세 개의 사이트 간에 배포된 99개의 데이터베이스가 있는 경우 적절한 배포는 각 사이트에서 33개의 데이터베이스입니다. 허용되는 편차가 20%인 경우 스크립트가 데이터베이스를 균형 있게 조정하려고 시도하므로 각 사이트에는 이 수의 10% 정도가 있어야 합니다. 33의 10%는 3.3이며 4로 반올림됩니다. 따라서 스크립트는 각 사이트에 29개에서 37개의 데이터베이스가 있도록 시도합니다.Specifies the allowed variation of active databases across sites, expressed as a percentage. The default is 20%. For example, if there were 99 databases distributed between three sites, the ideal distribution would be 33 databases in each site. If the allowed deviation is 20%, the script attempts to balance the databases so that each site has no more than 10% more or less than this number. 10% of 33 is 3.3, which is rounded up to 4. Therefore, the script attempts to have between 29 and 37 databases in each site.

ShowDatabaseCurrentActivesShowDatabaseCurrentActives

스크립트가 데이터베이스를 이동한 방법 및 가장 선호되는 복사본에서 데이터베이스가 지금 활성화되어 있는지 여부를 자세히 나타내는 각 데이터베이스의 보고서를 생성하도록 지정합니다.Specifies that the script produce a report for each database detailing how the database was moved and whether it's now active on its most-preferred copy.

ShowDatabaseDistributionByServerShowDatabaseDistributionByServer

스크립트가 데이터베이스 배포를 나타내는 각 서버의 보고서를 생성하도록 지정합니다.Specifies that the script produce a report for each server showing its database distribution.

Runonly OnpamRunOnlyOnPAM

스크립트가 현재 PAM 역할이 있는 DAG 구성원에서만 실행되도록 지정합니다. 스크립트가 PAM에서 실행되고 있는지 확인합니다. PAM에서 실행되고 있지 않은 경우 스크립트가 종료됩니다.Specifies that the script run only on the DAG member that currently has the PAM role. The script verifies it's being run from the PAM. If it isn't being run from the PAM, the script exits.

LogEventsLogEvents

스크립트가 작업 요약을 포함하여 이벤트(MsExchangeRepl 이벤트 4115)를 기록하도록 지정합니다.Specifies that the script logs an event (MsExchangeRepl event 4115) containing a summary of the actions.

IncludeNonReplicatedDatabasesIncludeNonReplicatedDatabases

스크립트가 활성 데이터베이스를 다시 배포하는 방법 결정 시 복제되지 않은 데이터베이스(복사본이 없는 데이터베이스)를 포함하도록 지정합니다. 복제되지 않은 데이터베이스는 이동될 수 없지만 복제된 데이터베이스 배포에 영향을 줄 수 있습니다.Specifies that the script should include non-replicated databases (databases without copies) when determining how to redistribute the active databases. Although non-replicated databases can't be moved, they may affect the distribution of the replicated databases.

ConfirmConfirm

Confirm 스위치를 사용하면 이 스크립트를 실행할 때 기본적으로 나타나는 확인 메시지를 표시하지 않을 수 있습니다. 확인 메시지를 표시하지 않으려면 -Confirm:$False 구문을 사용합니다. 구문에 콜론(: )을 포함해야 합니다.The Confirm switch can be used to suppress the confirmation prompt that appears by default when this script is run. To suppress the confirmation prompt, use the syntax -Confirm:$False. You must include a colon ( : ) in the syntax.

RedistributeActiveDatabases.ps1 예RedistributeActiveDatabases.ps1 examples

이 예는 기본 설정 카운트 목록을 포함하여 DAG에 대한 현재 데이터베이스 배포를 보여 줍니다.This example shows the current database distribution for a DAG, including preference count list.

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

이 예는 입력을 요청하지 않고 활성 기본 설정을 사용하여 DAG에서 활성 사서함 데이터베이스 복사본을 다시 배포하고 균형 있게 조정합니다.This example redistributes and balances the active mailbox database copies in a DAG using activation preference without prompting for input.

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

이 예는 활성 기본 설정을 사용하여 DAG에서 활성 사서함 데이터베이스 복사본을 다시 배포하고 균형 있게 조정하며 배포 요약을 생성합니다.This example redistributes and balances the active mailbox database copies in a DAG using activation preference, and produces a summary of the distribution.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

데이터베이스 복사본 모니터링Monitoring database copies

데이터베이스 복사본은 데이터베이스의 활성 복사본에 영향을 주는 오류가 발생할 경우 첫 번째 방어 수단입니다. 따라서 필요할 때 사용할 수 있으려면 데이터베이스 복사본의 상태를 모니터링하는 것이 중요합니다. EAC에서 데이터베이스 복사본의 상세 정보를 확인하면 복사 큐 길이, 재생 큐 길이, 상태 및 콘텐츠 인덱스 상태 정보를 포함한 다양한 정보를 볼 수 있습니다. 또한 셸에서 Get-MailboxDatabaseCopyStatus cmdlet을 사용하여 데이터베이스 복사본의 다양한 상태 정보를 볼 수도 있습니다.A database copy is your first defense if a failure occurs that affects the active copy of a database. It's therefore critical to monitor the health and status of database copies to ensure that they will be available when needed. You can view a variety of information, including copy queue length, replay queue length, status, and content index state information, by examining the details of a database copy in the EAC. You can also use the Get-MailboxDatabaseCopyStatus cmdlet in the Shell to view a variety of status information for a database copy.

데이터베이스 복사본 모니터링에 대 한 자세한 내용은 데이터베이스 사용 가능 그룹 모니터링을 참조 하십시오.For more information about monitoring database copies, see Monitoring database availability groups.

데이터베이스 복사본 제거Removing a database copy

EAC를 사용하거나 셸에서 Remove-MailboxDatabaseCopy cmdlet을 사용하여 데이터베이스 복사본을 언제든지 제거할 수 있습니다. 데이터베이스 복사본을 제거한 후에는 데이터베이스 복사본을 제거하고 있는 서버에서 모든 데이터베이스 및 트랜잭션 로그 파일을 수동으로 삭제해야 합니다. 데이터베이스 복사본을 제거하는 방법에 대한 자세한 단계는 사서함 데이터베이스 복사본을 제거 합니다.를 참조하십시오.A database copy can be removed at any time by using the EAC or by using the Remove-MailboxDatabaseCopy cmdlet in the Shell. After removing a database copy, you must manually delete any database and transaction log files from the server from which the database copy is being removed. For detailed steps about how to remove a database copy, see Remove a mailbox database copy.

데이터베이스 전환Database switchovers

데이터베이스의 활성 복사본을 호스트하는 사서함 서버를 사서함 데이터베이스 마스터라고 합니다. 수동 데이터베이스 복사본을 활성화하는 프로세스는 데이터베이스의 사서함 데이터베이스 마스터를 변경시키고 수동 복사본을 새로운 활성 복사본으로 전환합니다. 이 프로세스를 데이터베이스 전환이라고 합니다. 데이터베이스 전환에서는 데이터베이스의 활성 복사본이 특정 사서함 서버에서 분리되고, 해당 데이터베이스의 수동 복사본이 새 활성 사서함 데이터베이스로 다른 사서함 서버에 탑재됩니다. 전환을 수행할 때 새 사서함 데이터베이스 마스터에서 데이터베이스 탑재 다이얼 설정을 다시 정의할 수 있습니다.The Mailbox server that hosts the active copy of a database is referred to as the mailbox database master. The process of activating a passive database copy changes the mailbox database master for the database and turns the passive copy into the new active copy. This process is called a database switchover. In a database switchover, the active copy of a database is dismounted on one Mailbox server and a passive copy of that database is mounted as the new active mailbox database on another Mailbox server. When performing a switchover, you can optionally override the database mount dial setting on the new mailbox database master.

EAC의 데이터베이스 복사본 탭에서 오른쪽 열을 확인하여 어떤 사서함 서버가 현재 사서함 데이터베이스 마스터인지 신속하게 알아볼 수 있습니다. EAC에서 활성화 링크를 사용하거나 셸에서 Move-ActiveMailboxDatabase cmdlet을 사용하여 전환을 수행할 수 있습니다.You can quickly identify which Mailbox server is the current mailbox database master by reviewing the right-hand column under the Database Copies tab in the EAC. You can perform a switchover by using the Activate link in the EAC, or by using the Move-ActiveMailboxDatabase cmdlet in the Shell.

수동 복사본을 활성화하기 전에 수행될 몇몇 내부 검사가 있습니다.There are several internal checks that will be performed before activating a passive copy:

  • 데이터베이스 복사본의 상태를 확인합니다.The status of the database copy is checked. 데이터베이스 복사본이 실패 상태이면 전환이 차단됩니다.If the database copy is in a failed state, the switchover is blocked. 이동-ActiveMailboxDatabase Cmdlet의 SkipHealthChecks 매개 변수를 사용 하 여이 동작을 다시 정의 하 고 상태 검사를 무시할 수 있습니다.You can override this behavior and bypass the health check by using the SkipHealthChecks parameter of the Move-ActiveMailboxDatabase cmdlet. 이 매개 변수는 활성 복사본을 실패 상태인 데이터베이스 복사본으로 이동하는 데 사용됩니다.This parameter allows you to move the active copy to a database copy in a failed state.

  • 활성 데이터베이스 복사본이 현재 데이터베이스의 수동 복사본에 대한 시드 원본인지 여부를 검사합니다.The active database copy is checked to see if it's currently a seeding source for any passive copies of the database. 활성 복사본이 현재 시드 원본으로 사용 중인 경우에는 전환이 차단됩니다.If the active copy is currently being used as a source for seeding, the switchover is blocked. 이동-ActiveMailboxDatabase Cmdlet의 Skipactivecopychecks 매개 변수를 사용 하 여이 동작을 다시 정의 하 고 시드 원본 검사를 무시할 수 있습니다.You can override this behavior and bypass the seeding source check by using the SkipActiveCopyChecks parameter of the Move-ActiveMailboxDatabase cmdlet. 이 매개 변수를 사용하면 시드 원본으로 사용 중인 활성 복사본을 이동할 수 있습니다.This parameter allows you to move an active copy that's being used as a seeding source. 이 매개 변수를 사용할 경우 시드 작업이 취소되고 실패한 것으로 간주됩니다.Using this parameter will cause the seeding operation to be cancelled and considered failed.

  • 데이터베이스 복사본의 복사 큐와 재생 큐 길이를 검사하여 그 값이 구성된 기준 내에 있는지 확인합니다.The copy queue and replay queue lengths for the database copy are checked to ensure their values are within the configured criteria. 또한 데이터베이스 복사본이 시드를 위한 원본으로 현재 사용되고 있지 않은지 확인합니다.Also, the database copy is verified to ensure that it isn't currently in use as a source for seeding. 큐 길이에 대한 값이 구성된 기준을 벗어나거나 데이터베이스가 시드를 위한 원본으로 현재 사용 중이면 전환이 차단됩니다.If the values for the queue lengths are outside the configured criteria, or if the database is currently used as a source for seeding, the switchover is blocked. 이동-ActiveMailboxDatabase Cmdlet의 SkipLagChecks 매개 변수를 사용 하면이 동작을 다시 정의 하 고 이러한 검사를 무시할 수 있습니다.You can override this behavior and bypass these checks by using the SkipLagChecks parameter of the Move-ActiveMailboxDatabase cmdlet. 이 매개 변수는 구성된 기준을 벗어나는 재생 큐 및 복사 큐가 있는 복사본을 활성화하는 데 사용됩니다.This parameter allows a copy to be activated that has replay and copy queues outside of the configured criteria.

  • 데이터베이스 복사본의 검색 카탈로그 상태(콘텐츠 인덱스)를 확인합니다.The state of the search catalog (content index) for the database copy is checked. 검색 카탈로그가 최신 상태가 아니거나, 비정상 상태이거나, 손상된 경우 전환이 차단됩니다.If the search catalog isn't up to date, is in an unhealthy state, or is corrupt, the switchover is blocked. 이동-ActiveMailboxDatabase Cmdlet의 SkipClientExperienceChecks 매개 변수를 사용 하 여이 동작을 다시 정의 하 고 검색 카탈로그 검사를 무시할 수 있습니다.You can override this behavior and bypass the search catalog check by using the SkipClientExperienceChecks parameter of the Move-ActiveMailboxDatabase cmdlet. 이 매개 변수는 이 검색이 카탈로그 상태 검사를 건너뛰게 하는 데 사용됩니다.This parameter causes this search to skip the catalog health check. 활성화할 데이터베이스 복사본의 검색 카탈로그가 비정상이거나 사용할 수 없는 상태인 경우 이 매개 변수를 사용하여 카탈로그 상태 검사를 건너뛰고 데이터베이스 복사본을 활성화하면 검색 카탈로그를 다시 크롤링하거나 시드해야 합니다.If the search catalog for the database copy you're activating is in an unhealthy or unusable state and you use this parameter to skip the catalog health check and activate the database copy, you will need to either crawl or seed the search catalog again.

데이터베이스 전환을 수행할 때 현재 활성화되어 있는 수동 데이터베이스 복사본을 호스트하는 서버에 구성된 탑재 다이얼 설정을 다시 정의할 수 있습니다.When performing a database switchover, you also have the option of overriding the mount dial settings configured for the server that hosts the passive database copy being activated. 이동-ActiveMailboxDatabase Cmdlet의 MountDialOverride 매개 변수를 사용 하 여 대상 서버에서 자체 탑재 다이얼 설정을 재정의 하 고 MountDialOverride 매개 변수에 지정 된 것을 사용 하도록 합니다.Using the MountDialOverride parameter of the Move-ActiveMailboxDatabase cmdlet instructs the target server to override its own mount dial settings and use those specified by the MountDialOverride parameter.

데이터베이스 복사본 전환을 수행하는 방법의 자세한 단계는 사서함 데이터베이스 복사본 활성화 항목을 참조하십시오.For detailed steps about how to perform a switchover of a database copy, see Activate a mailbox database copy.