mysql не стартует из-за ошибок в базе

[drag0mir]

Вопрос больше по части mysql конечно, но тем не менее,
mysql не стартует, а при старте сыпятся ошибки типа:

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

Jan 22 11:00:11 lt mysqld_safe[12478]: started
Jan 22 11:00:11 lt mysqld[12482]: 110122 11:00:11  InnoDB: Database was not shut down normally!
Jan 22 11:00:11 lt mysqld[12482]: InnoDB: Starting crash recovery.
Jan 22 11:00:11 lt mysqld[12482]: InnoDB: Reading tablespace information from the .ibd files...
Jan 22 11:00:11 lt mysqld[12482]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jan 22 11:00:11 lt mysqld[12482]: InnoDB: buffer...
Jan 22 11:00:11 lt mysqld[12482]: 110122 11:00:11  InnoDB: Starting log scan based on checkpoint at
Jan 22 11:00:11 lt mysqld[12482]: InnoDB: log sequence number 254 2518577586.
Jan 22 11:00:12 lt named[4507]: client 188.128.1.98#43285: query (cache) '90056-b7208518/A/IN' denied
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: Doing recovery: scanned up to log sequence number 254 2523587322
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: 1 transaction(s) which must be rolled back or cleaned up
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: in total 4 row operations to undo
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: Trx id counter is 0 979812096
Jan 22 11:00:12 lt mysqld[12482]: 110122 11:00:12  InnoDB: Starting an apply batch of log records to the database...
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: Progress in percents: 0 1 2 3 4 5 InnoDB: ERROR: Submit the output to http://bugs.mysql.com
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: ibuf cursor restoration fails!
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: ibuf record inserted to page 10303017
Jan 22 11:00:12 lt mysqld[12482]: PHYSICAL RECORD: n_fields 6; 1-byte offsets; info bits 0
Jan 22 11:00:12 lt mysqld[12482]:  0: len 4; hex 00000000; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 009d3629; asc   6);; 3: len 13; hex 00860300040000860300048000; asc              ;; 4: len 4; hex 80000e72; asc    r;; 5: len 4; hex 9c764a58; asc  vJX;;
Jan 22 11:00:12 lt mysqld[12482]: PHYSICAL RECORD: n_fields 6; 1-byte offsets; info bits 0
Jan 22 11:00:12 lt mysqld[12482]:  0: len 4; hex 00000000; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 009d3629; asc   6);; 3: len 13; hex 00860300040000860300048000; asc              ;; 4: len 4; hex 80000e72; asc    r;; 5: len 4; hex 9c764a58; asc  vJX;;
Jan 22 11:00:12 lt mysqld[12482]: DATA TUPLE: 3 fields;
Jan 22 11:00:12 lt mysqld[12482]:  0: len 4; hex 00000000; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 009d3629; asc   6);;
Jan 22 11:00:12 lt mysqld[12482]: PHYSICAL RECORD: n_fields 6; 1-byte offsets; info bits 0
Jan 22 11:00:12 lt mysqld[12482]:  0: len 4; hex 00000000; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 009d3629; asc   6);; 3: len 13; hex 00860300040000860300048000; asc              ;; 4: len 4; hex 80000e72; asc    r;; 5: len 4; hex 9c777dcd; asc  w} ;;
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: Validating insert buffer tree:
Jan 22 11:00:12 lt mysqld[12482]: 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 InnoDB: Records in wrong order on page 322007index CLUST_IND of table SYS_IBUF_TABLE_0
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: previous record PHYSICAL RECORD: n_fields 6; 1-byte offsets; info bits 0
Jan 22 11:00:12 lt mysqld[12482]:  0: len 4; hex 00000000; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 009d362b; asc   6+;; 3: len 13; hex 00860300040000860300048000; asc              ;; 4: len 4; hex 80000a77; asc    w;; 5: len 4; hex 9c720c5e; asc  r ^;;
Jan 22 11:00:12 lt mysqld[12482]:
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: record PHYSICAL RECORD: n_fields 6; 1-byte offsets; info bits 0
Jan 22 11:00:12 lt mysqld[12482]:  0: len 4; hex 00000000; asc     ;; 1: len 1; hex 00; asc  ;; 2: len 4; hex 009d3629; asc   6);; 3: len 13; hex 00860300040000860300048000; asc              ;; 4: len 4; hex 80000e72; asc    r;; 5: len 4; hex 9c714571; asc  qEq;;
Jan 22 11:00:12 lt mysqld[12482]:
Jan 22 11:00:12 lt mysqld[12482]: InnoDB: Apparent corruption in page 322007 in index CLUST_IND of table SYS_IBUF_TABLE_0
Jan 22 11:00:12 lt mysqld[12482]: 110122 11:00:12  InnoDB: Page dump in ascii and hex (16384 bytes):

