We rise up for the things we believe in over and over again
Потихоньку прихожу в себя от сегодняшней мозголомки. Умом понимаю, что такие проблемы, как эта, надо ценить и коллекционировать. Когда становится бессильным даже гугл - that's a challenge. Впрочем, обо всем по порядку.
Итак, есть задание - перенести базы с одной системы хранения данных (назовем ее ареной), на другую такую же систему. Первая арена предназначена под тотальный апгрейд и переконфигурацию. Обе арены подключены к серверу Exchange, разделы сконфигурированы и видны, как диски. Все готово для переноса, процедура которого весьма обыденна - нужно отмонтировать нужную базу данных и перебросить ее файлы в нужный каталог. С этим проблем не возникло никаких. База успешно поднимается, лежа уже в новой папке на новой арене.
После копирования файлов базы было решено сразу же завершить копирование группы хранения, в которой эта база находится. Это включает в себя перенесение chk-файла и файлов логов группы. Сказано, сделано. Подготовлены каталоги, отдана команда на перенесение одного, потом другого. Все успешно. Курсор мыши зависает над пунктом Mount Database. Один щелчок кнопкой, и...
Произошла внутренняя ошибка обработки. Попробуйте перезапустить диспетчер Exchange System Manager или службу Microsoft Exchange Information Store, или обе службы.
Код события: c1041724
Exchange System Manager
Первый звонок о том, что что-то пошло совсем не так, как планировалось. О перезапуске Information Store речи не идет, downtime будет не запланированным, отчего по голове не погладят. Первым делом смотрим в логи. Computer Management, Event log, Application...
Description: "Information Store Unable to read the header of logfile Exx.log. Error -530
Много непечатного. Очень много. Потому что весь интернет с MS во главе при такой ошибке дают два варианта действий: либо восстановление из бекапа, либо... eseutil /p, о котором мне писать уже доводилось. Спасибо, не надо, это долго. Да, я знаю, что у меня проблема с базой, но это не основная база, потому есть время на размышления.
Первым делом предпринял попытку вернуть логи назад... к моему великому удивлению - база примонтировалась и спокойно заработала без каких-либо ошибок. Мистика. Повторное отключение и перенос на новую арену. Результат описан выше. Снова возвращаю логи в исходную папку. Работает. Мистика дважды. Ради интереса переношу логи на системный раздел сервера Exchange - все работает. Возвращаю назад и логи, и базу (копия осталась в исходной папке) и ложусь спать, потому что время на тот момент было уже два часа ночи (работал из дома).
По приходу на работу утром предпринимаю еще одну отчаянную попытку переместить логи на новое место, только создал для этого тестовую группу хранения с тестовой базой внутри. Как легко догадаться, за ночь ситуация лучше не стала. База отключена, состояние - Clean Shutdown, то есть для ее работы логи в принципе не нужны. Что ж, копирую их в безопасное место, после чего уничтожаю их на новой арене, проверив, что сам Exchange будет их искать там. Расчет был на то, что даже если файлы и портятся при копировании, сервер просто создаст новые логи на новом месте. Это вполне допустимо, если есть резервная копия (она есть). Хотя и непонятно, почему при обратном копировании все работает, ведь файлы могут быть повреждены. К моему великому удивлению, логи создались на новой арене без проблем и вся база данных успешно примонтировалась.
Следующая стадия эксперимента - перенесение этих новых логов с новой арены в какую-нибудь папку на старой. Неудача. Та же самая ошибка, и то же самое восстановление работоспособности после перенесения их в их "место рождения", то есть на новую арену. Ради интереса переношу их на системный раздел, ожидая увидеть ошибку. Не ошибся.
Получается очень интересная ситуация. Логи, созданные вне новой арены, можно таскать куда угодно, но только не на новую арену. Логи же, созданные на новой арене, можно таскать как угодно на этой арене, но вне ее база работать отказывается. Чувство, что файлы на арене кодированы, но никто никакой кодировкой не занимается.
Дальше идет несколько часов курения гугла, всевозможных манов, форумов и им подобного. И везде одно и то же - бекап, eseutil. В голове третий вариант об отказе от старых логов для всех групп хранения и создании их на новой арене. Но это неправильно, потому что в прошлый раз при перенесении баз ничего подобного не было.
Под конец дня решил повнимательнее присмотреться к логу, который выдается, как сбойный. Файл как файл, MD5-хэши одни и те же, значит он не меняется и речи о повреждении не идет. Тогда что мешает? Unable to read the header of logfile. Но это Information Store не может прочитать. А что если взглянуть на файл под микроскопом?
eseutil /ml exx.log
Результат огорошил:
Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current volume's sector size)
О таком я не слышал никогда. Чтобы лог файл не мог прижиться на новом устройстве, размер сектора которого отличается от размера сектора диска, где лог был создан. Эксперимента ради рассмотрел живой лог и на старой арене, и на новой. Результат сказал обо всем:
Env Log Sec size: 512 - на старой.
Env Log Sec size: 4096 - на новой.
Разделы и на одной арене, и на другой, создавались без меня. И никто не придал значения параметру Sector Size в настройках слайсов рейд-массива, сомневаюсь, что сам бы это сделал. Однако, значение это имеет, и довольно большое. Проблема лишь в том, что массив перебивать уже нельзя.
В итоге все же решили остановиться на варианте создания новых логов, это будет быстрее. И как всегда, бекап, бекап, бекап.
До сути проблемы докопались, это уже хорошо. Урок и полезная информация на будущее. Надеюсь, что кому-то она сэкономит много нервных клеток.