|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день!
Сегодня начал падать mysql, в логах ошибка:
131223 0:09:41 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: Log scan progressed past the checkpoint lsn 174 3187403662
131223 0:09:55 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 174 3192646144
InnoDB: Doing recovery: scanned up to log sequence number 174 3197889024
InnoDB: Doing recovery: scanned up to log sequence number 174 3203131904
InnoDB: Doing recovery: scanned up to log sequence number 174 3208374784
InnoDB: Doing recovery: scanned up to log sequence number 174 3213617664
InnoDB: Doing recovery: scanned up to log sequence number 174 3218860544
InnoDB: Doing recovery: scanned up to log sequence number 174 3224103424
InnoDB: Doing recovery: scanned up to log sequence number 174 3229346304
InnoDB: Doing recovery: scanned up to log sequence number 174 3234589184
InnoDB: Doing recovery: scanned up to log sequence number 174 3239832064
InnoDB: Doing recovery: scanned up to log sequence number 174 3245074944
InnoDB: Doing recovery: scanned up to log sequence number 174 3250317824
InnoDB: Doing recovery: scanned up to log sequence number 174 3255560704
InnoDB: Doing recovery: scanned up to log sequence number 174 3260803584
InnoDB: Doing recovery: scanned up to log sequence number 174 3266046464
InnoDB: Doing recovery: scanned up to log sequence number 174 3271289344
InnoDB: Doing recovery: scanned up to log sequence number 174 3272728947
131223 0:10:17 InnoDB: Starting an apply batch of log records to the database...
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
InnoDB: Apply batch completed
131223 0:11:24 InnoDB: Started; log sequence number 174 3272728947
131223 0:11:24 [Note] Event Scheduler: Loaded 0 events
131223 0:11:24 [Note] C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld: ready for connections.
Version: '5.1.41-community' socket: '' port: 3306 MySQL Community Server (GPL)
131223 0:13:29 InnoDB: Operating system error number 665 in a file operation.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/ … codes.html
InnoDB: File name .\ibdata1
InnoDB: File operation call: 'Windows aio'.
InnoDB: Cannot continue operation.
Сервис стартует, но стоит запустить приложения(например, apache), работающие с базой, sql падает.
Подскажите пожалуйста, может кто знает, в чем причина???
Буду крайне благодарен за помощь!!!
В гугле нашел что то про дефрагментацию диска, в частности файла ibdata
Система Windows server 2008 r2, lsi-9260-4i, 4x300 sas 15k raid10
Виндовый дефрагментатор показывает фрагментацию 4%, сторонний Auslogics DiskDefrag показывает 88%
Вот как то так....
Неактивен
Это какая-то виндовая ошибка файловой системы (можно считать багой винды). Попробуйте разные варианты:
1) проверьте наличие свободного места на диске
2) если на диске включено сжатие, отключите
3) остановите mysql, сделайте бэкап всех файлов базы, затем переименуйте файл в ibdata1.old, а затем скопируйте его в ibdata1 (это сделает файл дефрагментированным)
Неактивен
1) занято 427gb, свободно 129gb
2) сжатие отключено
3) backup невозможен, ibdata1 389gb
Неактивен
А к утру нужно сервис запустить.....(((
Backup будет длиться оооочень долго!
Склоняюсь к теме фрагментации файла ibdata1 в файловой системе ntfs.
Может попробовать выполнить дефрагментацию файла, не смотря что он находиться на raid 10 ???
Неактивен
Цитата от майкрософт:
Эта проблема возникает, так как в файловой системе NT (NTFS) Достигнуто максимальное количество экстентов. При достижении этого ограничения NTFS возвращает сообщение об ошибке STATUS_FILE_SYSTEM_LIMITATION .
Примечание Экстент — это набор последовательных кластеров на томе. NTFS может выделять много экстентов для хранения больших файлов. Все сведения о степени сохраняются в файл записи в основной таблицы файлов (MFT). При записи файла слишком мал, NTFS выделяет записи вторичный файл для хранения сведений о степени. Тем не менее NTFS имеет ограниченное число экстентов для файла. Это ограничение определяется максимальное число записей вторичный файл из файла. Номер максимальной степени достигается, когда запись дополнительных вторичный файл не может быть выделен для хранения сведений о степени.
Неактивен
Попробуйте дефрагментацию, да.
Без бэкапа, кстати, жить нельзя вообще. Продумайте это. RAID и Innodb не защита сохранности данных.
Неактивен
Да, опыт восстановления базы -force recovery 6 уже есть! Неблагодарное занятие.....
В ближайшее время думаю настроить репликацию, и бекапы со слейв сервер...
Неактивен
Для дефрагментации не имеет значения находится от на RAID или нет. RAID это физический уровень, а дефрагментация выполняется на логическом уровне. На последнем уровне не важно где и как записана информация, важно только ее расположение по логическим адресам.
Вообще, если такая проблема есть - это плохо. Она будет появляться снова. Решение - отказ от видны или использование раздела диска без файловой системы: http://dev.mysql.com/doc/refman/5.0/en/ … vices.html
Неактивен
Стоит обратить внимание также на утилиту Percona Xtrabackup, которая позволяет бэкапить с мастера без остановки работы:
http://www.percona.com/doc/percona-xtrabackup/2.1/
Она пригодится и для создание слейва.
Неактивен
Спасибо, непременно изучу!
Дефрагментация при помощи Auslogics DiskDefrag, не действует на ibdata1
Штатный показывает фрагментацию всего 3%
Еще накапал http://support.microsoft.com/kb/957065
Предлагают установить обновление, которое полностью не протестировано, мда, рисковано.
Неактивен
Утилита MegaRAID Storage Manager пишет, что с массивом все в порядке.
Неактивен
С RAID все в порядке - это не удивительно, так как проблема именно логическая - видноус не справляется с управлением файлами. Еще есть вариант - вставить чистый хард вне RAID и на него скопировать ibdata1.
Неактивен
rgbeast написал:
С RAID все в порядке - это не удивительно, так как проблема именно логическая - видноус не справляется с управлением файлами. Еще есть вариант - вставить чистый хард вне RAID и на него скопировать ibdata1.
А потом затереть оригинал, и скопировать обратно, правильно понимаю?
Неактивен
Я имел в виду запустить mysqld с файлом ibdata1 на другом диске - может быть на нем файловая система будет себя вести иначе. Скопировать назад - эквивалентно дефрагментации, можно тоже попробовать. Не забудьте, что копирование файлов только при остановленном mysqld.
Неактивен
Про остановку mysql в курсе, но последний раз при копирование глюканул контроллер, и получил два поврежденных ibdata1, неделька ушла на бекап-рестор.
К сожалению заплатка на windows оказалась пригодной только для Vista. Странно, что майкрософт признает проблему, но не предлагает решения. Все больше склонюсь к переходу на debian, один из сервисов уже успешно на нем работает.
В линуксе я с подобной проблемой не столкнусь, правильно?
Неактивен
Этой проблемы точно не будет, так как проблема именно NTFS. Каких-то аналогичных проблем (какие-либо ограничения файловой системы ext4) я не встречал.
Неактивен
Скопировал ibdata1 ib_logfile0 и 1 на ЖД не в рейде.
Перенастроил my.ini
Работает!
Дефрагментатор показывает 800 тыс. фрагментов, в новом ibdata
Сейчас заменю исходную ibdata1, на скопированную, посмотрю, что из этого выйдет.
Отредактированно marrt (23.12.2013 14:16:11)
Неактивен
Все работает!
Решение скопировать ibdata1 на другой диск, затем обратно с удалением исходного ibdata1. Может кому пригодится!
Спасибо rgbeast за помощь и пищу для размышлений!!!
Неактивен