далее куча всякой фигни еще
и в конце:

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

Jan 22 11:00:13 lt mysqld[12482]: 110122 11:00:13  InnoDB: Page checksum 2439518664, prior-to-4.0.14-form checksum 3748383345
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: stored checksum 2439518664, prior-to-4.0.14-form stored checksum 3748383345
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: Page lsn 254 2522608615, low 4 bytes of lsn at page end 2522608615
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: Page number (if stored to page already) 1355194,
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: Page may be an index page where index id is 4294967295 0
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: (index CLUST_IND of table SYS_IBUF_TABLE_0)
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: Error in page 1355194 of index CLUST_IND of table SYS_IBUF_TABLE_0
Jan 22 11:00:13 lt mysqld[12482]: 110122 11:00:13InnoDB: Assertion failure in thread 2716576656 in file ibuf0ibuf.c line 2967
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: We intentionally generate a memory trap.
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: If you get repeated assertion failures or crashes, even
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: immediately after the mysqld startup, there may be
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jan 22 11:00:13 lt mysqld[12482]: InnoDB: about forcing recovery.
Jan 22 11:00:13 lt mysqld[12482]: 110122 11:00:13 - mysqld got signal 11;
Jan 22 11:00:13 lt mysqld[12482]: This could be because you hit a bug. It is also possible that this binary
Jan 22 11:00:13 lt mysqld[12482]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 22 11:00:13 lt mysqld[12482]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 22 11:00:13 lt mysqld[12482]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 22 11:00:13 lt mysqld[12482]: the problem, but since we have already crashed, something is definitely wrong
Jan 22 11:00:13 lt mysqld[12482]: and this may fail.
Jan 22 11:00:13 lt mysqld[12482]:
Jan 22 11:00:13 lt mysqld[12482]: key_buffer_size=0
Jan 22 11:00:13 lt mysqld[12482]: read_buffer_size=67104768
Jan 22 11:00:13 lt mysqld[12482]: max_used_connections=0
Jan 22 11:00:13 lt mysqld[12482]: max_connections=100
Jan 22 11:00:13 lt mysqld[12482]: threads_connected=0
Jan 22 11:00:13 lt mysqld[12482]: It is possible that mysqld could use up to
Jan 22 11:00:13 lt mysqld[12482]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3407471 K
Jan 22 11:00:13 lt mysqld[12482]: bytes of memory
Jan 22 11:00:13 lt mysqld[12482]: Hope that's ok; if not, decrease some variables in the equation.
Jan 22 11:00:13 lt mysqld[12482]:
Jan 22 11:00:13 lt mysqld[12482]: thd=(nil)
Jan 22 11:00:13 lt mysqld[12482]: Attempting backtrace. You can use the following information to find out
Jan 22 11:00:13 lt mysqld[12482]: where mysqld died. If you see no messages after this, something went
Jan 22 11:00:13 lt mysqld[12482]: terribly wrong...
Jan 22 11:00:13 lt mysqld[12482]: Cannot determine thread, fp=0xa1eb99e8, backtrace may not be correct.
Jan 22 11:00:13 lt mysqld[12482]: Stack range sanity check OK, backtrace follows:
Jan 22 11:00:13 lt mysqld[12482]: 0x81ea513
Jan 22 11:00:13 lt mysqld[12482]: 0x8344906
Jan 22 11:00:13 lt mysqld[12482]: 0x83461aa
Jan 22 11:00:13 lt mysqld[12482]: 0x83b1a0b
Jan 22 11:00:13 lt mysqld[12482]: 0x83dbcfb
Jan 22 11:00:13 lt mysqld[12482]: 0x83245e8
Jan 22 11:00:13 lt mysqld[12482]: 0xb7ecd4fb
Jan 22 11:00:13 lt mysqld[12482]: 0xb7ce1e5e
Jan 22 11:00:13 lt mysqld[12482]: New value of fp=(nil) failed sanity check, terminating stack trace!
Jan 22 11:00:13 lt mysqld[12482]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
Jan 22 11:00:13 lt mysqld[12482]: stack trace is much more helpful in diagnosing the problem, so please do
Jan 22 11:00:13 lt mysqld[12482]: resolve it
Jan 22 11:00:13 lt mysqld[12482]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains
Jan 22 11:00:13 lt mysqld[12482]: information that should help you find out what is causing the crash.

