30 января 2007 случился самый крупный сбой системы рейтинга top.bigmir.net, чуть не приведший к его полному уничтожению. Этот материал рассказывает о событиях тех дней.

Многие помнят, как год назад зашли проверить статистику своих сайтов на top.bigmir.net и были удивлены. "С 14 часа 30.01.2007 по настоящий момент статистика рейтинга top.bigmir.net недоступна в связи с повреждением 67% массива RAID 1+0 одного из серверов баз данных, который обслуживает рейтинговую систему портала...". Эта надпись вместо десятков отчетов была размещена на разделе 6 дней.

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

Итак, хронология событий.

Утро. Помнится, был еще какой-то политический фон... Все как обычно - шутки, стук клавиш. Я занимался утилитой собирающей дерево сайтов. Наша команда из пяти разработчиков я, Юра Дорошенко, Женя Кубичка, Антон Войтович и Витя Лушкин в те дни заканчивала работу над выпуском новой версии рейтинга, оставались небольшие косметические доработки.

В обед, кажется это было 15:20, в кабинете ацкого сатаны раздается звонок, сервер базы данных пропадает. Злобный смех... Занавес.

Звонок к сиcадминам. Продолжаем работать, для разработки есть своя копия базы.
Прошел час, звонки и письма учащаются, админы рейтинга то и дело нервно спрашивают когда все починится, иду к сисадминам. Александр Яцюк (aka Logka) был на месте и разговаривал матом с консолью. Logka объяснил, что пострадало хранилище БД, и он запускает внутренние тесты и диагностику, чтобы оживить его. Вылетело 4 из 6 дисков RAID1+0. Было множество прогонов и "пусков", каждый отнимал кучу времени. А сам демон продолжал накапливать необработанные данные о посещаемости тысяч сайтов.

Logka: «Хорошо помню тот день. Сервер упал. Поехал на площадку. Смотрю в биос контролера - нету 4х винчестеров из 6ти. Ну ладно мы привыкли, что может один веник потеряться, ну 2. А тут 4! Структура десятого рейда такова, что мы могли потерять 3 дублирующих диска и работать дальше. Но судьба имеет свое извращенное чувство юмора :) С площадки уехал под утро. Пару часов поспать. На следующий день становится понятно, что из дампа нам не восстановится так хорошо как хочется.»

Александр Типлинский (aka Astral): «Был собран RAID10 из 6-ти дисков SCSI 36Gb. В один момент контроллер сказал, что у него "вылетели" 4 диска. Spare дисков не было, так как корпус допускал установку всего 6-ти HDD. Однако сомневаюсь, что их наличие повлияло бы на ситуацию»

Паники нет, иногда только нервные смешки - черный юмор разряжает обстановку.
Масштаб проблемы очертился под вечер, когда стало понятно, что базу мы можем потерять. Logke удалось оживить один диск, но этого было мало.

Astral: «Резервная копия (ночной mysqldump базы) была, но быстро развернуть её толком не получалось - вылазили боком кириллические комментарии к таблицам и возникали ошибки с DUPLICATE KEY, а редактировать файл размером больше 50GB ещё то удовольствие...»

Было ясно, что даже если дамп поможет нам, то только, если мы откажемся от части данных 30 числа. Этот вариант оставался как самый крайний. Весь следующий день мы ждали известий из Епос.

Astral: «Сервер отвезли для восстановления данных в Епос, а на его замену срочно купили новый... В итоге Епос смог восстановить данные и муки с огромным dump-ом остались лишь хорошим уроком на будущее»

