MySQL Запуск восстановления после сбоя

Я искал решение этой проблемы повсюду. Мой MySql дает мне следующие показания:

121231 20:41:05 [Note] Plugin 'FEDERATED' is disabled.
121231 20:41:05 InnoDB: The InnoDB memory heap is disabled
121231 20:41:05 InnoDB: Mutexes and rw_locks use Windows interlocked functions
121231 20:41:05 InnoDB: Compressed tables use zlib 1.2.3
121231 20:41:05 InnoDB: Initializing buffer pool, size = 512.0M
121231 20:41:05 InnoDB: Completed initialization of buffer pool
121231 20:41:05 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
121231 20:41:05  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...
121231 20:41:06  InnoDB: Waiting for the background threads to start
121231 20:41:07 InnoDB: 1.1.8 started; log sequence number 124716458
121231 20:41:07 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
121231 20:41:07 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
121231 20:41:07 [Note] Server socket created on IP: '0.0.0.0'.
121231 20:41:09 [Note] Event Scheduler: Loaded 0 events
121231 20:41:09 [Note] c:\xampp\mysql\bin\mysqld.exe: ready for connections.
Version: '5.5.27'  socket: ''  port: 3306  MySQL Community Server (GPL)

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

Это делает меня неудобным, потому что я не уверен, что что-то может быть повреждено или повреждено. Я использую Windows Vista и Xampp, но я также использовал nginX, показывающий то же самое.

Я только что воссоздал совершенно новую базу данных, и теперь после выключения (что мне иногда приходится делать) ошибка снова появляется! Это нормально или что-то не так?

Спасибо


mysql crash recovery
person qrs    schedule 01.01.2013    source источник
comment
В чем я думаю может быть проблема. предоставьте MySql доступ к брандмауэру, это исправит, вы должны разрешить запуск сервера MySQL (mysqld.exe) и разрешить доступ к порту 3306. Затем попробуйте уменьшить размер innodb_buffer_pool_size в файле my.ini. Установите его на 1G и проверьте, позволит ли это запустить службу.   -  person Arun Killu    schedule 01.01.2013
comment
Спасибо. Он начинается нормально. Проблем с запуском нет. Он имеет доступ через брандмауэр компьютеров, но не через брандмауэр маршрутизаторов. Я имею в виду, что он работает отлично. На самом деле я попытался разрешить доступ через брандмауэр маршрутизатора и проверить его с помощью средства проверки портов.   -  person qrs    schedule 01.01.2013
comment
попробуйте удалить файл журнала, после остановки сервера перезапустите сервер   -  person Arun Killu    schedule 01.01.2013
comment
Я делал это много раз! Извините, но вы когда-нибудь работали с базой данных MySQL!? Я ищу экспертного совета. Просто шутка. :)   -  person qrs    schedule 01.01.2013
comment
Вы решили это? Я вижу эти журналы на моем рабочем сервере mysql на RedHat5, и мне становится не по себе.   -  person dlite922    schedule 01.07.2013

Ответы (1)


arrow_upward
2
arrow_downward

Как видно из лога, InnoDB запускает аварийное восстановление:

InnoDB: Starting crash recovery.

Причина этого в том, что закрытие MySQL не было чистым. Почему? Возможно, MySQL слишком долго завершает работу, и ОС убивает процесс (если вы перезагрузите сервер). Или MySQL падает из-за ошибки.

person akuzminsky    schedule 10.02.2014