запустил мускул с
[mysqld]
innodb_force_recovery = 4

стартанул, но есть проблемы

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

Jan 22 11:00:39 lt mysqld_safe[12715]: started
Jan 22 11:00:39 lt mysqld[12719]: 110122 11:00:39  InnoDB: Database was not shut down normally!
Jan 22 11:00:39 lt mysqld[12719]: InnoDB: Starting crash recovery.
Jan 22 11:00:39 lt mysqld[12719]: InnoDB: Reading tablespace information from the .ibd files...
Jan 22 11:00:39 lt mysqld[12719]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jan 22 11:00:39 lt mysqld[12719]: InnoDB: buffer...
Jan 22 11:00:39 lt mysqld[12719]: 110122 11:00:39  InnoDB: Starting log scan based on checkpoint at
Jan 22 11:00:39 lt mysqld[12719]: InnoDB: log sequence number 254 2518577586.
Jan 22 11:00:40 lt mysqld[12719]: InnoDB: Doing recovery: scanned up to log sequence number 254 2523587322
Jan 22 11:00:40 lt mysqld[12719]: InnoDB: 1 transaction(s) which must be rolled back or cleaned up
Jan 22 11:00:40 lt mysqld[12719]: InnoDB: in total 4 row operations to undo
Jan 22 11:00:40 lt mysqld[12719]: InnoDB: Trx id counter is 0 979812096
Jan 22 11:00:40 lt mysqld[12719]: 110122 11:00:40  InnoDB: Starting an apply batch of log records to the database...
Jan 22 11:00:46 lt mysqld[12719]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Jan 22 11:00:46 lt mysqld[12719]: InnoDB: Apply batch completed
Jan 22 11:00:46 lt mysqld[12719]: InnoDB: Last MySQL binlog file position 0 4280554, file name /var/log/mysql/mysql-bin.003027
Jan 22 11:00:46 lt mysqld[12719]: 110122 11:00:46  InnoDB: Started; log sequence number 254 2523587322
Jan 22 11:00:46 lt mysqld[12719]: InnoDB: !!! innodb_force_recovery is set to 4 !!!
Jan 22 11:00:46 lt mysqld[12719]: 110122 11:00:46 [Note] /usr/sbin/mysqld: ready for connections.
Jan 22 11:00:46 lt mysqld[12719]: Version: '5.0.38-Ubuntu_0ubuntu1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Ubuntu 7.04 distribution
Jan 22 11:00:46 lt /etc/mysql/debian-start[12814]: Upgrading MySQL tables if necessary.
Jan 22 11:00:49 lt /etc/mysql/debian-start[12823]: Checking for crashed MySQL tables.
Jan 22 11:01:03 lt mysqld[12719]: Error: index `dhs_last_update_date_status_idx` of table `UTM5/dhs_sessions_log` contains 561252 entries, should be 561291

соответственно говорит что в индексах проблема в таблице dhs_sessions_log
но удалить их нельзя

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