Logka: «Помню как забирал инфу из Эпоса. Я им предварительно указал, что самое главное для нас /var/lib/mysql/. Дают мне винт - говорят вот ваше файло. Смотрю на размер - а там лишь гиг 40. Большие, важные таблицы пустые. Ну все-равно лучше чем ничего. Плюс дают еще один винчестер - тут полный дамп вашей системы. В общем еду в офис и уже думаю как выдирать из большого файла нужные куски дампа. Сколько же было радости, когда на втором винчестере оказалась база в полном размере %) В данном случае злую шутку сыграла файловая система NTFS, на которую работники эпоса скопировали файлы баз данных. Винда почему-то не поняла файлов, которые больше 8ми гиг. А вот в полном дампе - где ext3 было все хорошо. Ну мы соответственно насетапили новый сервак и возникла новая проблема. А куда же блин воткнуть этот sata диск с данными ? :) У нас то везде scsi. В новом сервер в карманы только SCSI. Пришлось производить операции на столе, с открытым сервером, подвешенным винтом. Какже я боялся уронить или стукнуть этот винт с данными :))) Пересобрал ядро(наверно из-за усталости и чего-то еще собралось не с первого раза - тоже потеря времени, тоже просидка под дующим кондиционером). Скопировал инфу, вынул веник, позвонил Астралу - мол чЕкай таблицы, ты дома, тебе там тепло и чай есть. А сам уехал спать. Ибо уже надо было :)»

Основной план "спасения" сформировался к утру следущего дня. Мной была собрана утилита для "вливания" данных накопленных счетчиком за период простоя базы, а Юра Дорошенко адаптировал скрипты для расчета часовых и суточных отчетов. Короче, как только админы установили новое железо с вновь обретенной БД, мы стали понемногу "догонять" счетчик; он продолжал накапливать необработанные данные, а мы вливали в БД старые. Сейчас кажется, что могли обойтись без многих сложностей, но тогда мы делали что могли. Были моменты, когда казалось, что все происходит только для того чтобы помешать нам. У Юры стали ремонтировать домашнюю сеть - на несколько часов он выпал из работы. Моя сеть тоже работала отвратительно. Скорость обработки данных, не учитывая помех, была невысокой - около 4x1, т.е. за час мы нагоняли три часа отставания. Надо еще не забыть про сон, кажется мы все-таки спали ))

Догнать счетчик мы смогли только в воскресенье к вечеру, кажется часов в семь. Когда мы закончили, и я посмотрел на отчеты, единственное что утешало, это их наличие. Статистику просто "трясло". Но она работала )

Моей финальной фразой стало «После того, что мы проделали с рейтингом, нам надо на нем жениться»

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

Еще бы мы не сделали выводов )
Astral: «Сейчас база лежит на внешнем хранилище, на основном сервере включен binary log, а резервные копии делаем с реплики простым копированием.»

Что стало причиной сбоя? Я не знаю ответа до сих пор. Происки конкурентов, не исключено и не факт, адский электрон, критический бит, сейчас уже не узнать...

Logka: «Причиной сбоя явилась как всегда (по нашим подсчетам 90% неисправностей серверов) локальная дисковая система. RAID контролеры хоть и созданы для надежности и скорости все же имеют показатель надежности как таковой. Кроме того у них есть еще и прошивка - программное обеспечение, которые тоже пишут люди, которые тоже умеют делать ошибки. Ну и плюс сами винчестеры. Исходя из нашего опыта - SCSI диски, которые в жесткой нагрузке отработали полтора года - следует менять. Но как всегда эта процедура требует времени. А время для систем, которые предоставляют сервис пользователям 24x7 выбрать сложно. Задержкой по времени диагностирования проблемы стала также устаревшая прошивка RAID контролера на тот момент. Ну и конченый контролер Adaptec, который не умеет без потери информации поднимать винчестеры в RAID. Хорошо помню, как на сканирование одного винчестера уходило по полтора часа, которые приходилось проводить под промышленными кондиционерами, закутавшись в куртку :) Имей мы тогда нормальную систему бэкапа (для базы такого размера) - восстановились бы быстрее. Но 6 винчестеров ели справлялись с нагрузкой записи/чтения реальных sql запросов. Включение репликации на старом железе не было возможным. Хорошо теперь, когда базы на внешнем хранилище, bin-log пишется на локальный веник, а место для временных таблиц выделено в памяти :) Виват новому железу! Виват внешним хранилищам данных с избыточностью и хорошим масштабированием.»