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

ОБЛАСТЬ ПРИМЕНЕНИЯ:2016 2019 Subscription Edition

В Exchange Server можно использовать консоль управления Exchange (EAC) или командную консоль Exchange, чтобы добавить копии базы данных почтовых ящиков после создания, настройки и заполнения группы доступности базы данных (DAG) членами сервера почтовых ящиков.

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

После создания нескольких копий базы данных можно использовать EAC или командную консоль Exchange для выполнения следующих задач:

• Отслеживайте работоспособность и состояние каждой копии.
• Выполнение других задач управления, связанных с копиями баз данных. Например:
  • Приостановка или возобновление копирования базы данных.
  • Заполняет копию базы данных.
  • Мониторинг копий базы данных.
  • Настройка параметров копирования базы данных
  • Удалите копию базы данных.

Приостановка и возобновление работы копий базы данных

По ряду причин, таких как плановое обслуживание, может потребоваться приостановить и возобновить непрерывную репликацию для копии базы данных. Кроме того, для некоторых административных задач, таких как ввод, необходимо сначала приостановить копию базы данных. Рекомендуется приостановить все действия репликации при изменении пути к базе данных или ее файлам журнала. Действие копирования базы данных можно приостановить и возобновить с помощью EAC или командлетов Suspend-MailboxDatabaseCopy и Resume-MailboxDatabaseCopy в командной консоли Exchange. Подробные инструкции по приостановке или возобновлению непрерывной репликации для копии базы данных см. в статье Приостановка или возобновление копирования базы данных почтового ящика.

Заполнение копии базы данных

Заполнение, также называемое обновлением, — это когда пустая база данных или копия рабочей базы данных добавляется в целевое расположение копии на другом сервере почтовых ящиков в том же daG, что и активная база данных. Эта база данных становится базовой базой данных для копии, поддерживаемой этим сервером.

В зависимости от ситуации заполнение может выполняться автоматически или вручную. При добавлении копии базы данных она автоматически заполняется, если целевой сервер и его хранилище настроены правильно. Чтобы вручную засеять копию базы данных и не выполнять автоматическое заполнение при создании копии, можно использовать параметр SeedingPostponed в командлете Add-MailboxDatabaseCopy .

Иногда необходимо повторно заполнить копии базы данных после первоначального заполнения. Тем не менее, если требуется повторное выполнение или вручную заполнить копию базы данных вместо автоматического заполнения копии системой, у вас есть два варианта:

• Используйте мастер обновления копии базы данных почтовых ящиков в Центре администрирования Exchange.
• Используйте командлет Update-MailboxDatabaseCopy в командной консоли Exchange.

Подробное описание действий по заполнению копии базы данных см. в разделе Обновление копии базы данных почтовых ящиков.

После завершения операции начального значения вручную репликация для заполненной копии базы данных почтового ящика автоматически возобновляется. Если вы не хотите автоматически возобновлять репликацию, можно использовать параметр ManualResume в командлете Update-MailboxDatabaseCopy .

Выбор объекта заполнения

При выполнении начальной операции можно выбрать следующее:

• Заполните копию базы данных почтового ящика.
• Заполните каталог индексов содержимого для копии базы данных почтового ящика.
• Начальное значение как копии базы данных, так и копии каталога индекса контента.

По умолчанию мастер обновления копии базы данных почтовых ящиков и командлет Update-MailboxDatabaseCopy заполняют копию базы данных почтовых ящиков и копию каталога индексов содержимого.

Чтобы заполнить только копию базы данных почтового ящика без заполнения каталога индексов контента, используйте параметр DatabaseOnly в командлете Update-MailboxDatabaseCopy .

Чтобы заполнить только копию каталога индекса контента, используйте параметр CatalogOnly в командлете Update-MailboxDatabaseCopy .

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

Вы можете использовать любую работоспособную копию базы данных в качестве источника заполнения для другой копии этой базы данных. Этот параметр особенно полезен, если у вас есть daG, расширенная в нескольких физических расположениях.

Например, рассмотрим следующее развертывание группы daG с четырьмя членами:

• MBX1 и MBX2 расположены в Портленде, штат Орегон.
• MBX3 и MBX4 находятся в Нью-Йорке.
• База данных почтовых ящиков с именем DB1 активна в MBX1.
• Существуют пассивные копии DB1 в MBX2 и MBX3.