mysql> show index from dhs_sessions_log;
+------------------+------------+---------------------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table            | Non_unique | Key_name                        | Seq_in_index | Column_name      | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+------------------+------------+---------------------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+
| dhs_sessions_log |          0 | PRIMARY                         |            1 | id               | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
| dhs_sessions_log |          1 | dhs_last_update_date_status_idx |            1 | last_update_date | A         |        NULL |     NULL | NULL   | YES  | BTREE      |         |
| dhs_sessions_log |          1 | dhs_last_update_date_status_idx |            2 | Acct_Status_Type | A         |        NULL |     NULL | NULL   | YES  | BTREE      |         |
+------------------+------------+---------------------------------+--------------+------------------+-----------+-------------+----------+--------+------+------------+---------+
3 rows in set (0.00 sec)
mysql> ALTER TABLE dhs_sessions_log DROP INDEX dhs_last_update_date_status_idx;
ERROR 1030 (HY000): Got error -1 from storage engine

так как стоит innodb_force_recovery = 4

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

Jan 22 11:03:17 lt mysqld[12719]: InnoDB: A new raw disk partition was initialized or
Jan 22 11:03:17 lt mysqld[12719]: InnoDB: innodb_force_recovery is on: we do not allow
Jan 22 11:03:17 lt mysqld[12719]: InnoDB: database modifications by the user. Shut down
Jan 22 11:03:17 lt mysqld[12719]: InnoDB: mysqld and edit my.cnf so that newraw is replaced
Jan 22 11:03:17 lt mysqld[12719]: InnoDB: with raw, and innodb_force_... is removed.

подскажите куда копнуть плиз?
как поправить индексы?

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

# mysqlcheck UTM5 dhs_sessions_log
UTM5.dhs_sessions_log
error    : Corrupt

# mysqlcheck -r UTM5 dhs_sessions_log
UTM5.dhs_sessions_log
note     : The storage engine for the table doesn't support repair

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

mysql> SELECT * FROM dhs_sessions_log INTO OUTFILE '/DB/dhs_sessions_log.sql';
ERROR 1034 (HY000): Incorrect key file for table 'dhs_sessions_log'; try to repair it

[littlesavage]

Вопрос больше по части mysql конечно, но тем не менее,
mysql не стартует, а при старте сыпятся ошибки типа:
Jan 22 11:00:13 lt mysqld[12482]:
Jan 22 11:00:13 lt mysqld[12482]: key_buffer_size=0
Jan 22 11:00:13 lt mysqld[12482]: read_buffer_size=67104768
Jan 22 11:00:13 lt mysqld[12482]: max_used_connections=0
Jan 22 11:00:13 lt mysqld[12482]: max_connections=100
Jan 22 11:00:13 lt mysqld[12482]: threads_connected=0
Jan 22 11:00:13 lt mysqld[12482]: It is possible that mysqld could use up to
Jan 22 11:00:13 lt mysqld[12482]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3407471 K
Jan 22 11:00:13 lt mysqld[12482]: bytes of memory
Jan 22 11:00:13 lt mysqld[12482]: Hope that's ok; if not, decrease some variables in the equation.
[/code]

Для начала, убрать весь тюнинг mysql'я.
Если не поможет, с innodb_force_recovery = 4 сдампить все базы, поставить 0, пересоздать innodb пул и залить базы обратно.

А после чего такое началось? Не после смены innodb_log_file_size / innodb_buffer_pool_size?

[drag0mir]

тюнинг убрал не помогло

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

110122 13:07:15  InnoDB: Page checksum 2439518664, prior-to-4.0.14-form checksum 3748383345
InnoDB: stored checksum 2439518664, prior-to-4.0.14-form stored checksum 3748383345
InnoDB: Page lsn 254 2522608615, low 4 bytes of lsn at page end 2522608615
InnoDB: Page number (if stored to page already) 1355194,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 4294967295 0
InnoDB: (index CLUST_IND of table SYS_IBUF_TABLE_0)
InnoDB: Error in page 1355194 of index CLUST_IND of table SYS_IBUF_TABLE_0
110122 13:07:15InnoDB: Assertion failure in thread 2987125648 in file ibuf0ibuf.c line 2967
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
110122 13:07:15 - mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=0
read_buffer_size=131072
max_used_connections=0
max_connections=100
threads_connected=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb20bd9e8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x81ea513
0x8344906
0x83461aa
0x83b1a0b
0x83dbcfb
0x83245e8
0xb7ea44fb
0xb7cb8e5e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

