Управление копиями базы данных почтовых ящиковManage mailbox database copies

В Exchange Server с помощью консоли управления Exchange или командной консоли Exchange можно добавлять копии баз данных почтовых ящиков после создания, настройки и заполнения группы обеспечения доступности баз данных (DAG).In Exchange Server, you can use the Exchange Management Console (EAC) or the Exchange Management Shell to add mailbox database copies after a database availability group (DAG) has been created, configured, and populated with Mailbox server members.

Управление копиями базы данныхManaging database copies

Центр администрирования Exchange и Командная консоль Exchange позволяют отслеживать работоспособность и состояние копий базы данных, а также управлять ими, в том числе приостанавливать и возобновлять их работу, заполнять, отслеживать, настраивать и удалять.After multiple copies of a database are created, you can use the EAC or the Exchange Management 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

По ряду причин, например для планового обслуживания, может потребоваться приостановить и возобновить непрерывную репликацию копии базы данных. Кроме того, приостановить копию базы данных требуется для выполнения некоторых административных задач, таких как заполнение. Рекомендуется приостанавливать репликацию при изменении пути к базе данных или к ее файлам журнала. Чтобы приостановить и возобновить работу копии базы данных, используйте Центр администрирования Exchange или запустите командлеты Suspend-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy в командной консоли Exchange. Подробные инструкции см. в статье Приостановка или возобновление работы копии базы данных почтовых ящиков.For a variety of reasons, such as performing planned maintenance, you may need to suspend and resume continuous replication activity for a database copy. In addition, some administrative tasks, such as seeding, require that you first suspend a database copy. We recommend that you suspend all replication activity 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 Exchange Management 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 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, you can seed a database by using 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. Если вы хотите вручную заполнить копию базы данных и не использовать автоматическое заполнение при создании копии, можно использовать параметр SeedingPostponed при запуске командлета Add — MailboxDatabaseCopy .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.

Иногда необходимо повторно заполнить копии базы данных после первоначального заполнения. Чтобы повторно заполнить копию базы данных или заполнить ее вручную, используйте мастер обновления копии базы данных в Центре администрирования Exchange или командлет Update-MailboxDatabaseCopy в командной консоли Exchange. Перед заполнением копии базы данных необходимо приостановить работу копии базы данных почтовых ящиков. Подробное описание действий по заполнению копии базы данных см. в разделе Обновление копии базы данных почтовых ящиков.Database copies rarely need to be reseeded after the initial seeding. However, if reseeding is necessary, or if you want to manually seed a database copy instead of having the system automatically seed the copy, you have two options. You can reseed a database by using the Update Mailbox Database Copy wizard in the EAC or by using the Update-MailboxDatabaseCopy cmdlet in the Exchange Management 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. Если автоматическое возобновление репликации не требуется, необходимо использовать параметр ManualResume при запуске командлета Update-MailboxDatabaseCopy.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 you perform 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 заполняют копию базы данных почтовых ящиков и копию каталога индексов содержимого.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. Чтобы заполнить только копию базы данных почтовых ящиков без заполнения каталога индексов содержимого, используйте параметр DatabaseOnly при запуске командлета Update – MailboxDatabaseCopy .To seed just the mailbox database copy without seeding the content index catalog, use the DatabaseOnly parameter when running the Update-MailboxDatabaseCopy cmdlet. Чтобы заполнить только копию каталога индексов содержимого, используйте параметр CatalogOnly при запуске командлета Update-MailboxDatabaseCopy.To seed just the content index catalog copy, use the CatalogOnly parameter when running the Update-MailboxDatabaseCopy cmdlet.

Выбор источника заполненияSelecting the seeding source