При добавлении копии DB1 в MBX4 можно использовать копию на MBX3 в качестве источника для заполнения. Этот параметр позволяет избежать засеяния по каналу глобальной сети (WAN) между Портлендом и Нью-йорком.

Чтобы использовать определенную копию в качестве источника для заполнения при добавлении новой копии базы данных, можно выполнить следующие действия:

• Используйте параметр SeedingPostponed в командлете Add-MailboxDatabaseCopy , чтобы добавить копию базы данных. В противном случае копия базы данных явно заполняется с использованием активной копии базы данных в качестве источника.

• Вы можете указать исходный сервер для использования в мастере копирования базы данных почтовых ящиков в Центре администрирования Exchange или использовать параметр SourceServer в командлете Update-MailboxDatabaseCopy , чтобы указать нужный исходный сервер для заполнения.

  В предыдущем примере в качестве исходного сервера необходимо указать MBX3. В противном случае копия базы данных явно заполняется из активной копии базы данных.

Заполнение и сети

Помимо выбора конкретного исходного сервера для заполнения копии базы данных почтовых ящиков, можно также использовать командную консоль Exchange, чтобы указать, какие сети DAG следует использовать. Вы можете переопределить параметры сжатия и шифрования сети DAG во время начальной операции.

Вы можете указать сети, которые будут использоваться для заполнения, с помощью параметра Network в командлете Update-MailboxDatabaseCopy и указать сети DAG, которые вы хотите использовать. Если параметр Network не используется, система использует следующее поведение по умолчанию для выбора сети, используемой для операции заполнения:

• Если исходный и целевой сервер находятся в одной подсети и настроена сеть репликации, включающая подсеть, используется сеть репликации.

• Если исходный и целевой сервер находятся в разных подсетях, даже если настроена сеть репликации, содержащая эти подсети, для заполнения используется клиентская сеть (MAPI).

• Если исходный и целевой сервер находятся в разных центрах обработки данных, для заполнения используется клиентская сеть (MAPI).

Шифрование и сжатие данных настраивается на уровне группы DAG. По умолчанию шифрование и сжатие используются только для обмена данными в разных подсетях. Если источник и целевой объект находятся в разных подсетях и daG настроено со значениями по умолчанию для NetworkCompression и NetworkEncryption, эти значения можно переопределить с помощью параметров NetworkCompressionOverride и NetworkEncryptionOverride в командлетеUpdate-MailboxDatabaseCopy .

Процесс заполнения

При запуске процесса заполнения с помощью командлета Add-MailboxDatabaseCopy или Update-MailboxDatabaseCopy выполняются следующие задачи:

1. Свойства базы данных из Active Directory считываются для проверки указанной базы данных и серверов, а также для проверки того, что исходный и целевой серверы работают Exchange Server, они оба являются членами одного daG и что указанная база данных не является базой данных восстановления. Также считываются пути к файлам базы данных.

2. Приготовления выполняются для проверки повторного заполнения из службы репликации Microsoft Exchange целевого сервера.

3. Служба репликации Microsoft Exchange на целевом сервере проверяет наличие базы данных и файлов журнала транзакций в каталогах файлов, считанных при проверке Active Directory на шаге 1.

4. Служба репликации Microsoft Exchange возвращает сведения о состоянии из целевого сервера в интерфейс администратора, в котором запущен командлет.

5. Если все предварительные проверки пройдены, вам будет предложено подтвердить операцию, прежде чем продолжить. При подтверждении операции процесс продолжится. Если при предварительных проверках произошла ошибка, будет создан отчет об этой ошибке и произойдет сбой операции.

6. Операция заполнения начнется из службы репликации Microsoft Exchange целевого сервера.

7. Служба репликации Microsoft Exchange приостановит репликацию базы данных для активной копии базы данных.

8. Служба репликации Microsoft Exchange обновляет сведения о состоянии базы данных, чтобы отразить состояние начального заполнения.

9. Если на целевом сервере еще нет каталогов для целевой базы данных и файлов журналов, они создаются.