а с innodb_force_recovery = 4
сдампить не получается

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

# mysqldump UTM5 > /DB/utm5.sql
mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `access_log`': Incorrect key file for table 'access_log'; try to repair it (1034)

началось само по себе, ничего не менял.
просто вчера рухнуло всё, не понятны причины.
выручайте народ, буду сильно признателен, живая система, клиентов около 1000

[kamae1ka]

Перед проверкой и восстановлением таблиц при работающем сервере «mysqld» следует обновить «кеш-память» таблиц командой

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

«mysqladmin flush-tables»

Проверять и восстанавливать MyISAM таблицы можно с помощью утилиты «myisamchk», а также можно использовать операторы CHECK и REPAIR.

Синтаксис «myisamchk» можно посмотреть командой: «myisamchk --help | less » вкратце это выглядит так:

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

shell#>myisamchk  [список_опций]  [имя_таблицы] ...

Проверка таблиц на наличие ошибок.
В качестве [имя_таблицы] может выступать, как и имя проверяемой таблицы, так и имя файла её индекса. Для определения сразу нескольких таблиц определенного каталога можно воспользоваться следующим синтаксисом:

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

shell#> myisamchk  список_опций_проверки  *.MYI

Где «список_опций_проверки»:
-c | --check обычная проверка (по умолчанию)
-e | --extend-check более тщательная проверка
-m | --medium-check детальная проверка (самая долгая)

Можно проверить все таблицы во всех базах данных, если задать шаблон вместе с путем к каталогу данных MySQL:

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

shell#> myisamchk  /path/to/datadir/*/*.MYI

Исправление таблиц содержащих ошибки.
Для исправления ошибок можно пользоваться следующими командами:

восстановление без модификации файла данных (.MYD);

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

shell> myisamchk  - -quick  [имя_таблицы]

если проблема осталась не решённой то:

может исправить большинство проблем за исключением несовпадения ключей;

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

shell> myisamchk  - -recover  [имя_таблицы]

если проблема осталась не решённой то:

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

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

shell> myisamchk  - -safe-recover  [имя_таблицы]

Восстановление INDEX файла таблицы (*.MYI).

1. перейти в каталог БД, содержащий файлы поврежденной таблицы.
2. скопировать файл данных таблицы (*.MYD) в безопасное место.
3. запустить «mysql» и выполнить следующие команды:

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

     mysql#> use  [имя_БД];
      mysql#> SET  AUTOCOMMIT=1;
      mysql#> TRUNCATE  TABLE  [имя_восстанавливаемой_таблицы];
      mysql#> quit;

4. скопировать файл данных таблицы (*.MYD) обратно в каталог БД.
5. выполнить команду:

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

      shell#> myisamchk  -r  -q  [имя_таблицы]

6. затем после восстановления выполнить операторы:

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

      mysql#> use  [имя_БД];
      mysql#> FLUSH  TABLE [имя_таблицы];
      mysql#> quit;

Или перезапустить демон "mysqld".

разбор пункта #3,6.
Оператор «use [имя_БД]» - делает активной БД [имя_БД].
Оператор «SET AUTOCOMMIT=1» - команда не обязательная (её можно упустить), устанавливает значение переменной «AUTOCOMMIT» равным единице (*6*).
Оператор «TRUNCATE TABLE» - опустошает полностью таблицу. Этот оператор похож на «DELETE», который удаляет все строки в таблице.

Оператор «FLUSH TABLE» принудительно закрывает открытую таблицу, также сбрасывается кэш запросов. Для принудительного закрытия всех таблиц можно использовать оператор «FLUSH TABLES».