Исправную копию базы данных можно использовать в качестве источника заполнения для дополнительной копии этой базы данных. Это может быть полезно, если группа доступности базы данных развернута в нескольких физических местоположениях. В качестве примера рассмотрим развертывание группы доступности базы данных из четырех участников, в которой два участника (MBX1 и MBX2) находятся в Москве, а другие два участника (MBX3 и MBX4) — в Санкт-Петербурге. База данных почтовых ящиков с именем DB1 активна в MBX1, а пассивные копии DB1 расположены в MBX2 и MBX3. При добавлении копии DB1 в MBX4 вы можете использовать копию в MBX3 как источник для заполнения. При этом вы избегаете заполнения по каналу глобальной сети между Москвой и Санкт-Петербургом.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 can do the following:

  • Используйте параметр SeedingPostponed при запуске командлета Add – MailboxDatabaseCopy для добавления копии базы данных.Use the SeedingPostponed parameter when running the Add-MailboxDatabaseCopy cmdlet to add the database copy. Если не использовать параметр SeedingPostponed , копия базы данных будет явно заполнена с использованием активной копии базы данных в качестве источника.If you don't use the SeedingPostponed parameter, the database copy will be explicitly seeded using the active copy of the database as the source.

  • Вы можете указать исходный сервер, который будет использоваться в составе мастера обновления базы данных почтовых ящиков в центре администрирования Exchange, или можно использовать параметр саурцесервер при запуске командлета Update – MailboxDatabaseCopy , чтобы указать нужный исходный сервер для заполнения.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 you don' t use SourceServer parameter, the database copy will be explicitly seeded from the active copy of the database.

Заполнение и сетиSeeding and networks

Кроме исходного сервера, вы можете указать сети DAG, которые следует использовать для заполнения копии базы данных. Используйте для этого командную консоль Exchange. Вы можете переопределить параметры сжатия и шифрования сети DAG во время операции заполнения.In addition to selecting a specific source server for seeding a mailbox database copy, you can also use the Exchange Management Shell to specify which DAG networks to use. You have the option to override the DAG network's compression and encryption settings during the seed operation.

Вы можете указать сети, которые будут использоваться для заполнения, с помощью параметра Network при запуске командлета Update – MailboxDatabaseCopy и указать сети DAG, которые необходимо использовать.You can specify the networks you want to use for seeding by using 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.At the DAG level, DAG networks are configured for encryption and compression. По умолчанию шифрование и сжатие используются только для обмена данными в разных подсетях.The default settings use encryption and compression only for communications on different subnets. Если исходный и целевой серверы находятся в разных подсетях и для группы DAG заданы значения параметров NetworkCompression и NetworkEncryption по умолчанию, вы можете переопределить эти значения, используя параметры NetworkCompressionOverride и NetworkEncryptionOverride соответственно при запуске командлета Update-MailboxDatabaseCopy.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 выполняются следующие задачи:When you begin a seeding process by using the Add-MailboxDatabaseCopy or Update-MailboxDatabaseCopy cmdlets, the following tasks are performed:

  1. Свойства базы данных из Active Directory считываются для проверки указанных баз данных и серверов, а также для проверки того, что на исходном и целевом серверах выполняется Exchange Server, они являются членами одной группы обеспечения доступности баз данных и что указанная база данных не является восстановлением базу.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 Server, 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 на целевом сервере проверяет наличие базы данных и файлов журнала транзакций в каталогах файлов, считанных при проверке Active Directory на шаге 1.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 возвращает сведения о состоянии из целевого сервера в интерфейс администратора, в котором запущен командлет.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. Запрос на заполнение базы данных оправляется из службы репликации Microsoft Exchange на целевом сервере в службу репликации Microsoft Exchange на исходном сервере с помощью протокола TCP. Этот запрос и последующее подключения для заполнения базы данных выполняются в сети группы доступности базы данных, настроенной в качестве сети репликации.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 на исходном сервере запускает потоковую архивацию расширенного обработчика хранилищ (ESE) с помощью интерфейса службы банка данных Microsoft Exchange.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 — seeding.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 на целевом сервере записывает данные каталога во временный каталог с именем CiSeed. 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. Конечный результат операции проходит в интерфейс администратора, в котором был запущен командлет.The final result of the operation is passed to the administrative interface from which the cmdlet was called.