10. TCP-запрос для заполнения базы данных передается из службы репликации Microsoft Exchange на целевом сервере в службу репликации Microsoft Exchange на исходном сервере. Этот запрос и последующие связи для заполнения базы данных выполняются в сети DAG, настроенной как сеть репликации.

11. Служба репликации Microsoft Exchange на исходном сервере запускает потоковую архивацию расширенного обработчика хранилищ (ESE) с помощью интерфейса службы банка данных Microsoft Exchange.

12. Служба банка данных Microsoft Exchange передает сведения базы данных в службу репликации Microsoft Exchange.

13. Сведения базы данных перемещаются из службы репликации Microsoft Exchange исходного сервера в службу репликации Microsoft Exchange целевого сервера.

14. Служба репликации Microsoft Exchange на целевом сервере записывает копию базы данных во временный каталог, расположенный в главном каталоге базы данных.

15. Операция потоковой архивации на исходном сервере заканчивается, когда достигается конец базы данных.

16. Операция записи завершается на целевом сервере, и база данных перемещается из каталога "temp-seeding" в конечное расположение. Каталог "temp-seeding" удаляется.

17. Служба репликации Microsoft Exchange на целевом сервере предоставляет запрос службе поиска Microsoft Exchange на подключение каталога индексов содержимого к копии базы данных, если она существует. Если существуют файлы каталога предыдущей копии базы данных с истекшим сроком действия, происходит сбой операции подключения, что приводит к необходимости репликации каталога с исходного сервера. Подобным образом, если каталог отсутствует в новом экземпляре копии базы данных на целевом сервере, требуется создать копию каталога. Служба репликации Microsoft Exchange указывает службе поиска Microsoft Exchange приостановить индексирование копии базы данных, пока новый каталог копируется из источника.

18. Служба репликации Microsoft Exchange на целевом сервере отправляет запрос на заполнение каталога службе репликации Microsoft Exchange на исходном сервере.

19. На исходном сервере служба репликации Microsoft Exchange запрашивает сведения о каталоге из служба Microsoft Exchange и запрашивает приостановку индексирования.

20. Служба поиска Microsoft Exchange на исходном сервере возвращает сведения о каталоге из каталога поиска службе репликации Microsoft Exchange.

21. Служба репликации Microsoft Exchange на исходном сервере считывает файлы каталога из каталога.

22. Служба репликации Microsoft Exchange на исходном сервере перемещает данные каталога в службу репликации Microsoft Exchange на целевом сервере с помощью подключения в сети репликации. После считывания служба репликации Microsoft Exchange отправляет запрос на возобновление индексации исходной базы данных службе поиска Microsoft Exchange.

23. Если в папке на целевом сервере существуют файлы каталога, служба репликации Microsoft Exchange на целевом сервере удалит их.

24. Служба репликации Microsoft Exchange на целевом сервере записывает данные каталога во временный каталог CiSeed.Temp до полной передачи данных.

25. Служба репликации Microsoft Exchange перемещает все данные каталога в конечное местоположение.

26. Служба репликации Microsoft Exchange на целевом сервере возобновляет индексацию поиска в целевой базе данных.

27. Служба репликации Microsoft Exchange на целевом сервере возвращает уведомление о состоянии завершения.

28. Конечный результат операции проходит в интерфейс администратора, в котором был запущен командлет.

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

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

Использование параметров задержки преобразования и задержки усечения

Копии базы данных почтовых ящиков поддерживают использование параметров время задержки преобразования и время задержки усечения, которые указываются в минутах. Установка времени задержки преобразования позволяет выполнить откат копии базы данных к определенной точке во времени. Установка времени задержки усечения позволяет использовать журналы в пассивной копии базы данных для восстановления утерянных файлов журнала активной копии базы данных. Так как обе эти функции приводят к временному сборке файлов журнала, использование любой из них влияет на структуру хранилища.

Время задержки преобразования

Интервал задержки воспроизведения — свойство копии базы данных почтовых ящиков, которое определяет интервал задержки воспроизведения журнала для копии базы данных (в минутах). Таймер задержки воспроизведения запускается, когда файл журнала реплицируется в пассивную копию и успешно проходит проверку. Задержка воспроизведения журналов в копию базы данных позволяет восстановить состояние базы данных в определенной точке времени в прошлом. Копия базы данных почтового ящика, настроенная с задержкой воспроизведения, больше нуля, называется копией базы данных почтового ящика с отставанием или просто отставанием.

