2010-01-15 InnoDB не разваливается, разваливается память!
Однако, история с InnoDB исчерпана.
Сначала было подозрение на OPTIMIZE. Попробовал — не воспроизвелось.
Часик повосстанавливал, танцами с бубном вокруг разных значений опции innodb_force_recovery. В какой-то момент непонятным образом удалось снять mysqldump предположительно повреждённой базы и потом залить его обратно, после чего MySQL запустился более-менее без ошибок, по крайней мере, без segmentation fault’ов. Тут мне бы, конечно, снять полный дамп всех баз, увидеть ошибки, если они есть, либо получить копию данных, если их нет, но нет! Появилась новая идея.
Потом было подозрение на checkarray софтового RAID’а, запускающийся каждую неделю из крона. Попробовал. Воспроизвелось. Да так воспроизвелось, что при восстановлении данных таки похерилось, правда, лишь чуть-чуть и ненужных (немножко старых ревизий статьи, у которой их всего > 200, велика потеря). Ну, думаю, вот ты гадина, а! Ну, думаю, снова меня XFS, пусть даже в связке с mdadm’ом и InnoDB, обидел! Ну, думаю, ах я его! И сделал его ах — /var/ перенёс на ext3 — не ext4, потому что ядро ещё было 2.6.26, а в нём, дебиановском, ext4 нема, и InnoDB на «сырой раздел» (Raw Device) повесил, просто на RAID’овый, то есть без XFS’а в качестве слоя промежуточного. Провёл checkarray одновременно с обновлениями базы — уцелела. Лёг спать.
А за ночь база успела рассыпаться снова и уже без посторонней помощи mdadm’а. А я, зайдя на сервер, совершенно случайно стал архивировать 2-гиговый лог bzipом2. Архивировал он, архивировал, а потом и сказал — не хочу больше, устал. Может, у меня самого баг, но я в это не верю и надеюсь, что не будет никогда этого (заявление прекрасное), может, это компилятор скомпилил не туда и не то… А может, это у тебя с памятью что-то? Ну а частично записанный файл я, конечно, удалю, нафига тебе мусор всякий собирать.
Я и подумал — а может, у меня и правда с памятью что-то? Оказалось, действительно, даже memtester — не путать с memtest86/memtest86+, запускающимся вне операционной системы какой бы то ни было — на одном тесте и некоторых проходах обнаруживал ошибки. Правда только на одном тесте и не на всех проходах, но мы-то знаем, что их быть не должно вообще. Вот так и решилась проблема с разваливающимся InnoDB — заменой памяти. Для сервера её объём, кстати, был уже почти неприличен (2 гб). Теперь 4 гб. Тоже немного, но сервер-то изначально за «корок сопеек» самосборный, да и то халявит-простаивает, так что нефикЪ.
Кстати, памятью были две 1 гб планки Kingston’а 533 МГц’овых, полный мемтест я по ним ещё не гонял, но судя по тому, что с заменой всё починилось — именно они и были виновны. Мемтест погоняю и отчёт выложу, а пока запомним, что прожили они — парой, вместе и счастливо — всего примерно 2.5 года. А на новые 2гб Hynix’а во Флеше дали гарантию аж 5 лет, так что временно — до того, как накроется уже и Hynix — запишем, что Kingston — говно.
А ещё я из этой истории извлёк урок — бэкапы надо делать не на случай, что харды накроются — харды просто так не накроются, и от них RAID спасёт, а на случай, что чьи-то кривые ручки (программистов, конечно), внесут Страшный Баг в твои данные, и RAID не спасёт, а только размножит ошибку радостно по всем дискам. Либо ещё один вид бэкапов — «Larin-style». Которые закатываются на диски и закапываются на даче. Это на случай уничтожения или утраты. Или визита гоблинов.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.