Настройка копий базы данныхConfiguring database copies

Просмотреть информацию о конфигурации копии базы данных можно на ее странице Свойства в Центре администрирования Exchange. Просмотреть и настроить параметры копии базы данных, такие как интервал задержки воспроизведения, интервал задержки усечения и приоритет активации, можно с помощью командлетов Get-MailboxDatabase и Set-MailboxDatabaseCopy в командной консоли Exchange. Подробные инструкции см. в статье Настройка свойств копии базы данных почтовых ящиков.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 Exchange Management 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

Интервал задержки воспроизведения — свойство копии базы данных почтовых ящиков, которое определяет интервал задержки воспроизведения журнала для копии базы данных (в минутах).Replay lag time is a mailbox database copy property 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. Копия базы данных почтовых ящиков, для которой настроен интервал задержки воспроизведения больше 0, называется изолированной копией базы данных почтовых ящиков, или просто изолированной копией.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 Server, может обеспечить защиту от ряда сбоев, которые обычно приводят к потере данных.A strategy that uses database copies and the litigation hold features in Exchange Server 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. Это происходит, когда расширенный обработчик хранилищ пытается записать страницу базы данных, и несмотря на то, что отображается сообщение об успешном завершении операции, данные либо вообще не записываются на диск, либо записываются в неправильном месте.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 Server обеспечивает защиту от логического повреждения хранилища (так как предотвращает окончательное удаление содержимого пользователем или приложением).The litigation hold feature in Exchange Server 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.

Комбинация копий базы данных, политики удержания и восстановления одиночной страницы с помощью расширенного обработчика хранилищ предотвращает редкие катастрофические случаи логического повреждения хранилища. Решение о том, использовать копию базы данных с задержкой преобразования (изолированную копию), зависит от используемых сторонних приложений и от опыта исправления логических повреждений хранилища в организации.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.

При использовании изолированных копий необходимо учитывать следующие последствия.If you choose to use lagged copies, be aware of the following implications for their use:

  • Существует настраиваемое администратором значение времени задержки преобразования, и по умолчанию оно отключено.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) для защиты отдельной изолированной копии при отсутствии нескольких изолированных копий. При потере или повреждении диска отложенная во времени точка не будет потеряна.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. Если произойдет повреждение страницы базы данных (например, ошибка 1018), изолированную копию придется заполнить повторно (что приведет к потере изолированности копии).Lagged copies cant be patched with the ESE single page restore feature. If a lagged copy encounters database page corruption (for example, a -1018 error), the copy will have to be reseeded. Reseeding will lose the lagged aspect of the copy.

Если вы хотите воспроизвести все файлы журнала и обновить копию базы данных, активировать и восстановить изолированную копию базы данных почтовых ящиков легко. Если вы хотите воспроизвести файлы журнала до определенного момента, задача становится сложнее, так как необходимо вручную управлять файлами журнала и запускать служебные программы Exchange Server (Eseutil.exe).If you want the database to replay all log files and make the database copy current, then activating and recovering a lagged mailbox database copy is an easy process . If you want to replay log files up to a specific point in time, the prosess is more difficult because you have to manually manipulate log files and run Exchange Server Database Utilities (Eseutil.exe).