Стратегия, использующая копии баз данных и функции удержания для судебного разбирательства в Exchange Server, может обеспечить защиту от ряда сбоев, которые обычно приводят к потере данных. Однако эти функции не могут обеспечить защиту от потери данных из-за логического повреждения. Хотя логическое повреждение встречается редко, это может привести к потере данных. Отложенные копии предназначены для предотвращения потери данных из-за логического повреждения. Как правило, существует два типа логического повреждения

• Логическое повреждение базы данных. Контрольная сумма страниц базы данных совпадает, но данные на страницах логически неверны. Эта ситуация возникает, когда ESE пытается записать страницу базы данных. Хотя операционная система возвращает сообщение об успешном выполнении, данные либо никогда не записываются на диск, либо записываются в неправильное место. Это условие называется потерянным потоком. Чтобы предотвратить потерю данных в результате утерянной очистки, расширенный обработчик хранилищ (ESE) добавляет в базу данных механизм определения утерянной очистки и функцию исправления страницы (восстановления одной страницы).

• Логическое повреждение хранилища. Данные добавляются, удаляются или обрабатываются таким образом, что пользователь не ожидает. Такие случаи обычно вызывают приложения, не относящиеся к Корпорации Майкрософт. Обычно это считается повреждением в том смысле, что пользователь рассматривает его как повреждение. Хранилище Exchange считает транзакцию, которая привела к логическому повреждению серией правильных операций MAPI. Функция удержания для судебного разбирательства в Exchange Server обеспечивает защиту от логического повреждения хранилища (так как она предотвращает окончательное удаление содержимого пользователем или приложением). Однако могут возникнуть ситуации, когда почтовый ящик пользователя настолько поврежден, что будет проще восстановить базу данных до точки во времени до повреждения, а затем экспортировать почтовый ящик пользователя для получения неподтвержденных данных.

Комбинация копий базы данных, политики удержания и восстановления одиночной страницы с помощью расширенного обработчика хранилищ предотвращает редкие катастрофические случаи логического повреждения хранилища. Ваше решение о том, следует ли использовать копию базы данных с задержкой воспроизведения (отстающей копией), зависит от того, какие приложения сторонних поставщиков вы используете, и от журнала вашей организации с логическим повреждением хранилища.

При использовании изолированных копий необходимо учитывать следующие последствия.

• Время задержки воспроизведения — это значение, настроенное администратором. По умолчанию время задержки воспроизведения отключено.

• Параметр времени задержки воспроизведения имеет значение по умолчанию равным нулю дням, а максимальный — 14 дней.

• Изолированные копии не считаются высокодоступными. Вместо этого они предназначены для аварийного восстановления для защиты от логического повреждения хранилища.

• Чем больше время задержки преобразования, тем дольше длится процесс восстановления базы данных. Восстановление базы данных может занять несколько часов из-за:

  • Количество воспроизводимых файлов журнала.
  • Скорость, с которой оборудование может воспроизводить их.

• Рекомендуется определить, критично ли использование изолированных копий для общей стратегии аварийного восстановления. Если их использование является критичным, рекомендуется использовать несколько изолированных копий или использовать резервный массив независимых дисков (RAID) для защиты отдельной изолированной копии при отсутствии нескольких изолированных копий. При потере или повреждении диска отложенная во времени точка не будет потеряна.

• Отложенные копии не могут быть исправлены с помощью функции одностраничного восстановления ESE. Если при отложенной копии происходит повреждение страницы базы данных (например, ошибка -1018), копия должна быть повторно добавлена. При повторном просмотре теряется отстающий аспект копии.

Если вы хотите, чтобы база данных воспроизводила все файлы журналов и копировать базу данных в актуальном состоянии, активация и восстановление копии базы данных с отставанием является простым процессом. Если вы хотите воспроизвести файлы журнала до определенного момента времени, процесс будет сложнее, так как вам нужно вручную управлять файлами журналов и запускать Exchange Server служебных программ баз данных (Eseutil.exe).

Подробные инструкции по активации копии базы данных отложенного почтового ящика см. в разделе Активация копии базы данных с отложенным почтовым ящиком.

Время задержки усечения

