Итак, причина исчезновения питания проста до банальности. Один из посетителей дата-центра
вдавил кнопку аварийного отключения питания (наличие Большой Красной Кнопки возле каждого выхода из здания требуется согласно государственным стандартам пожарной безопасности США — так удобно работать пожарным), затем вернул ее в прежнее состояние, опустил защитный кожух на место и покинул здание.

Как говорит Фитцпатрик, он помнит случай, когда какой-то лопух подумал, что большая красная кнопка возле выхода должна открывать дверь. Тогда она была не помечена и никак не защищена. Что случилось сейчас — неизвестно: «Может, парень бежал и упал прямо в кнопку… загадка», — недоумевает Фитцпатрик.

Так или иначе, но почему потребовалось так много времени на восстановление системы? Здесь множество причин.

1. Материнские карты с глючными встроенными сетевыми картами, которые некорректно поддерживают функцию авто-согласования (оперативное автоматическое конфигурирование). Таких оказалось 9 штук. Их пришлось настраивать вручную.

2. Загрузка базы данных. Большинство машин восстановили свою
работу после появления электричества, меньше чем через час, но база
данных не была настроена на автоматическую загрузку резервной копии после сбоя. Раньше, если какой-то сервер падал, то это не создавало проблем, потому что резервная копия всегда была на соседнем
сервере. Но когда они перезагрузились все вместе, то работающих БД не осталось, и базу пришлось запускать вручную.

3. Проверка данных. Конечно, можно было запустить все БД
и надеяться на лучшее, но инженеры решили сначала все проверить и перестраховаться. Во-первых, были сделаны
резервные копии всех баз до их запуска. Перед загрузкой нужно было проверить целостность таблиц, которые хранятся в формате InnoDB, а также преобразовать некоторые таблицы из MyISAM в формат
InnoDB, чтобы проверить их тоже. На каждой машине в глобальном кластере прошло переиндексирование и проверка данных. Это заняло много времени.

4. Проблемы с дисковым кэшем. На серверах работали RAID-карты с автономным питанием, но оказалось, что эти карты не отключали дисковое кэширование.

5. Большинство slave-серверов были оптимизированы на максимальное быстродействие, а не на синхронизацию, поэтому восстанавливать их пришлось очень долго.

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

Поскольку на серверах не использовалась синхронизация бинарного
журнала (binlogs) с жестким диском, некоторые транзакции, которые произошли на серверах непосредственно перед отключением питания, оказались безвозвратно потеряны. Администрация Livejournal извиняется перед пользователями, чьи записи оказались уничтожены.

Чтобы избежать таких проблем в будущем, планируется провести апгрейд материснких плат, подключить источники бесперебойного питания к другой сети, вручную отключить дисковое кэширование за RAID-картами, закончить миграцию с MyISAM на InnoDB, активировать синхронизацию бинарного журнала (binlogs) с жестким диском, перевести другие настройки серверов от производительности к защищенности, а также внедрить утилиту резервного копирования каждого юзера
в файл GDBM, которая должна работать для всех пользователей в реальном режиме времени. Эта утилита позволит не только ускорить процесс восстановления, но и восстанавливать пользователей
в системе независимо друг от друга. Например, сначала платные аккаунты (таких всего 1,6% среди 5,8 млн пользователей), потом самых активных пользователей и т.д. Да и вообще, полезно поддерживать резервную копию в разных форматах.

Кроме того, говорит Фитцпатрик, уже закуплена куча дополнительных жестких дисков для бэкапа, так что Livejournal
основательно проапгрейдился. Подобного больше не должно повториться — честное слово.

www.webplanet.ru