Подробное описание процедуры активации копии базы данных почтовых ящиков изолированной можно найти в разделе Активация копии базы данных почтовых ящиков изолированной.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 the 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 2016 и Exchange 2019, как и в Exchange 2010.Log truncation works the same in Exchange 2016 and Exchange 2019 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 (except 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 Server усечение журнала не происходит в активной копии базы данных почтовых ящиков, когда одна или несколько пассивных копий приостанавливаются.In Exchange Server, 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 Server теперь используется функция свободного усечения , которая отключена по умолчанию.Exchange Server now has a feature called loose truncation that 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.

Поведение усечения отличается при включении свободного усечения и циклического ведения журнала.Truncation behavior is different when loose truncation and circular logging are enabled. Каждая копия базы данных отслеживает собственное свободное место на диске и применяет свободное усечение, если свободное место заканчивается.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.

  • Пассивная копия: если место заканчивается, она самостоятельно усекает свои файлы журналов, используя настроенные параметры, описанные ниже в таблице "Значение реестра". Пассивные копии пытаются учитывать решение об усечении, принятое для активной копии. Несмотря на свое имя (MinCopiesToProtect), Exchange будет игнорировать самую старую пассивную копию базы данных при запуске усечения.For a passive copy, if space gets low, it will independently truncate its log files using the configured parameters described later in the Registry Value table.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.

Если ранее недоступная база данных снова станет доступной, в ней будут отсутствовать файлы журналов, удаленные из других исправных копий. Ее состояние будет отображаться как FailedAndSuspended (сбой и приостановка). В этом случае, если настроена функция автоматического повторного заполнения, поврежденная копия будет автоматически заполнена данными. Если эта функция не настроена, администратору придется заполнить копию базы данных вручную.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.

Если циклическое ведение журнала отключено, свободное усечение учитывает резервные копии, если они были выполнены, поэтому, если журналы не были архивированы, они не будут удалены при свободном усечении.If circular logging is disabled, loose truncation respects backups if they have been taken, so if logs have not been backed up they will not be removed by loose Truncation.

усечение — это рекомендуемая функция для предпочтительной архитектуры, в которой не используются резервные копии и циклическое ведение журнала включено.truncation is a recommended feature for preferred architecture where backups are not used and circular logging is enabled.

Необходимое количество исправных копий, минимальный порог свободного дискового пространства и число журналов являются настраиваемыми параметрами. По умолчанию порог свободного дискового пространства составляет 204 800 МБ (200 ГБ). Число журналов составляет 100 000 (100 ГБ) для пассивных и 10 000 (10 ГБ) для активных копий.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.

Включение и настройка свободного усечения выполняется путем изменения реестра Windows для каждого участника группы DAG. Существует три настраиваемых значения реестра. Все они хранятся в разделе HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. Указанные ниже значения DWORD не существуют по умолчанию, их нужно создать вручную. Значения реестра DWORD из раздела BackupInformation описаны в следующей таблице.Enabling loose truncation and configuring loose truncation parameters is performed by editing the Windows registry on each DAG member. There are three registry values that can be configured, that are all stored under HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. The BackupInformation key the following DWORD values do not exist by default and must be manually created. The DWORD registry values under BackupInformation are described in the following table:

Значение реестраRegistry Value ОписаниеDescription Значение по умолчаниюDefault Value
Лусетрункатион_минкопиестопротектLooseTruncation_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_MinDiskFreeSpaceThresholdInMB Пороговое значение доступного места на диске (в МБ) для запуска свободных усечений. Если количество свободного места на диске падает ниже этого значения, происходит запуск свободных усечений.Available disk space (in MB) threshold for triggering loose truncation. If free disk space falls below this value, loose truncation is triggered. Если этот параметр реестра не настроен, при свободном усечении используется параметр по умолчанию (200 ГБ).If this registry value is not configured, the default value used by loose truncation is 200 GB.
Лусетрункатион_минлогстопротектLooseTruncation_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. 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're 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. Политику активации базы данных для всего сервера можно настроить с помощью командлета Set – MailboxServer или отдельной копии базы данных с помощью командлета Set – MailboxDatabaseCopy для установки DatabaseCopyAutoActivationPolicy Заблокированный параметр.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 Server включает в себя API-интерфейс, который используется службами, такими как служба репликации почтовых ящиков Exchange (MRS), для проверки работоспособности архитектуры копии базы данных на основе значения параметра DataMoveReplicationConstraint , который был задается системой или администратором.Exchange Server includes a Data Guarantee API that's used by services such as the 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 Data Guarantee может использоваться для: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: 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. Если задано это значение, условия интерфейса Data Guarantee 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. Если задано это значение, по крайней мере одна пассивная копия базы данных должна соответствовать условиям Data Guarantee 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

При выполнении Data Guarantee API для оценки работоспособности инфраструктуры копий баз данных, оцениваются несколько элементов.When the Data Guarantee API is executed to evaluate the health of the database copy infrastructure, several items are evaluated.

Во всех сценариях пассивная копия базы данных должна удовлетворять следующим условиям:In all scenarios, the passive database copy must meet the following conditions:

  • быть работоспособной;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.


Если для параметра DataMoveReplicationConstraint задано значение...If the DataMoveReplicationConstraint parameter is set to... Затем для заданной базы данных...Then, for a given database...
SecondCopy По крайней мере одна пассивная копия базы данных для реплицированной базы данных должна соответствовать описанным выше условиям.At least one passive database copy for a replicated database must meet the previously described conditions.
SecondDatacenter По крайней мере одна пассивная копия базы данных на другом сайте Active Directory должна соответствовать описанным выше условиям.At least one passive database copy in another Active Directory site must meet the previously described conditions.
AllDatacenters Активная копия должна быть подключена, а пассивная копия на каждом сайте Active Directory должна соответствовать описанным выше условиям.The active copy must be mounted, and a passive copy in each Active Directory site must meet the previously described conditions.
AllCopies Активная копия должна быть подключена, а все пассивные копии базы данных должны соответствовать описанным выше условиям.The active copy must be mounted, and all passive database copies must meet the previously described conditions.

Проверка очистки репликацииCheck Replication Flush

Data Guarantee API также можно использовать для проверки того, что требуемое число копий базы данных преобразовали необходимые журналы транзакций.The Data Guarantee API can also be used to validate that a prerequisite number of database copies have replayed the required transaction logs. Это делается за счет сравнения метки времени последнего преобразованного журнала с меткой времени вызывающей службы (в большинстве случаев это метка времени последнего файла журнала, который содержит необходимые данные), плюс дополнительные пять секунд (для учета рассогласования системного времени).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
Группа DAG на одном сайте Active DirectoryA DAG within a single Active Directory site SecondCopy
Группа DAG в нескольких центрах обработки данных с использованием растянутого сайта Active DirectoryA DAG in multiple datacenters using a stretched Active Directory site SecondCopy
Группа DAG, в которую входят два сайта Active Directory, на каждом сайте будут копии базы данных с высокой доступностьюA DAG that spans twoActive Directory sites, and you will have highly available database copies in each site SecondDatacenter
Группа DAG, в которую входят два сайта Active Directory, на втором сайте будут только изолированные копии базы данныхA DAG that spans two Active Directory sites, and you will have only lagged database copies in the second site SecondCopy
Это связано с тем, что Data Guarantee 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.
Группа DAG, в которую входят три или больше сайтов Active Directory, при этом каждый сайт будет содержать копии базы данных с высокой доступностьюA DAG that spans three or more Active Directory sites, and each site will contain highly available database copies AllDatacenters

Балансировка копий баз данныхBalancing database copies

Следствием самой структуры групп обеспечения доступности баз данных (DAG) и результатом переключений базы данных и отработок отказа в них является то, что для активных копий базы данных почтовых ящиков узлы размещения будут меняться несколько раз в течение времени жизни группы DAG. В итоге, группы DAG становятся несбалансированными с точки зрения распределения активных копий базы данных почтовых ящиков. В следующей таблице приводится пример группы DAG, в которой имеются четыре базы данных с четырьмя копиями каждой из них (всего 16 баз данных на каждом сервере) с неравномерным распределением активных копий баз данных.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.

Группа DAG с несбалансированным распределением активных копийDAG with unbalanced active copy distribution

СерверServer Количество активных баз данныхNumber of active databases Количество пассивных баз данныхNumber of passive databases Количество подключенных баз данныхNumber of mounted databases Количество отключенных баз данныхNumber of dismounted databases Список для подсчета приоритетовPreference count list
EX1EX1 17:005 -11:0011 17:005 нуль0 4, 4, 3, 54, 4, 3, 5
EX2EX2 1,11 означает15 1,11 нуль0 1, 8, 6, 11, 8, 6, 1
EX3EX3 1212 SP44 1212 нуль0 13, 2, 1, 013, 2, 1, 0
EX4EX4 1,11 означает15 1,11 нуль0 1, 1, 5, 91, 1, 5, 9

В предыдущем примере для каждой базы данных существует четыре копии, и поэтому возможно только четыре значения для приоритета активации (1, 2, 3 или 4). В столбце Список для подсчета приоритетов приводится подсчет числа баз данных с каждым из этих значений. Например, на сервере EX3 имеется 13 копий баз данных с приоритетом активации 1, две копии с приоритетом 2, одна копия с приоритетом 3 и ни одной копии с приоритетом 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.

Как можно видеть, эта группа обеспечения доступности баз данных не сбалансирована с точки зрения количества активных баз данных или количества пассивных баз данных, размещаемых каждым членом такой группы, либо подсчета приоритетов активации для размещенных баз данных.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. При необходимости также выполняется попытка балансировки активных баз данных по сайтам.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.

Группа DAG со сбалансированным распределением активных копийDAG with balanced active copy distribution

СерверServer Количество активных баз данныхNumber of active databases Количество пассивных баз данныхNumber of passive databases Количество подключенных баз данныхNumber of mounted databases Количество отключенных баз данныхNumber of dismounted databases Список для подсчета приоритетовPreference count list
EX1EX1 SP44 1212 SP44 нуль0 4, 4, 4, 44, 4, 4, 4
EX2EX2 SP44 1212 SP44 нуль0 4, 4, 4, 44, 4, 4, 4
EX3EX3 SP44 1212 SP44 нуль0 4, 4, 4, 44, 4, 4, 4
EX4EX4 SP44 1212 SP44 нуль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.ps1RedistributeActiveDatabases.ps1 script parameters

ParameterParameter ОписаниеDescription
ДагнамеDagName Указывает имя группы 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.
ШовфиналдатабаседистрибутионShowFinalDatabaseDistribution Указывает, что отчет по распределению текущей базы данных должен отображаться после перераспределения.Specifies that a report of current database distribution be displayed after redistribution is complete.
АлловеддевиатионфроммеанперцентажеAllowedDeviationFromMeanPercentage Указывает допустимую вариацию активных баз данных по сайтам, выраженную в процентах. Значение по умолчанию — 20 %. Например, если между тремя сайтами было распределено 99 баз данных, то идеальным распределением будет по 33 базы данных на каждом сайте. Если допустимое отклонение составляет 20 %, то при выполнении сценария будет производиться попытка сбалансировать базы данных таким образом, чтобы количество баз данных на каждом сайте отклонялось не более чем на 10 % в ту или другую сторону от этого значения. 10 % от 33 составляют 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.
ШовдатабасекуррентактивесShowDatabaseCurrentActives Указывает, что в сценарии необходимо создать отчет для каждой базы данных с подробными сведениями о том, как перемещалась база данных и является ли она теперь активной в своей наиболее предпочтительной копии.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.
ШовдатабаседистрибутионбисерверShowDatabaseDistributionByServer Указывает, что в сценарии необходимо создать отчет для каждого сервера со сведениями о распределении базы данных на нем.Specifies that the script produce a report for each server showing its database distribution.
РунонлйонпамRunOnlyOnPAM Указывает, что сценарий должен выполняться только для того члена группы 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.
ЛожевентсLogEvents Указывает, что в процессе выполнения сценария необходимо внести в журнал событие 4115 (MsExchangeRepl) со сводкой по действиям.Specifies that the script logs an event (MsExchangeRepl event 4115) containing a summary of the actions.
ИнклуденонрепликатеддатабасесIncludeNonReplicatedDatabases Указывает, что в сценарий во время определения способа перераспределения активных баз данных необходимо включить нереплицированные базы данных (базы данных без копий). Несмотря на то что нереплицированные базы данных перемещать невозможно, они могут влиять на распределение реплицированных баз данных.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.ps1RedistributeActiveDatabases.ps1 examples

В этом примере показано распределение текущей базы данных для группы DAG, в том числе список для подсчета приоритетов.This example shows the current database distribution for a DAG, including preference count list.

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

Этот пример выполняет повторное распределение и балансировку активных копий базы данных почтовых ящиков в группе доступности с использованием предпочтений активации без запроса на ввода данных.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

Сведения о копии базы данных, в том числе длину очереди копирования, длину очереди воспроизведения, статус и информацию о состоянии индекса контента, можно просмотреть в Центре администрирования Exchange. Информацию о состоянии копии базы данных также можно просмотреть с помощью командлета Get-MailboxDatabaseCopyStatus в командной консоли Exchange.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 Exchange Management Shell to view a variety of status information for a database copy.

Примечание

Копия базы данных является первой защитой при сбое, влияющем на активную копию базы данных. Поэтому важно отслеживать работоспособность и состояние копий базы данных, чтобы они были доступны при необходимости.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 are available when needed.

Дополнительные сведения о мониторинге копий баз данных можно найти в статье мониторинг групп обеспечения доступности баз данных.For more information about monitoring database copies, see Monitor database availability groups.

Удаление копии базы данныхRemoving a database copy

Копию базы данных можно удалить в любой момент с помощью Центра администрирования Exchange или командлета Remove-MailboxDatabaseCopy в командной консоли Exchange. После удаления копии базы данных необходимо вручную удалить все файлы журнала базы данных и транзакций на сервере, с которого удалена база данных. Подробные инструкции см. в статье Удаление копии базы данных почтовых ящиков.A database copy can be removed at any time by using the EAC or by using the Remove-MailboxDatabaseCopy cmdlet in the Exchange Management 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.

Чтобы быстро определить, какой сервер является главным для базы данных почтовых ящиков, просмотрите правый столбец на вкладке Копии базы данных в Центре администрирования Exchange. Переключение можно выполнить с помощью ссылки Активировать в Центре администрирования Exchange или с помощью командлета Move-ActiveMailboxDatabase в командной консоли Exchange.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 Exchange Management Shell.

Перед активацией пассивной копии будет выполнено несколько внутренних проверок. В некоторых случаях переключение базы данных блокируется или отменяется. В других случаях с помощью командлетов можно переместить или пропустить некоторые проверки.There are several internal checks that will be performed before a passive copy is activated. In some cases, the database switchover is blocked or canceled. In other cases, you can use cmdlets to move or skip over some checks.

  • Проверяется состояние копии базы данных.The status of the database copy is checked. Если копия базы данных повреждена, переключение будет заблокировано.If the database copy is in a failed state, the switchover is blocked. Вы можете переопределить это поведение и обойти проверку работоспособности с помощью параметра скифеалсчеккс командлета Move – ActiveMailboxDatabase .You can override this behavior and bypass the health check by using the SkipHealthChecks parameter of the Move-ActiveMailboxDatabase cmdlet. Этот параметр позволяет переместить активную копию в поврежденную копию базы данных.This parameter lets you 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. Это поведение можно переопределить и обойти проверку источника заполнения с помощью параметра скипактивекопичеккс командлета Move – ActiveMailboxDatabase .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. Вы можете переопределить это поведение и обойти эти проверки с помощью параметра SkipLagChecks командлета Move – ActiveMailboxDatabase .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. Вы можете переопределить это поведение и обойти проверку каталога поиска с помощью параметра SkipClientExperienceChecks командлета Move – ActiveMailboxDatabase .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 you perform 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.When you perform 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. Использование параметра MountDialOverride равно командлета Move – ActiveMailboxDatabase предписывает целевому серверу переопределять собственные параметры подключения и использовать их, указанные параметром 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.