Время задержки усечения — это свойство копии базы данных почтового ящика, указывающее время в минутах для задержки удаления журнала для копии базы данных после воспроизведения файла журнала в копии базы данных. Отсчет времени задержки усечения начинается после репликации файла журнала в пассивную копию, успешного прохождения проверки и воспроизведения в копию базы данных. Задержка усечения файлов журнала из копии базы данных позволяет выполнять восстановление после сбоев, влияющих на файлы журнала активной копии базы данных.

Копии базы данных и усечение журнала

Усечение журнала работает так же в Exchange 2016 и Exchange 2019, как и в Exchange 2010. Поведение усечения зависит от параметров времени задержки преобразования и времени задержки усечения копии.

Файл журнала копии базы данных должен соответствовать следующим критериям, если для параметров задержки установлено значение по умолчанию 0 (отключено).

• Резервное копирование файла журнала успешно создается или циклическое ведение журнала включено.
• Файл журнала должен находиться под контрольной точкой (минимальный файл журнала, необходимый для восстановления) для базы данных.
• Все остальные отложенные копии проверяли файл журнала.
• Все остальные копии (за исключением отложенных копий) воспроизводили файл журнала.

Для выполнения усечения необходимо соответствие копии базы данных следующим критериям.

• Файл журнала должен быть ниже контрольной точки для базы данных.
• Время, прошедшее с момента создания файла журнала, должно превышать значение ReplayLagTime + TruncationLagTime.
• Файл журнала усечен в активной копии.

В Exchange Server усечение журнала не выполняется в активной копии базы данных почтового ящика при приостановке одной или нескольких пассивных копий. Если запланированные действия по обслуживанию занимают длительный период времени (например, несколько дней), может потребоваться значительное создание файла журнала. Чтобы предотвратить заполнение диска журналами транзакций, можно удалить пассивную копию базы данных, а не приостанавливать ее. После планового обслуживания можно повторно добавить эту пассивную копию базы данных.

Exchange Server теперь имеет функцию свободного усечения, которая отключена по умолчанию. Во время обычных операций каждая копия базы данных хранит журналы, которые должны быть отправлены в другие копии базы данных, пока все копии базы данных не подтвердят:

• Они воспроизводили файлы журнала (пассивные копии).
• Они получили файлы журнала (отставшие копии).

Это поведение является усечением журнала по умолчанию. Если по какой-либо причине копия базы данных переходит в автономный режим, файлы журнала начинают накапливаться на дисках, используемых другими копиями базы данных. Если затронутая копия базы данных остается в автономном режиме в течение длительного периода времени, это может привести к тому, что в других копиях базы данных не будет свободного места на диске.

Поведение усечения отличается, если включены свободное усечение и циклическое ведение журнала. Каждая копия базы данных отслеживает собственное свободное место на диске и применяет свободное усечение, если свободное место заканчивается.

• Активная копия: самая старая пассивная копия базы данных (по дате воспроизведения журналов) игнорируется, усечение начинается со следующей самой старой пассивной копии. Глобальное усечение рассчитывается в активной копии базы данных.

• Для пассивной копии, если пространство становится низким, она независимо усекает файлы журнала с помощью настроенных параметров, описанных далее в таблице Значения реестра. Пассивные копии пытаются выполнить решение об усечении, принятое для активной копии. Несмотря на значение имени MinCopiesToProtect, Exchange игнорирует только самый старый известный отставание на момент выполнения усечения.

Когда автономная база данных возвращается в режим "в сети", ее отсутствующие файлы журнала удаляются из других работоспособных копий, а ее состояние копии базы данных — FailedAndSuspended. В этом случае, если настроено автоматическое использование, затронутые копии автоматически повторно добавляются. Если автоматическое использование не настроено, администратор должен вручную заполнить копию базы данных.

Если циклическое ведение журнала отключено, при свободном усечении учитываются все сделанные резервные копии. При свободном усечении не удаляются файлы журналов, для которых не создана резервная копия.

Усечение — это рекомендуемая функция для предпочтительной архитектуры, в которой резервные копии не используются и включено циклическое ведение журнала.

