Механизм свертывания журнала существует довольно давно, однако большинству администраторов, по всей вероятности, о нем ничего не известно, так как их реплицированные базы данных, как правило, используются довольно интенсивно и потребности в искусственной репликации никогда не возникает. Но я — не такой, как все (по крайней мере, так мне говорили). После применения обновления к серверу Exchange 2013 мне показалось, что свертывание журнала вернулось. Но на самом деле это не так, и вот почему.
Свертывание журнала — метод, используемый в кластерах типа CCR/SCR в Exchange 2007 для принудительной репликации между членами кластера в периоды отсутствия значительной активности на серверах. Когда серверы заняты, репликация журнала происходит регулярно по мере заполнения 1 Мбайт журналов. Программе Exchange приходится закрывать активный журнал, создавать новые журналы и выполнять репликацию. Происходит отлаженный цикл.
Однако если активность серверов низкая, частично заполненный журнал транзакций может «повиснуть». Он предусматривает операцию надежной фиксации, отмечающую конец транзакции, но репликация на серверы, содержащие копии базы данных, невозможна. Конечно, вы помните, что транзакционные данные, представляющие единственное сообщение, могут занимать несколько журналов (если размер каждого журнала составляет всего 1 Мбайт), а конец транзакции отмечается надежной фиксацией. Поэтому серверы не могут определить, что транзакция завершена, и если на данном этапе произойдет сбой, транзакция может быть потеряна. Чтобы решить эту проблему, Exchange закрывает журнал и начинает принудительную репликацию, если текущий журнал транзакций частично заполняется в течение 90 секунд. Как объясняется блоге Тима Макмайкла (см. blogs.technet.com/b/timmcmic/archive/2009/06/09/exchange-2007-sp1-ccr-lcr-scr-transaction-log-roll.aspx), кластер CCR/SCR Exchange 2007 может ежедневно создавать 960 файлов журналов, даже если на первый взгляд он не выполняет каких-либо действий из-за фонового обслуживания или по другим причинам.
В Exchange 2010 также используется свертывание журнала, но в более скромных масштабах. На неактивном сервере группы обеспечения доступности баз данных (DAG) свертывание журнала может происходить каждые 15 минут, то есть ежедневно могут создаваться только 96 файлов журналов.
Но Exchange 2013 не использует свертывания журнала. Думаю, что причина, побудившая разработчиков отказаться от свертывания журнала — появление блочного режима репликации в Exchange 2010 SP1. Этот механизм обеспечил надежный способ безотлагательной репликации данных между серверами в группе DAG.
Exchange автоматически переходит между репликацией в файловом режиме (нормальное состояние при запуске) и репликацией в блочном режиме. Администраторы не решают, когда сервер должен задействовать блочный режим репликации. Все происходит в фоновом режиме. Служба Replication отслеживает состояние репликации, и если все в порядке (журналы не скапливаются в очередях для копирования и преобразования), то используется репликация в блочном режиме. А когда используется блочный режим, транзакции пересылаются на сервер, на котором размещаются копии базы данных, сразу же после их завершения в буфере журнала. Никаких задержек, связанных с ожиданием, нет, пока 1 Мбайт данных не окажется в журнале транзакций.
Репликация в блочном режиме работает превосходно. Репликация в файловом режиме всегда доступна как запасной вариант в случае, когда блочный вариант становится ненадежным из-за условий в сети или по другим причинам.
Я знал, что свертывание журнала удалено из Exchange 2013 RTM, но после применения недавнего обновления Exchange 2013 к серверу заметил, что базы данных, казалось, формируют журнал через каждые 15 минут — точно так же, как при свертывании журналов (см. экран). Движимый любопытством, я попросил разъяснений у группы разработчиков Exchange. Они отнеслись к вопросу очень доброжелательно, и вместо того, чтобы посмеяться над моей несообразительностью, пояснили: «синтетические транзакции».
.jpg) |
| Экран. Журналы базы данных Exchange?2013 |
Возможно, вы помните, что в Exchange 2013 предусмотрен механизм автоматического мониторинга и обслуживания системы, именуемый Managed Availability, который постоянно проверяет состояние различных компонентов Exchange с использованием исчерпывающего набора зондов, мониторов и ответчиков. Очевидно, очень важно, чтобы базы данных находились в исправном состоянии, а пользователи могли подключаться к базам данных для отправки и приема сообщений электронной почты. Часть набора тестов Managed Availability предназначена для сквозной проверки удобства работы пользователя, и как вы, вероятно, догадались, эти тесты повторяются приблизительно через каждые 15 минут. Для этой цели используются почтовые ящики состояния.
Замеченное мною кажущееся свертывание журнала было ничем иным, как записываемыми в базу данных синтетическими транзакциями, выполняемыми Managed Availability с целью проверки состояния базы данных. Это естественное следствие проверки исправности сервера. Так что никаких оснований для беспокойства нет.