Главная Exchange/UC, Без рубрики, Новое Exchange 2010 DAG: Replay Lag Time
  • Exchange 2010 DAG: Replay Lag Time

    42911223

    Про Database Availability Group написано давно и много , но все же остается ряд опций и настроек, которые находятся “за кадром” для большинства системных администраторов. При этом данные настройки играют серьезную роль  в работе DAG и учитывать их при планировании высокой доступности просто необходимо. Итак, приступим, поговорим про параметр “Replay Lag Time” и принципы его работы.

     

    Replay Lag Time

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

    Параметр "Replay Lag Time”  задается на уровне каждой копии и определяет временную задержку от момента получения и проверки транзакционного лога до момента его “накатывания” на базу. Если для реплики параметр "Replay Lag Time” отличен от нуля, то такая копия называется “lagged copy”, т.е копия с  задержкой. Получается что лог поступает на сервер с пассивной копией, но применяется только через N-временной промежуток.

    Для параметра временной задержки по умолчанию установлено значение 0 дней (т.е не включена). Максимальное значение для этого параметра 14 дней. Если не понятно зачем нужна такая “тормозная” копия, то я поясню.  Replay Lag Time защищает ваши данные от  логического повреждения базы данных. Если такой сценарий произойдет, то все копии которые актуализируются будут сразу  испорчены, но не та копия, которая  работает с задержкой.

    Lagged copy не считается высоко доступной, это связанно с тем, что автоматический переход на них невозможен . Еще раз повторюсь, они разработаны для аварийного восстановления и защиты от логического повреждения хранилища. Восстановление терабайтной базы из резервной копии  после логического повреждения это время в часах, а переход на “lagged copy” это минуты. (продолжительность зависит от установленного Replay Lag Time, чем он больше, тем продолжительней переключение) Более того всегда существуют данные, которые еще не попали в бэкап, но могут быть потеряны.

    Рекомендованная концепция такова: вы имеете три реплики, две из них актуализируются сразу по поступлению транзакционных логов, а третья с небольшой задержкой в несколько часов. Если вы теряете активную реплику (падение диска, сервера), то активируется вторая обычная реплика (которая актуализировалась сразу). А в случае логических сбоев, вы достаточно быстро руками вытащите нужные данные из третьей  “lagged copy”.

    Если реплики уже есть, то установить задержку в 10 минут можно через EMS следующей командой:

    Set-MailboxDatabaseCopy –Identity “HA Database\SRV-MIAT-EXCH1” -ReplayLagTime 0.0:10:0

    1

    Теперь будет заметно, как увеличивается количество транзакционных логов в “lagged copy”, но при этом не растет размер базы данных, точнее растет, но с задержкой. Посмотреть какая копия с какой задержкой актуализируется можно так же через powershell. В моём случае реплика находящаяся на сервере SRV-MIAT-EXCH1 идет с 10 минутной задержкой.

    Get-maiboxDatabase “HA Database” | fl Name,ReplayLagTime

    3

    Если появилась потребность воспользоваться  “lagged сору”, то для начала нужно приостановить копирование новых логов командой “Suspend-MailboxDatabaseCopy

    Suspend-MailboxDatabaseCopy -Identity “HA Database\SRV-MIAT-EXCH1” 

    2

    Далее вам нужно выбрать время  по состояние на которое вы хотите откатить базу данных. Если вы решили вернуться на 10:06, то все транзакционные логи с датой после 10:06 должны быть  перемещены или удалены. Изображение, которое находиться ниже с другой статьи, поэтому название базы не совпадает, но действие нам нем производится именно то, которое нужно – все логи, после определенного времени перемещаются из папки.

    image0141276284816376

    Далее удалите файл контрольной точки (.chk) для реплики  базы данных (“lagged copy”).  И запустите командную строку, но только обязательно от имени администратора!!!

    Зайдите в директорию с базой и запустите утилиту eseutil /r e00 /a   

    (e00 это префикс моей базы, у вас может быть другой)

    Lagged copy – перейдет в состояние чистого выключения и проиграет все транзакционные логи, которые остались в папке с базой. После чего база может быть использована для восстановления.

    Capture4

    Документация немногословна и конкретно сказано следующее “After log replay is finished, the database is in a clean shutdown state and can be copied and used for recovery purposes”. На этом моменте я долго чесал затылок пытаясь понять, как именно должно пройти восстановление.

    Решение пришло позже.  Оказывается:

    1. Теперь у вас есть база в состоянии на какую то дату. Вы эту базу, а точнее edb файл сливаете в другой каталог.

    2. Создаете на основе edb файла базу для восстановления и восстанавливаете нужные данные.

    New-MailboxDatabase –Name “Recovery Database” –Server SRV-MIAT-EXCH1 –EdbFilePath “C:\RDB\ha database.edb” –LogFolderPath C:\RDB\  -Recovery

    Mount-Database “Recovery Database”

    Get-MailboxStatistics – Database “Recovery Database”

    Restore-Mailbox –Identity “Ilya Rud” –RecoveryDatabase “Recovery Database”

    3. После чего базу для восстановления удаляете, а Lagged copy продолжаете актуализировать с поноценной реплики, продолжив репликацию.

    Resume-MailboxDatabaseCopy “HA Database\SRV-MIAT-EXCH1”

    Выводы:

    Имея только две реплики  особого смысла  делать вторую Lagged copy я не вижу. Автоматического переключения нет. Понадобится такая копия только компаниям с очень жестким SLA, в котором терять почту нельзя совсем. Имея такую реплику вы всегда сможете вытащить, то что было двадцать минут назад, но вдруг пропало и при этом не засветилось ни в одном бэкапе.

     

    MCT/MVP Илья Рудь

    P.S Спасибо Олегу Крылову за помощь при тестировании Lagged copy