Необходимое количество работоспособных копий, пороговое значение свободного места на диске и количество журналов для хранения — это настраиваемые параметры. По умолчанию порог свободного места на диске составляет 204800 МБ (200 ГБ), а количество журналов для хранения — 100 000 (100 ГБ) для пассивных копий и 10 000 (10 ГБ) для активных копий.

Включение свободного усечения и настройка параметров свободного усечения выполняется путем изменения реестра Windows в каждом элементе DAG. Можно настроить три значения реестра, которые хранятся в HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. Ключ BackupInformation: следующие значения DWORD не существуют по умолчанию и должны быть созданы вручную. Значения реестра DWORD в разделе BackupInformation описаны в следующей таблице:

При использовании значения реестра LooseTruncation_MinLogsToProtect поведение активных и пассивных копий базы данных отличается.

• Активный. Количество дополнительных журналов, хохраняемых перед этими журналами, необходимое для защищенных пассивных копий, и требуемый диапазон активной копии.
• Пассивный. Количество журналов, храняемых из последнего доступного журнала. Одна десятая часть этого числа также используется для ведения журналов до требуемого диапазона этой пассивной копии.

Эти два ограничения применяются для обеспечения того, чтобы отстающие копии базы данных не занимают слишком много места, так как требуемый диапазон обычно очень велик.

Политика активации базы данных

Существуют сценарии, в которых может потребоваться создать копию базы данных почтового ящика и запретить системе автоматически активировать эту копию. Например, после сбоя:

• Разверните одну или несколько копий базы данных почтовых ящиков в альтернативный или резервный центр обработки данных.
• Вы настраиваете отстающий экземпляр базы данных для восстановления.
• Выполняется обслуживание или обновление сервера.

В каждом из указанных выше сценариев копии базы данных не должны автоматически активироваться системой. Чтобы предотвратить автоматическую активацию копии базы данных почтовых ящиков, можно настроить блокирование (приостановку) активации копии.

Эта конфигурация позволяет системе поддерживать валюту базы данных путем доставки и воспроизведения журналов, но не позволяет системе автоматически активировать и использовать копию. Администратор должен вручную активировать копии, заблокированные для активации.

Для параметра DatabaseCopyAutoActivationPolicy можно задать значение Заблокировано для:

• Весь сервер с помощью командлета Set-MailboxServer .
• Отдельная копия базы данных с помощью командлета Set-MailboxDatabaseCopy .

Дополнительные сведения о настройке политики активации базы данных см. в разделе Настройка политики активации для копии базы данных почтовых ящиков.

Влияние перемещения почтовых ящиков на непрерывную репликацию

В интенсивно используемой базе данных почтовых ящиков с высокой скоростью создания журналов вероятность потери данных выше, если репликация в пассивные копии базы данных не успевает за созданием журналов. Скорость создания журналов возрастает при перемещении почтовых ящиков. Exchange Server включает API гарантии данных, который используется такими службами, как служба репликации почтовых ящиков Exchange (MRS), для проверка работоспособности архитектуры копирования базы данных на основе значения параметра DataMoveReplicationConstraint, заданного системой или администратором. В частности, API Data Guarantee может использоваться для:

• Проверка работоспособности репликации. Подтверждает наличие необходимого количества копий базы данных.

• Проверка сброса репликации. Подтверждает, что необходимые файлы журнала воспроизводится в соответствии с предварительным числом копий базы данных.

При выполнении API-интерфейса он возвращает следующие сведения о состоянии вызывающему приложению:

• Повторная попытка. Указывает на наличие временных ошибок, которые препятствуют проверке условия в базе данных.

• Удовлетворено. Означает, что база данных соответствует требуемым условиям или база данных не реплицируется.

• NotSatisfied: означает, что база данных не соответствует требуемым условиям. Кроме того, вызывающему приложению предоставляется информация о причине возврата состояния NotSatisfied.

Значение параметра DataMoveReplicationConstraint для базы данных почтового ящика определяет, сколько копий базы данных следует оценить в рамках запроса. Параметр DataMoveReplicationConstraint имеет следующие возможные значения:

• None: при создании базы данных почтовых ящиков это значение задается по умолчанию. Если задано это значение, условия интерфейса Data Guarantee API игнорируются. Этот параметр следует использовать только для баз данных почтовых ящиков, которые не реплицируются.

