10 марта Exchange 2010
У меня была эта проблема с клиентом на прошлой неделе, система была Exchange 2010 с настройкой группы доступности базы данных (DAG) из 2 узлов. Один из узлов Exchange перешел в автономный режим, и он будет постоянным, поскольку сбой был катастрофическим. Я проверил, что второй узел вступил в действие, но это не так. База данных почтовых ящиков не работала, и после проверки состояния репликации базы данных почтовых ящиков на второй узел очередь копирования находилась в 9223372036854775766.
Из-за этого при попытке принудительного переключения при сбое меня встретила следующая ошибка.
Операция Active Manager не удалась. Ошибка Действие базы данных не удалось. Ошибка: произошла ошибка при попытке проверить указанную копию базы данных для возможной активации. Ошибка: копия базы данных «Database1» на сервере «dagnode2.domain.com» имеет длину очереди копирования 9223372036854725486, что слишком много для автоматического восстановления. Вы можете использовать командлет Move-ActiveMailboxDatabase с параметрами -SkipLagChecks и -MountDialOverride для перемещения базы данных с потерями. Если база данных не смонтирована после успешного запуска Move-ActiveMailboxDatabase, используйте командлет Mount-Database для подключения базы данных.
Я был уверен, что никакая почта не будет потеряна, так как все мои клиенты находятся в режиме кэширования, поэтому при повторном подключении к серверу CAS они синхронизируют резервную копию почты со вторым сервером почтовых ящиков.
После запуска команды, упомянутой в сообщении об ошибке, меня снова встретили с красным предупреждением о том, что он не может запустить службу индексирования поиска Microsoft Exchange на отказавшем узле … потому что он больше не существует, отлично.
Чтобы обойти это, нам нужно добавить несколько дополнительных флагов в команду выше. Они как ниже.
- —SkipActiveCopyChecks — Параметр SkipActiveCopyChecks указывает, следует ли пропустить проверку текущей активной копии, чтобы узнать, является ли она в настоящее время источником заполнения для любых пассивных баз данных. Помните, что при использовании этого параметра вы можете переместить базу данных, которая в настоящее время является источником заполнения, что отменяет операцию заполнения.
- –SkipClientExperienceChecks — Параметр SkipClientExperienceChecks указывает, следует ли пропустить проверку состояния каталога поиска (индекса контента), чтобы убедиться в исправности и актуальности каталога поиска. Если каталог поиска для копии базы данных, которую вы активируете, находится в нездоровом или непригодном для использования состоянии, и вы используете этот параметр, чтобы пропустить проверку работоспособности каталога поиска и активировать копию базы данных, вам нужно будет либо повторно сканировать, либо заново заполнить каталог поиска. ,
Имея это в виду, мы запускаем следующие команды, чтобы вернуть наш узел к жизни, даже если база данных почтовых ящиков не синхронизирована полностью.
Move-ActiveMailboxDatabase database1 -ActivateOnServer dagnode2 -SkipHealthChecks -SkipActiveCopyChecks -SkipClientExperienceChecks -SkipLagChecks -MountDialOverride: BESTEFFORT
После запуска ваша база данных будет подключена, и клиенты смогут подключаться. Как уже упоминалось, это хорошо работает для ситуаций, когда у вас есть кластер DAG из 2 узлов с одним узлом и длина очереди копирования не допускает автоматического сбоя.
Удалить копию базы данных почтовых ящиков DAG
После того, как вы снова заработаете, вам нужно будет привести в порядок вышедший из строя узел dag. Сначала удалите копию базы данных почтовых ящиков со сбойного сервера. Сделайте это с помощью этой команды.
Remove-MailboxDatabaseCopy -Identity database1 \ dagnode1 -Confirm: $ False
Удалить узел из DAG
Мы также должны полностью удалить узел из dag с помощью следующей команды.
Remove-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer DAGNODE1 -ConfigurationOnly
Эта небольшая партия заняла у меня несколько часов, чтобы починить, так что, надеюсь, это сэкономит кому-то много времени.