Комментарии

  1. День добрый. Илья, спасибо за статью. Надеюсь она поможет админисраторам понимать работу отложенной записи.
    На последней конференции Tech Ed Russia 2011 Скотт Шноль. Прокоментировал отложенную запись, сказав что Microsoft перестали использовать данную функцию, на промышленных серверах, так как повреждение базы на уровне логического повреждения маловероятна.

  2. Значит в Exchange 201X ее наверно уберут. 🙂 А потом в Exchange 202X опять добавят 🙂 Я бы не юзал “Lagged copy”, особого смысла нет. Но знать как работает нужно, поэтому и разбирался.

  3. Есть подозрение, что Exchange 2015. По разговорам Lync планируеться на 2015.

  4. Врятли, по моим данным в этом году мы увидим новый Exchange.

  5. Много лет пытался понять, что же это за логическое повреждение базы данных. По описанию получается, что теоретически может придти такое сообщение, которое повреждает базу… Но где тогда гарантия, что кто-то не будет присылать его нам ежедневно? Выяснилось, что речь идет о программах сторонних разработчиков, типа антивирусных сканеров и т.п. Они могут некорректно отработать с базой, и повреждения реплицируются на все остальные копии.
    Второе замечание – а почему речь о recovery-базе данных? Я всегда считал, что переключившись на копию с задержкой, мы делаем ее активной и рабочей, и все изменения от нее до текущего момента теряются безвозвратно (если не считать транспортного дампстера, который хранит свежие сообщения, но там установки по умолчанию небольшие, и это сильно не поможет).

  6. >а почему речь о recovery-базе данных?

    Если вы мне подскажете как подругому перескочить на нее, буду вам благодарен. Я нашел только такой вариант восстановления.

  7. Есть “грязный вариант” – удалить все non-lagged copies. Та база, с которой работали будет единственной активной базой, с нее и будем реплицироваться.
    Вариант с lagged copy стоит рассматривать только в случае полного отказа от backup’ов.