• SecondCopy: это значение по умолчанию при добавлении второй копии базы данных почтовых ящиков. Если задано это значение, по крайней мере одна пассивная копия базы данных должна соответствовать условиям Data Guarantee API.

• SecondDatacenter: если задано это значение, по крайней мере одна пассивная копия базы данных на другом сайте Active Directory должна соответствовать условиям API гарантии данных.

• AllDatacenters: если задано это значение, по крайней мере одна пассивная копия базы данных на каждом сайте Active Directory должна соответствовать условиям API гарантии данных.

• AllCopies: если задано это значение, все копии базы данных почтовых ящиков должны соответствовать условиям API гарантии данных.

Проверка работоспособности репликации

При выполнении Data Guarantee API для оценки работоспособности инфраструктуры копий баз данных, оцениваются несколько элементов.

Во всех сценариях пассивная копия базы данных должна соответствовать следующим условиям:

• быть работоспособной;

• содержать очередь преобразования в течение 10 минут времени задержки преобразования;

• использовать очередь копирования длиной не менее 10 журналов;

• использовать среднюю очередь копирования длиной не менее 10 журналов. Средняя длина очереди копирования вычисляется на основе количества запросов приложения к состоянию базы данных.

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

Data Guarantee API также можно использовать для проверки того, что требуемое число копий базы данных преобразовали необходимые журналы транзакций. Это проверяется путем сравнения метки времени последнего воспроизведения журнала с меткой времени фиксации вызывающей службы (в большинстве случаев это метка времени последнего файла журнала, содержащего необходимые данные) и дополнительных пяти секунд (для решения проблем с отклонением или смещением системных часов времени). Если метка времени воспроизведения больше метки времени фиксации, параметр DataMoveReplicationConstraint удовлетворяется. Если метка времени воспроизведения меньше метки времени фиксации, dataMoveReplicationConstraint не удовлетворяется.

Перед перемещением большого количества почтовых ящиков в базы данных репликации или из них в DAG рекомендуется настроить параметр DataMoveReplicationConstraint для каждой базы данных почтовых ящиков в соответствии со следующей таблицей:

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

Из-за присущей daG природы, в результате переключения баз данных и отработки отказа база данных активного почтового ящика копирует узлы изменений несколько раз на протяжении всего времени существования DAG. В итоге, группы DAG становятся несбалансированными с точки зрения распределения активных копий базы данных почтовых ящиков. В следующей таблице приводится пример группы DAG, в которой имеются четыре базы данных с четырьмя копиями каждой из них (всего 16 баз данных на каждом сервере) с неравномерным распределением активных копий баз данных.

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

Как можно видеть, эта группа обеспечения доступности баз данных не сбалансирована с точки зрения количества активных баз данных или количества пассивных баз данных, размещаемых каждым членом такой группы, либо подсчета приоритетов активации для размещенных баз данных.

Вы можете использовать скрипт RedistributeActiveDatabases.ps1 для балансировки копий баз данных почтовых ящиков в группе обеспечения доступности баз данных. В этом сценарии базы данных перемещаются между своими копиями с целью попытки получения равных количеств подключенных баз данных на каждом сервере в группе DAG. При необходимости также выполняется попытка балансировки активных баз данных по сайтам.

В этом сценарии имеется два параметра для балансировки активных копий баз данных в группе DAG.

• BalanceDbsByActivationPreference: если указан этот параметр, скрипт пытается переместить базы данных в наиболее предпочтительную копию (на основе предпочтений активации) без учета сайта Active Directory.

• BalanceDbsBySiteAndActivationPreference: если указан этот параметр, скрипт пытается переместить активные базы данных в наиболее предпочтительную копию, а также пытается сбалансировать активные базы данных на каждом сайте Active Directory.

После запуска сценария с первым параметром предыдущая несбалансированная группа DAG становится сбалансированной, как показано в следующей таблице.

Как показано выше, эта группа DAG теперь сбалансирована с точки зрения количества активных и пассивных баз данных на каждом сервере и приоритетов активации по серверам.

В следующей таблице перечислены параметры скрипта RedistributeActiveDatabases.ps1.

Примеры RedistributeActiveDatabases.ps1

В этом примере показано распределение текущей базы данных для группы DAG, в том числе список для подсчета приоритетов.

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

