На днях в своей практике столкнулся с невиданной ранее ошибкой:
Так-так, что у нас тут? О, Ктулху, что это за четыре звездочки в отметке даты последней индексации? Оу, это лотус, детка... поработаешь с ним - и таким штукам больше не удивляешься. Смотрим дальше. Открываем представление "($ALL)", что же у нас там:
Ну дела! Дата модификации - тоже выглядит странно. А ну, что там в свойствах документа?
А там, уже ставшие знакомыми нам, звездочки на том месте, где мы ожидали увидеть год. На этом месте у меня возникло неприятное предчувствие... А как же так? Создано 03.02.2015, а модифицировано 03.02.**** ? Это вообще что за год? Интересно! Попробуем выяснить:
Создаем вычисляемое поле с вышеуказанной формулой. Открываем документ:
Whaaaaaaat?!!! Что это еще за Футурама?!! Год тридцать шесть тысяч четыреста восемдесят девятый от Рождества Христова!
Но самый главный вопрос заключается в том, как теперь с этим жить и что важно - как исправлять?
Оказывается, что при попытке создать или модифицировать любой документ в базе, включая элементы дизайна - таймстамп ставится испорченный, со звездочками вместо года.
Первое, что приходит в голову любому здравомыслящему человеку - часы на сервере сбились. Лезем, проверяем.
СерверПроверка показала, что время установлено правильно и даже настроена синхронизация с NTP, и что совсем неожиданно - даже Time Zone выбрана корректно.
OS: Debian Linux 6
Domino: Lotus Domino for Linux 7.0.2
Следующее, что пришло в голову - перестартовать сервер домино и проверить, не уйдет ли ошибка. Перестартовал, но без особой надежды на успех. Как и ожидалось - таймстампы как ставились, словно бы из далекого будущего, так и ставятся.
Следующим шагом я проверил на наличие этого бага остальные базы на сервере. Слава превеликому Ктулху - оказалось, что в этом плане, с ними все было в порядке. Команда "SHOW SERVER" из консоли сервера тоже не продемонстрировала каких-либо отклонений с временем.
Сложив все вышеперечисленное, пришел к заключению, что проблема в самой базе. Ну что же... делаю бэкапы, бэкапы на бэкапы и бэкапы на бэкапы на бэкапы.
Запускаю старый-добрый fixup из консоли. Ошибок не обнаружено.
Разумеется, что в очередной раз, внимательно исследовав диалоговое окно свойств базы - не нахожу там опцию "Ставить отметку времени на 36 тысяч лет вперед". И даже близко похожей по смыслу опции тоже нет.
Самая очевидная гипотеза - нарушение структуры файла хранилища. В пользу этой гипотезы говорит еще тот факт, что сервер находится в стойке, которую довольно часто (к примеру, в прошлом году, это было около 30 раз) отрубают от электричества и бесперебойником он не оснащен. Теоретически, у себя в голове я даже представляю, что должно сломаться в файле, чтобы возник такой эффект. Но, к сожалению, на практике магия этого уровня мне еще не доступна. Notes Storage Facility остается для меня в большой мере, Черным Ящиком.
В любом случае, подкрепить эту гипотезу фактами мне еще предстоит. К счастью, на сервере установлен munin. Можно зайти в базу, отыскать среди всех документов период, когда даты обзавелись звездочками и наложить на график отключений электричества в munin-е. Но это исследование прийдется отложить на следующий раз; как-то так совпало, что на момент написания этого поста, сервер снова не доступен.
Переходим ко второй части Мерлезонского балета: как нам это починить?
Первая мысль: сделать локальную реплику - теоретически, ошибка останется на серверной копии базы, а локальная создастся без ошибки. А затем - подложить локальную базу на сервер.
Проверяем. Нда, не получилось. Звездочки тут как тут.
Второй вариант, который я испрововал - накатил на базу шаблон ntf. Накатилось без ошибок, но проблему не исправило.
В итоге, я психанул и решил действовать радикально:
- Создал на сервере новую пустую базу.
- Накатил на нее шаблон дизайна.
- Проверил, что отметки времени без ошибок.
- Остановил сервер, забрал испорченную базу на локальный компьютер
- Использовал скрипт для смены Replica ID взятый отсюда: http://searchdomino.techtarget.com/tip/Use-Script-To-Change-The-Replicaid-Of-A-Database
- Отреплицировал все документы.
- Еще раз проверил - отметки времени создаются корректно.
В сухом остатке имеем рабочую базу, но с частью документов, с поврежденной датой.
Возникает вопрос: зачем эти шаманские выкрутасы со сменой Replica ID, если можно просто скопировать документы?
Ну, во-первых: при копировании документов, у них меняется Document UNID. Это дополнительная головная боль, т.к многие структуры внутри базы зависят от него.
И во-вторых, у всех пользователей на локальных клиентах перестанет открываться база, т.к все ссылки указывали бы на старую базу, со старой Replica ID. Это лишний гвоздь в крышку гроба админа, учитывая, что пользователи этой базы не имеют почтовой учетной записи и разослать ссылку на новую базу не удастся.
Впрочем, как мне теперь самому кажется, мое решение вышло слегка, как говорится, overcomplicated. В свое оправдание, можно отметить, что времени на все эти махинации у меня было не так уж и много, поэтому, хотелось действовать наверняка.
