Мой сервер MySQL аварийно завершил работу из-за (ошибки записи файла подкачки). Я провел диагностику диска, но ошибок не обнаружил. Я перезапустил сервер MySQL. Он просканировал журнал корзины в течение 1-2 часов и записал журнал, как показано ниже:
InnoDB: Doing recovery: scanned up to log sequence number 51 2341175808
InnoDB: Doing recovery: scanned up to log sequence number 51 2346418688
InnoDB: Doing recovery: scanned up to log sequence number 51 2351661568
InnoDB: Doing recovery: scanned up to log sequence number 51 2356904448
InnoDB: Doing recovery: scanned up to log sequence number 51 2362147328
После этого я вижу много ошибок, как показано ниже:
InnoDB: Number of pending reads 128, pending pread calls 0
InnoDB: Error: InnoDB has waited for 50 seconds for pending
InnoDB: reads to the buffer pool to be finished.
InnoDB: Number of pending reads 128, pending pread calls 0
InnoDB: Error: InnoDB has waited for 50 seconds for pending
InnoDB: reads to the buffer pool to be finished.
InnoDB: Number of pending reads 128, pending pread calls 0
InnoDB: Error: InnoDB has waited for 50 seconds for pending
InnoDB: reads to the buffer pool to be finished.
Мне нужно подождать несколько часов, но он просто многократно добавляет эти строки в журнал ошибок без каких-либо признаков остановки.
Что означают вышеуказанные сообщения журнала? Как я могу снова запустить мой сервер MySQL? У меня есть база данных InnoDB объемом 80 ГБ, работающая на этом сервере. Есть ли способ принудительно восстановить его без отмены каких-либо незавершенных транзакций или попытаться восстановить данные из файла подкачки, которые вызвали сбой? У меня нет проблем сбросить эти данные.
Я попробовал "sudo -u mysql / usr / sbin / mysqld –innodb_force_recovery = 6" для перезапуска сервера MySQL, но получил новые повторяющиеся ошибки, как показано ниже:
InnoDB: stored checksum 2440779633, prior-to-4.0.14-form stored checksum 3425185587
InnoDB: Page lsn 51 2450779673, low 4 bytes of lsn at page end 2450779673
InnoDB: Page number (if stored to page already) 10824,
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: Database page corruption on disk or a failed
InnoDB: file read of page 10824.
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 http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
Что мне теперь делать?
Без ошибки, которая вызвала сбой, версии MySQL и вашего my.cnf, трудно определить, в чем именно проблема ... При этом, вот несколько общих советов ...
Вы можете найти таблицу с поврежденной страницей несколькими способами. Самый простой способ выключить сервер и запустить innochecksum против всех таблиц в вашей базе данных. Если он обнаружит какие-либо проблемы, вы можете запустить базу данных в режим восстановления установив innodb_force_recovery и попытайтесь запустить SELECT INTO OUTFILE таблицы, чтобы выгрузить содержимое, затем LOAD DATA FROM INFILE, чтобы загрузить его в новую таблицу. Запустите innodb_force_recovery с 1, и если вы получите сбой при выгрузке таблиц, продолжайте увеличивать значение innodb_force_recovery, пока вы не сможете выгрузить данные без сбоев. Убедитесь, что при этом не подключаются клиенты.
Percona также имеет Инструмент восстановления данных Percona для InnoDB это может свести к минимуму время простоя, но для их использования требуется определенный опыт и может еще больше испортить ситуацию. Кроме того, на самом деле вы жестяная банка запустите innochecksum для активной базы данных, но вы можете получить ложные срабатывания для поврежденных страниц. В этом случае вы можете затем выключить сервер и произвести подсчет только тех таблиц, которые вернули ошибки страницы, пока он был активен. На живом сервере успешная innochecksum будет означать, что таблица в порядке, а неудачная innochecksum может быть неточной.
Когда вы это сделаете, я бы порекомендовал создать подчиненное устройство этой базы данных, чтобы, если это произойдет снова, вы могли легко начать использовать подчиненное устройство и не беспокоиться о сложных процедурах восстановления.
У меня была аналогичная ошибка, и после прочтения https://dba.stackexchange.com/questions/24477/innodb-corruption Решил проверить свою оперативную память. И он был бракованным ...
Я обнаружил, что запущенный memtester без перезагрузки машины, и получил много:
FAILURE: 0x657423ee6593084d != 0x84e423ee6593084d at offset 0x16f17b1a0.
FAILURE: 0x58c620a5a8e4984f != 0x783620a5a8e4984f at offset 0x16f3571a0.
FAILURE: 0x73eba2598aaaa228 != 0x935ba2598aaaa228 at offset 0x16f3db1a0.
Итак, если у вас есть эта ошибка в стабильной версии mysql и перезагрузка устраняет вашу проблему, скорее всего, это проблема с оперативной памятью. Если вы обратите внимание на сообщение об ошибке, оно говорит, что:
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.
Но, возможно, вы, как и я, отказываетесь верить, что это проблема оборудования.