Этот пример выполняет повторное распределение и балансировку активных копий базы данных почтовых ящиков в группе доступности с использованием предпочтений активации без запроса на ввода данных.

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

В этом примере выполняется перераспределение и балансировка активных копий базы данных почтовых ящиков в группе DAG с учетом приоритетов активации, а также формируется сводка по процессу распределения.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Копии базы данных мониторинга

Сведения о копии базы данных, в том числе длину очереди копирования, длину очереди воспроизведения, статус и информацию о состоянии индекса контента, можно просмотреть в Центре администрирования Exchange. Информацию о состоянии копии базы данных также можно просмотреть с помощью командлета Get-MailboxDatabaseCopyStatus в командной консоли Exchange.

Дополнительные сведения о мониторинге копий баз данных см. в разделе Мониторинг групп доступности баз данных.

Удаление копии базы данных

Копию базы данных можно удалить в любое время с помощью EAC или командлета Remove-MailboxDatabaseCopy в командной консоли Exchange. После удаления копии базы данных необходимо вручную удалить все файлы журнала базы данных и транзакций на сервере, с которого была удалена база данных. Подробные инструкции по удалению копии базы данных см. в разделе Удаление копии базы данных почтового ящика.

Переключения базы данных.

Сервер почтовых ящиков, на котором размещена активная копия базы данных, является хозяином базы данных почтовых ящиков. В процессе активации пассивной копии базы данных изменяется хозяин базы данных почтовых ящиков и пассивная копия преобразуется в новую активную копию. Этот процесс называется переключением базы данных. При переключении базы данных активная копия базы данных отключается на одном сервере почтовых ящиков, а пассивная копия этой базы данных подключается в качестве новой активной базы данных почтовых ящиков на другом сервере почтовых ящиков. При выполнении переключения можно также переопределить параметр подключения базы данных на новом хозяине базы данных почтовых ящиков.

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

Перед активацией пассивной копии выполняется несколько внутренних проверок. В некоторых случаях переключение базы данных блокируется или отменяется. В других случаях с помощью командлетов можно переместить или пропустить некоторые проверки.

• Проверяется состояние копии базы данных. Если копия базы данных повреждена, переключение будет заблокировано. Это поведение можно переопределить и обойти проверка работоспособности с помощью параметра SkipHealthChecks командлета Move-ActiveMailboxDatabase. Этот параметр позволяет переместить активную копию в поврежденную копию базы данных.

• Проверяется, является ли активная копия базы данных источником заполнения каких-либо пассивных копий базы данных. Если активная копия в данный момент используется как источник для заполнения, переключение блокируется. Это поведение можно переопределить и обойти исходный проверка заполнения с помощью параметра SkipActiveCopyChecks командлета Move-ActiveMailboxDatabase. Этот параметр позволяет переместить активную копию, используемую как источник заполнения. При использовании этого параметра операция заполнения будет отменена и считается неудачной.

• Выполняется проверка значений длины очереди копирования и очереди преобразования копии базы данных на нахождение в пределах заданных критериев. Также выполняется проверка того, используется ли копия базы данных в качестве источника для заполнения. Если значения длины очередей не соответствуют заданным критериям или база данных является источником заполнения, переключение будет заблокировано. Это поведение можно переопределить и обойти эти проверки с помощью параметра SkipLagChecks командлета Move-ActiveMailboxDatabase . Этот параметр позволяет активировать копии, которые имеют значения очередей преобразования и копирования за пределами настроенных критериев.

• Выполняется проверка состояния каталога поиска (индексов содержимого) для копии базы данных. Если каталог поиска устарел, неисправен или поврежден, переключение будет заблокировано. Это поведение можно переопределить и обойти проверка каталога поиска с помощью параметра SkipClientExperienceChecks командлета Move-ActiveMailboxDatabase. Этот параметр позволяет пропустить проверку работоспособности каталога поиска. Если каталог поиска для копии базы данных, которую вы активируете, находится в неработоспособном или непригодном для использования состоянии и этот параметр используется для пропуска проверка работоспособности каталога и активации копии базы данных, необходимо выполнить обход или заполнить каталог поиска еще раз.

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 .

Дополнительные сведения о переключении копии базы данных см. в разделе Активация копии базы данных почтовых ящиков.