Что нового в Exchange 2016. DB Divergence detection.

Потихоньку начинаем исследовать, что же нового появилось в Exchange 2016. И, раз уж недавно состоялась седьмая по счету встреча UC2, на которой Дмитрий Хребин рассказал про нововведения в Information Store, начнем именно с этих изменений. А именно сегодня затронем только одну новую функцию – “DB Divergence Detection”.



Один из важных процессов, которые ESE производит с почтовой базой – это проверка контрольных сумм (checksumming). Суть этого процесса: из базы читаются страницы с данными, высчитывается контрольная сумма для каждой страницы и затем сравнивается с контрольной суммой, записанной в самой странице. Этот процесс проверяет почтовую базу на ошибки во время записи страниц (physical corruption). В старых версиях Exchange (<= Exchange 2007 RTM) этот процесс выполнялся во время бекапа базы. Т.е. успешно забекапленную базу можно было считать «здоровой».


Немного истории

С появлением Continuous Replication в Exchange 2007 появилась возможность бекапить не только активную, но и пассивную копию. Что, собственно, и являлось рекомендацией при выборе типа архивирования, т.к. можно было разгрузить ноду с активной копией.

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

С приходом Exchange 2007 SP1 это поведение было исправлено. Это стало возможным благодаря новому процессу, который получил название Database Checksumming (Online Maintenance Checksum). Суть этого задания заключается в том, в режиме 24х7 контрольные суммы подсчитываются и проверяются как для активной копии, так и для пассивной.

Включение/выключение этой функции, как ни странно, но возможно. Хотя и описание этой настройки может смутить, она контролирует только Online Maintenance Checksum.

Для Exchange 2013:

image


Для Exchange 2010:

image


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



DB Divergence detection

И вот мы подошли к основной теме этой статьи.

Пару недель назад мне «посчастливилось» столкнуться с проблемой, когда из-за ошибок в системе хранения почтовая база просто-напросто размонтировалась. И монтироваться дальше отказывалась. После попыток ее реанимировать (вплоть до eseutil /p), хотя и удалось перевести базу в состояние Clean shutdown, но при попытке монтировать служба IS падала с ошибкой JET_errDbTimeTooNew.

Вкратце эта ошибка сводится к тому, что отметка времени для страницы в лог файле отличается от отметки времени для страницы в почтовой базе. Более подробно об этой ошибке можно почитать в статье Error–567 ( JET_errDbTimeTooNew )

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


Exchange 2016 совсем кардинально не меняет данную ситуацию, но теперь может предупреждать о таком типе ошибок.

Реализован данный механизм следующим образом:

  1. Во время Online Maintenance Checksum помимо того, что для страницы высчитывается контрольная сумма в памяти и проверяется со значением, записанным в самой странице, генерируется таблица с контрольной суммой и временной отметкой, которая за счет транзакционнах логов передается на сервер с пассивной копией
  2. Полученные данные сравниваются с данными для страницы из пассивной копии
  3. В случае, если не совпадает только контрольная сумма, активируется механизм Page Patching
  4. В случае, если не совпадает контрольная сумма и временная отметка, генерируется событие в лог о проблеме

image

Картинка из сессии Дмитрия Хребина UC². Встреча №7. Запись доклада.


События, которые могут генерироваться в пункте №4, могут быть следующие:

  • ESE Event 538 – DBTIME_CHECK_MISMATCH_ACTIVE_DB_BEHIND_ID
  • ESE Event 539 – DBTIME_CHECK_MISMATCH_PASSIVE_DB_BEHIND_ID

События, которые могут генерироваться в пункте №3, могут быть следующие:

  • ESE Event 540 – DB_DIVERGENCE_ID


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

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



Читайте также:

Добавить комментарий