Восстановление таблиц INNDB

[kozak]

После сбоя на сервере был поврежден жесткий диск, на котором размещались файлы таблиц INNODB (Users.ibd, Users.frm и db.opt).

После сбоя накрылся файл Users.ibd. После проверки HDD fsck'м в папке "lost+found" удалось найти Users.ibd, но после его возвращения в "родную" директорию таблица никак не хочет отображаться... Других BACKUP'ов нет... (((

Таблица Users - клиенты компании за последние 6 месяцев.

NEED HELP!!!

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[zg]

на вскидку

Код: Выделить всё

zg# ls /usr/local/bin/ | grep inno
innochecksum
zg#

http://dev.mysql.com/doc/refman/5.0/en/ ... cksum.html

Код: Выделить всё

4.6.1. innochecksum — Offline InnoDB File Checksum Utility
innochecksum prints checksums for InnoDB files.

может чего напишет

[kozak]

Делаем так:

Код: Выделить всё

bash-3.1# innochecksum -d /mnt/mass0/mysql/test/Users.ibd

...
file -d= 9437184 bytes (576 pages)...
checking pages in range 0 to 575
page 0: log sequence number: first = 1575557589; second = 1575557589
page 0: old style: calculated = 2344395615; recorded = 2344395615
page 0: new style: calculated = 1529347311; recorded = 1529347311
page 1: log sequence number: first = 1575560857; second = 1575560857
page 1: old style: calculated = 1583079948; recorded = 1583079948
page 1: new style: calculated = 903018481; recorded = 903018481
page 2: log sequence number: first = 1575557589; second = 1575557589
page 2: old style: calculated = 2172061152; recorded = 2172061152
page 2: new style: calculated = 2385590456; recorded = 2385590456
page 3: log sequence number: first = 1575528218; second = 1575528218
page 3: old style: calculated = 4059698346; recorded = 4059698346
page 3: new style: calculated = 1471387112; recorded = 1471387112
page 4: log sequence number: first = 1575459863; second = 1575459863

...

page 573: old style: calculated = 1371122432; recorded = 0
page 573: new style: calculated = 1575996416; recorded = 0
page 574: log sequence number: first = 0; second = 0
page 574: old style: calculated = 1371122432; recorded = 0
page 574: new style: calculated = 1575996416; recorded = 0
page 575: log sequence number: first = 0; second = 0
page 575: old style: calculated = 1371122432; recorded = 0
page 575: new style: calculated = 1575996416; recorded = 0

record = 0 начался с 83 строчки, причем я проверял рабочие ibd файлы - там тоже recorded = 0 присутствует! ((

Х.З.

[zg]

Innodb по ходу сам может восстанавливаться при старте http://dev.mysql.com/doc/refman/5.0/fr/ ... -0-13.html

Код: Выделить всё

If innodb_force_recovery=6, do not let InnoDB do repair of corrupt pages based on the doublewrite buffer.

Собственно как проявляется ошибка, мускул не стартует или не даёт работать с таблицей?

[kozak]

Стартует, но при первом обращении апача к таблице появляется "Failed to execute_query".

В логах:

Код: Выделить всё

081202 18:26:08081202 18:26:08 [ERROR] Cannot find table database/Users from the internal data dictionary
of InnoDB though the .frm file for the table exists. Maybe you
have deleted and recreated InnoDB data files but have forgotten
to delete the corresponding .frm files of InnoDB tables, or you
have moved .frm files to another database?
See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html
how you can resolve the problem.

[zg]

Стартует

гуд, это хороший признак -)))

Мануал говорит, что надо чекать http://dev.mysql.com/doc/refman/5.1/en/check-table.html

Код: Выделить всё

CHECK TABLE tbl_name [, tbl_name] ... [option] ...

option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

До кучи, вроде как с пятой версии к InnoDB можно также применять и repair http://dev.mysql.com/doc/refman/5.0/en/ ... table.html

Код: Выделить всё

REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE
    tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]

[kozak]

Делаем раз:

Код: Выделить всё

mysql> use privataccess;
Database changed
mysql> show tables;
+------------------------+
| Tables_in_database |
+------------------------+
| CoTypes                |
| Counter                |
| Customers              |
| Dealers                |
| Groups                 |
| Messages               |
| Relations              |
| Sources                |
| Specialities           |
| Users                  |
+------------------------+
10 rows in set (0.00 sec)

Делаем 2:

Код: Выделить всё

mysql> CHECK TABLE Users;
+----------------+-------+----------+------------------------------------------+
| Table              | Op    | Msg_type | Msg_text                                 |
+----------------+-------+----------+------------------------------------------+
| database.Users | check | Error    | Table 'database.Users' doesn't exist |
| database.Users | check | error    | Corrupt                                  |
+----------------+-------+----------+------------------------------------------+
2 rows in set (0.00 sec)

То же самое и для REPAIR TABLE Users;

Сейчас смотрю http://code.google.com/p/innodb-tools/...

[zg]

если получится, отпишись, будем знать куда ткнуть если чё

[Alex Keda]

извините что оффотопик...
вы уже перешли в категорию админов которые "уже делают бэкапы", или наконец серьёзно задумались о переходе в неё?

[zg]

продолжая тему оффтопика - ценные данные никогда не потеряются, теряются только никому ненужные. Как только данные становятся ценными, их бекапят каждый день и не по разу.

Но сама тема восстановления InnoDB в принципе интересная.

[kozak]

Сейчас смотрю http://code.google.com/p/innodb-tools/...

Ну... можно продолжить...

innodb-tools - как на мой взгляд очень мощный и простой инструмент для работы с поврежденными файлами .idb

Все очень просто как 1-2-3.

1. Сначала, на основе существующей поврежденной таблицы автоматически создаем скрипт "table_defs.h" с помощью "create_defs.pl";
2. Затем утилитой "page_parser" разбиваем поврежденный файл .idb на несколько страниц;
3. В дебаг-режиме выполняем "constraints_parser -4|5 -V -f <путь_к_одной_из_страниц_.page>"

Если в дебаг-режиме восстановление проходит успешно и никаких ошибок нет, можно запускать "constraints_parser" без флага "-V" (дебаг) и наблюдать за ходом восстановления вашей таблицы.

Уверен, что что-то пропустил, поэтому ссылаюсь на автора: http://code.google.com/p/innodb-tools/w ... overyHowto.

[zg]

Все очень просто как 1-2-3.

то есть восстановил?

[kozak]

нет

еще работаю над этим...

[kozak]

Все очень просто как 1-2-3.

это на счет innodb-tools...

[zg]

это на счет innodb-tools...

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

[LHC]

Сорри и мне за оффтопик. Я всегда знал, что mysqldump - это круто, а сейчас убедился в этом еще раз.

[zg]

Сорри и мне за оффтопик. Я всегда знал, что mysqldump - это круто, а сейчас убедился в этом еще раз.

дамп круто, но таблицы тоже надо уметь восстанавливать. С майисамом проблем нет, а вот с InnoDB есть и большие.

[Alex Keda]

ф топку иннодб.
отрубаю в my.cnf и больше про них не вспоминаю.

[zg]

ф топку иннодб.

продуктивно

[ProFTP]

ф топку иннодб.
отрубаю в my.cnf и больше про них не вспоминаю.

трансакция?

[Alex Keda]

ф топку.

[ProFTP]

потом будешь спрашиваешь почему не работает или почему деньги не пришли

для форума или cms все равно, но вот для каталога или для продукции какой-то - только DBD или инодб, SQLite по-моиму тоже есть трансакция

там можно разделить СУБД на примари и секондери: сессии и логи в MyISA, а все остальное в DBD

[Alex Keda]

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

[ProFTP]

там бывает таблиц больше 10

елси надо обновить 3 таблицы или 2

ты обновил 1 таблицу и сервак повис, дальше что? получиться ерунда, тебе потом руками надо будет исправлять, а если пользователей штук 10000 ?
или одновременно 1000 сидит


если 1 обновилась, а все остальное нет, то идет откат обратно...

Код: Выделить всё

use strict;
use DBI qw(:sql_types);

my $dbh = DBI->connect( 'dbi:Oracle:orcl',
                        'jeffrey',
                        'jeffspassword',
                        {
                          RaiseError => 1,
                          AutoCommit => 0
                        }
                      ) || die "Database connection not made: $DBI::errstr";

my @records = (
                [ 0, "Larry Wall",      "Perl Author",  "555-0101" ],
                [ 1, "Tim Bunce",       "DBI Author",   "555-0202" ],
                [ 2, "Randal Schwartz", "Guy at Large", "555-0303" ],
                [ 3, "Doug MacEachern", "Apache Man",   "555-0404" ] 
              );

my $sql = qq{ INSERT INTO employees VALUES ( ?, ?, ?, ? ) };
my $sth = $dbh->prepare( $sql );


for( @records ) {
  eval {
    $sth->bind_param( 1, @$_->[0], SQL_INTEGER );
    $sth->bind_param( 2, @$_->[1], SQL_VARCHAR );
    $sth->bind_param( 3, @$_->[2], SQL_VARCHAR );
    $sth->bind_param( 4, @$_->[3], SQL_VARCHAR );
    $sth->execute();
    $dbh->commit();
  };

  if( $@ ) {
    warn "Database error: $DBI::errstr\n";
    $dbh->rollback(); #just die if rollback is failing
  }
}

$sth->finish();
$dbh->disconnect();

Код: Выделить всё

    if ($dd{'mailbox'} $dd{'mailbox'} > 0) {
      my $sth = $dbh->prepare('SELECT mailbox
                         FROM mailbox
                         WHERE domain = ?
                             ');
    $sth->execute($domain);
             $sth->finish();
      my $n=0; my @mailboxs=();
   while ($mailbox_del = $sth->fetchrow_array() ) {
          $mailboxs[$n++]=$mailbox_del;
          }
       
    my $sth = $dbh->prepare('INSERT INTO delete_mailbox
              (domain,mailbox,created)
              VALUES (?,NOW())
                             ');
     
       eval {
       for ($i=0;$i<@mailboxs;$i++)
       {
         $id=$i+1;
          $sth->bind_param($id, $mailboxs[0]);
          $sth->execute();
         }       
       
        $dbh->do("DELETE FROM mailbox
                         WHERE domain = $domain");
       
        $dbh->commit();
                             ');
       if ($@) {
       warn "Transaction aborted $@";
       eval {$dbh->rollback()};
       $sth->finish();
       $dbh->disconnect();
       exit;
       }
     }

     if ($dd{'alias'} && $dd{'alias'} > 0) {
             my $sth = $dbh->prepare('DELETE FROM alias
                         WHERE domain = ?
                             ');
            $sth->execute($domain);
             $sth->finish();
                 }
      }  $dbh->disconnect();     
                

[zg]

покочану и покочерыжке.

жесть аргумент

либо ты обновил таблицу, либо не обновил.

суть транзакций - объединять несколько запросов в один, и если произойдёт коллизия, то сделать откат всех объединённых запросов, во избежание нарушения целостности базы данных. Хотя я думаю, ты и так это знаешь -)))

такие вещщи надо делать проще а не сложней - тогда не надо будет извратов всех этих.

все они дураки, что парятся над иннодб, один ты умный Лис, не обижайся, но всё-таки открой тайну - сколько банковских систем ты написал, для управления многомиллонными счетами? InnoDB - это всё таки дань банковским системам в первую очередь.