Исправление работы MySQL при поломке innoDB-таблиц

    Здравствуйте!
    mysql innodb
    Я (быть может, как и вы) — разработчик сайтов, и мне, чтобы все мои наработки не потерялись нужен SVN. А так как я работаю не один, то еще, как минимум, и общая БД. Несколько лет назад мы приобрели NAS-сервер Synology DS-101 (Tom`s Guide или Nix), устроили там хранилище, включили базу (правда, MySQL4). Несколько лет служил он нам верой и правдой, пережил приход пьяных электриков (когда нас сначала подключили на 380В, а потом спохватились — почти все погорело), но вот… несколько недель назад база не хотела загружаться. Пришлось исправлять.

    Все бы ничего, если бы этот случай не повторился…


    В первый раз на сервер в срочном порядке была залита новая прошивка, разрешающая доступ по telnet. Не забываем, там очень сильно урезанный линукс — Linux version 2.4.22-uc0 — установка чего-либо производится через telnet, а по SSH система требует рута, под которым не пускает. После пары часов была выявлена проблема — не запускается именно демон mysqld. Попытавшись вручную запустить mysqld, вылезала ошибка, она же собственно была и в логах, следующего содержания:

    100209 14:04:59 mysqld started
    100209 14:05:00 [Warning] Setting lower_case_table_names=2 because file system for /volume1/@database/mysql/ is case insensitive
    InnoDB: Database page corruption on disk or a failed
    InnoDB: file read of page 5.
    InnoDB: You may have to recover from a backup.
    100209 14:05:00 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex (...большой дамп ~ на 16КБ...)InnoDB: End of page dump
    100209 14:05:04 InnoDB: Page checksum 2825884538, prior-to-4.0.14-form checksum 2024336829
    InnoDB: stored checksum 1598293605, prior-to-4.0.14-form stored checksum 2024336829
    InnoDB: Page lsn 0 2531807, low 4 bytes of lsn at page end 2531807
    InnoDB: Page number (if stored to page already) 5,
    InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
    InnoDB: Database page corruption on disk or a failed
    InnoDB: file read of page 5.
    InnoDB: You may have to recover from a backup.
    InnoDB: It is also possible that your operating
    InnoDB: system has corrupted its own file cache
    InnoDB: and rebooting your computer removes the
    InnoDB: error.
    InnoDB: If the corrupt page is an index page
    InnoDB: you can also try to fix the corruption
    InnoDB: by dumping, dropping, and reimporting
    InnoDB: the corrupt table. You can use CHECK
    InnoDB: TABLE to scan your table for corruption.
    InnoDB: See also dev.mysql.com/doc/mysql/en/Forcing_recovery.html
    InnoDB: about forcing recovery.
    InnoDB: Ending processing because of a corrupt database page.
    100209 14:05:04 mysqld ended


    Получается, что я не мог запустить mysqld без того, чтобы исправить порушенные таблицы, и не мог исправить таблицы без запуска демона.
    Полазив по интернету, нашлось два пути решения данной проблемы:
    Первый и Официальный — dev.mysql.com
    Второй и менее официальный — mysqlperformanceblog.com

    Первый вариант решения проблемы подразумевает запуск демона так:

    mysqld --innodb_force_recovery=4

    таким образом, мы даем понять серверу, чтобы он:

    Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate table statistics.
    (Предотвращать операции слияния вставки буфера. Если они вызывают аварию, не выполнять их. Не считать статистику таблиц)


    Если короче — то чтобы сдампить таблицы, и перераспределить место на диске под таблицы innodb.
    С этим параметром сервер запускается, но CHECK TABLE показывает OK. OPTIMIZE TABLE для innodb-таблиц не поддерживается движком.

    Нужно каким-либо образом обратиться к таблицам innodb (например, создать INSERT-запрос) — mysqld перераспределит место. После перераспределения места мы сможем запустить демон myslqd в нормальном режиме, т.е. просто перезапустив NAS-сервер (это в нашем случае). Не могу сказать, что какие-либо данные недоступны — сдампил без ошибок и проблем. Возможно, в таком случае мы все же что-то теряем — пусть меня поправят специалисты.

    Второй вариант (с майэскулперформансблога) представляет собой запуск демона с innodb_force_recovery=1, создание <new_table> c движком MyISAM и попытку загнать туда все записи из таблицы с innodb. Вкратце описывается это так:

    CREATE TABLE <new_table> LIKE <crashed_table>;
    INSERT INTO <new_table> SELECT * FROM <crashed_table>;


    И переименовываем.

    Если же нужно найти именно те строки, на которых он рубится, используется метод нескольких вставок (INSERT IGNORE) в новую таблицу с лимитом. Там все подробно расписано.

    Надеюсь, эта маленькая статья кому-то поможет в похожей ситуации, потому как мне первый раз понадобилось достаточно большое время, чтобы все исправить. У меня было время — у вас его может не быть. Также призываю специалистов по MySQL включиться в обсуждение данного вопроса — почему innodb падает.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 11

      0
      не то что-б я против «насов» синолоджи, мне они очень даже нравятся, но использовать их как MySQL БД это свежо… я в курсе что там и пых и мускуль но они все-же там для другого, а можете дать какие-то бенчи такого применения? просто очень интересно, на сколько связка ion + SOHO nas рулит в качестве веб-сервера :)))
        0
        вообще конечно интересно, в принципе там линух и можно и svn поднять с авторизацией и багтреккер мантис например, интересует производительность? а так за 150+50 баксов получить «сервер» для нескольких разработчиков… очень интересно, правда.
          0
          а для чего они там еще? :)
          производительность не мерил — могу сказать, что при 100К строк в таблице сервачок начинает слегка подтормаживать…
          скажите — что вам интересно, если смогу — померяю.

          хотел туда еще MySQL5 поставить, но что-то стремно как-то стало — работает и так, хотя сидишь без триггеров и процедур.

          кстати, вся установка ведется через telnet
            0
            ну официально они там для создания хоумпага (блога) который видно в инет, также подозреваю что сам интерфейс на пыхе написан ;)
            Относительно обновления — не знаю как 101, но например для 107 регулярно выходят обновления прошивки и новыми версиями пыха и мускуля.
              0
              Официально там есть пхп и мускуль — стало быть, можно девелопить! :)
              101 уже даже с официального сайта снят.
                0
                107 тоже снят но обновления идут… оффтоп, интересно а если несколько таких (ну я 107 или более новые имею в виду :)) поставить в мастер-слейв, там гигабитная сетка и судя по тестам они весьма шустрые… очень эффективное использование пространства будет наверное… а 207+ можно и в райд поставить :)
                  0
                  Не делайте так — они поработят всю планету! Они!
        +1
        Спасибо, в закладки. До этого крашились MYISAM, а это достаточно просто и не так проблемно, но очень неприятно!

        По поводу вопроса присоединюсь к первому комментарию, ведь Mysql именно на самом NAS, почему так, можете рассказать?
          +1
          Всегда пожалуйста!

          Я вас слегка не понял — почему как??? :)
            +1
            Судя по посту понял что у вас Mysql крутится тоже на NAS, поправьте если ошибся.

            Но для Mysql обычно важен CPU и память, а там все же специализированная железка «для хранилища» немного не то по всем этим показателям… поэтому и вопрос почему сделали именно на ней?
              +1
              Да, все правильно.
              Это было сделано — для единства данных. Без этого было бы и файлы и БД разные, а так — файлы по SVN, БД — едина.

              Есть конечно, и минус в этом — допустим, я добавил на сайт новость с картинкой — новость добавится у всех, а картинку придется закачивать-скачивать по SVN.

              А насчет CPU и памяти — в основном, мы разрабатываем веб-проекты с нуля — там большой БД не надо, поэтому она и не тормозит. А вот когда надо было перелопачивать каждый раз при обращении к странице 5 таблиц по 100К (не наш проект, мы только на свой движок перенесли) — тормоза были.

        Only users with full accounts can post comments. Log in, please.