разбор пункта #5
«myisamchk -r -q [имя_таблицы]» запускает быстрое восстановление таблицы («-q» ключ означает быстрое восстановление, при этом исправляются только файл индексов, а файл данных не изменяется)
Восстановление файла описания таблицы (*.frm).
Чтобы воcсоздать файл описаний таблицы, его можно восстановить из архива (если архив создавался), или заново с помощью оператора «CREATE TABLE».

1. скопировать файл данных таблицы (*.MYD) в безопасное место
2. восстанавливаем файл из архива или заново создать таблицу с помощью оператора «СREATE TABLE»
3. снова запускам процедуру восстановления «myisamchk -r -q [имя_таблицы]»


Работа с блокировками таблиц во время ремонта.
Сервер MySQL использует два вида блокировок:

1. внутренняя блокировка
2. внешняя блокировка (на уровне файловой системы)

1-я применяется чтобы избежать взаимного влияния запросов клиентов (пример: не позволяет «SELECT» одного клиента выдать не правильные данные из-за одновременной запроса «UPDATE» другого клиента).
2-я не позволяет внешним программам изменять файлы таблиц, пока с ними работает сервер «mysqld».

От того включена ли внешняя блокировка будет зависеть, как запускать утилиту «myisamchk» (если нельзя включить (2) то нужно использовать (1)). Просмотреть состояние внешней блокировки можно с помощью команды «SHOW VARIABLES» переменная «skip_external_locking» или «skip_locking» будет содержать значение «ON» или «OFF». Значение «ON» означает, что внешняя блокировка отключена, значение «OFF» наоборот. Для того чтобы изменить значение переменной «skip_external_locking» нужно запустить сервер «mysqld» с соответствующей опцией (по умолчанию во FreeBSD 5.2 значение «ON»).

Если значение «skip_external_locking» равно «ON» (внешняя блокировка отключена) то для выполнения проверки или восстановления с помощью утилиты «myisamchk» лучше приостановить работу сервера «mysqld» или воспользоваться внутренним механизмом блокировки (закрыть на время доступ к проверяемым таблицам с помощью «mysql» команды «LOCK TABLES»). Для того чтобы воспользоваться внутренним механизмом блокировки для команды «myisamchk» следует:

1. запустить «mysql» и выполнить команду «LOCK TABLES» для нужной (исправляемой) таблицы
2. не завершая работы «mysql» запустить утилиту «myisamchk» с нужными опциями проверки/исправления
3. по окончанию работы утилиты «myisamchk» нужно вернуться к сессии «mysql» выполнить команду «FLUSH TABLES» и снять блокировку «UNLOCK TABLES»

Механизм блокировки может отличаться в зависимости от режима работы утилиты ясно, что если утилита »myisamchk» запущена только в режиме проверки данных то клиентам можно оставить право на чтения таблицы но, а если утилита будет восстанавливать таблицу то клиентам нужно запретить что либо изменять в таблице.
использовать механизм блокировки «LOCK» лучше в следующей последовательности:

1. «LOCK TABLE [имя_таблицы] [READ | WRITE]». Если установлено «READ» для некоторой таблицы, то только этот поток (и все другие потоки) могут читать из данной таблицы. Если для некоторой таблицы установлена блокировка «WRITE», тогда только этот поток, содержащий блокировку, может осуществлять операции чтения «READ» и записи «WRITE» заблокированной таблицей. Остальные потоки блокируются. То есть простыми словами если нам нужно просто проверить таблицу, то устанавливаем блокировку «READ», но а если исправить, то устанавливаем «WRITE».
2. после того, как закончили проверку/ремонт таблицы, выполняем команду «FLUSH TABLES» для того чтобы сбросить кэш таблиц.
3. выполнить команду «UNLOCK TABLES» когда нужно будет снять блокировку.

полная статья - http://www.opennet.ru/docs/RUS/mysql_notes/

[drag0mir]

всем большое спасибо кто откликнулся. вся база в InnoDB.
во всех таблицах похерились индексы каким то образом,
даже выборка не делалась.
В итоге откатился на 2 дня назад. текущую базу восстановить не удалось.

[JAO]

В свое время успешно сдампил битую базу с innodb_force_recovery=1. Видимо зависит от характера повреждений в базе.