Назад | Перейти на главную страницу

Сервер MySQL аварийно завершает работу, не оставляя никаких журналов

У меня сервер mysql (v5.6), работающий на сервере ubuntu 10 x64. Он всегда работает и работает со средним трафиком, но каждый раз, когда он падает и перезагружается, не оставляя никаких сообщений журнала, после перезапуска он начинает восстановление после сбоя, которое обычно занимает около 10 минут и mysql error.log файл сбрасывается и выглядит следующим образом:

2017-07-27 10:07:37 23427 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
2017-07-27 10:07:37 23427 [Note] Plugin 'FEDERATED' is disabled.
2017-07-27 10:07:37 23427 [Note] InnoDB: Using atomics to ref count buffer pool pages
2017-07-27 10:07:37 23427 [Note] InnoDB: The InnoDB memory heap is disabled
2017-07-27 10:07:37 23427 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-07-27 10:07:37 23427 [Note] InnoDB: Memory barrier is not used
2017-07-27 10:07:37 23427 [Note] InnoDB: Compressed tables use zlib 1.2.8
2017-07-27 10:07:37 23427 [Note] InnoDB: Using Linux native AIO
2017-07-27 10:07:37 23427 [Note] InnoDB: Not using CPU crc32 instructions
2017-07-27 10:07:37 23427 [Note] InnoDB: Initializing buffer pool, size = 5.0G

2017-07-27 10:07:38 23427 [Note] InnoDB: Completed initialization of buffer pool
2017-07-27 10:07:38 23427 [Note] InnoDB: Highest supported file format is Barracuda.
2017-07-27 10:07:38 23427 [Note] InnoDB: Log scan progressed past the checkpoint lsn 194934547118
2017-07-27 10:07:38 23427 [Note] InnoDB: Database was not shutdown normally!
2017-07-27 10:07:38 23427 [Note] InnoDB: Starting crash recovery.
2017-07-27 10:07:38 23427 [Note] InnoDB: Reading tablespace information from the .ibd files...

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

Вполне возможно, что время от времени сервер MySQL становится жертвой нехватки памяти Linux (OOM). убийца обработать. Вы можете найти следы такой активности в /var/log/syslog или в выводе dmesg команда.

Если системе не хватило оперативной памяти и MySQL убил, вы можете изменить настройки процесса сервера MySQL, чтобы избежать этого. Например, используйте MySQLTuner-perl сценарий. Показатели эффективности в его выводе показано максимально возможное использование памяти процессом сервера MySQL в процентах от установленной оперативной памяти.

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

Мне просто не повезло, я обнаружил, что сервер сообщества Mysql (по крайней мере версия 8.x) дает сбой, если местоположение, указанное в настройках в файле my.ini, не работает.

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

Чтобы ответить на ваш вопрос, могу ли я что-нибудь сделать, чтобы сохранить журнал, в котором отображается источник сбоя, чтобы я мог решить проблему.
Да, в вашем .cnf в разделе [mysqld] добавьте новую строку для - expire_logs_days = 7 # по умолчанию 0 mm / dd / ccyy до xx У вас будет 7 дней, доступных для исследования, прежде чем самые старые данные исчезнут. Просмотрите каталог, в котором вы нашли error.log, чтобы увидеть их.