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

MySQL продолжает вылетать

Итак, немного предыстории, несколько недель назад я привез новый выделенный сервер CentOS в Мельбурн, однако, похоже, помимо количества злоумышленников, которые я получаю, также есть проблема с базой данных MySQL или используемым программным обеспечением. он продолжает рассыпаться и сохнуть.

Я просмотрел журналы и не вижу причин, по которым он может вылетать, но мне интересно, сможет ли кто-нибудь помочь мне исправить эту проблему.

Последняя часть файла журнала:

 150512 06:15:02 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150512 06:20:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150512  6:20:02 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
150512  6:20:02 [Note] Plugin 'FEDERATED' is disabled.
150512  6:20:02 InnoDB: The InnoDB memory heap is disabled
150512  6:20:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150512  6:20:02 InnoDB: Compressed tables use zlib 1.2.3
150512  6:20:02 InnoDB: Using Linux native AIO
150512  6:20:02 InnoDB: Initializing buffer pool, size = 128.0M
150512  6:20:02 InnoDB: Completed initialization of buffer pool
150512  6:20:02 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!
150512  6:20:02  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...
150512 06:20:02 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150512 06:25:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150512  6:25:02 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
150512  6:25:02 [Note] Plugin 'FEDERATED' is disabled.
150512  6:25:02 InnoDB: The InnoDB memory heap is disabled
150512  6:25:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150512  6:25:02 InnoDB: Compressed tables use zlib 1.2.3
150512  6:25:02 InnoDB: Using Linux native AIO
150512  6:25:02 InnoDB: Initializing buffer pool, size = 128.0M
150512  6:25:02 InnoDB: Completed initialization of buffer pool
150512  6:25:02 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!
150512  6:25:02  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...
150512 06:25:03 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150512 06:30:01 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150512  6:30:01 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
150512  6:30:01 [Note] Plugin 'FEDERATED' is disabled.
150512  6:30:01 InnoDB: The InnoDB memory heap is disabled
150512  6:30:01 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150512  6:30:01 InnoDB: Compressed tables use zlib 1.2.3
150512  6:30:01 InnoDB: Using Linux native AIO
150512  6:30:01 InnoDB: Initializing buffer pool, size = 128.0M
150512  6:30:01 InnoDB: Completed initialization of buffer pool
150512  6:30:01 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!
150512  6:30:01  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...
150512  6:30:01  InnoDB: Waiting for the background threads to start
150512  6:30:02 InnoDB: 5.5.41 started; log sequence number 68534366
150512  6:30:02 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
150512  6:30:02 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
150512  6:30:02 [Note] Server socket created on IP: '0.0.0.0'.
150512  6:30:02 [Note] Event Scheduler: Loaded 0 events
150512  6:30:02 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.41'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi
150512 06:42:37 mysqld_safe Number of processes running now: 0
150512 06:42:37 mysqld_safe mysqld restarted
150512  6:42:37 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
150512  6:42:37 [Note] Plugin 'FEDERATED' is disabled.
150512  6:42:37 InnoDB: The InnoDB memory heap is disabled
150512  6:42:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150512  6:42:37 InnoDB: Compressed tables use zlib 1.2.3
150512  6:42:37 InnoDB: Using Linux native AIO
150512  6:42:37 InnoDB: Initializing buffer pool, size = 128.0M
150512  6:42:37 InnoDB: Completed initialization of buffer pool
150512  6:42:37 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!
150512  6:42:37  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...
150512  6:42:37  InnoDB: Waiting for the background threads to start
150512 06:42:37 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
150512 06:45:02 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
150512  6:45:02 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
150512  6:45:02 [Note] Plugin 'FEDERATED' is disabled.
150512  6:45:02 InnoDB: The InnoDB memory heap is disabled
150512  6:45:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150512  6:45:02 InnoDB: Compressed tables use zlib 1.2.3
150512  6:45:02 InnoDB: Using Linux native AIO
150512  6:45:02 InnoDB: Initializing buffer pool, size = 128.0M
150512  6:45:02 InnoDB: Completed initialization of buffer pool
150512  6:45:02 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!
150512  6:45:02  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...
150512  6:45:02  InnoDB: Waiting for the background threads to start
150512  6:45:03 InnoDB: 5.5.41 started; log sequence number 68578838
150512  6:45:03 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
150512  6:45:03 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
150512  6:45:03 [Note] Server socket created on IP: '0.0.0.0'.
150512  6:45:03 [Note] Event Scheduler: Loaded 0 events
150512  6:45:03 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.41'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL \

На сервере работает следующее:

CentOS 6 vestaCP MYSQL 5.5.4 Почтовый сервер

Это старый вопрос, но ответ может быть полезен другим ...

Одной из частых причин «внезапных» сбоев MySQL / MariaDB является убийца OOM ядра - в основном, если на машине не хватает оперативной памяти, ядро ​​уничтожает процесс, наиболее потребляющий оперативную память.

Убийца OOM ядра частично настраивается, поэтому нужно иметь возможность «защитить» важный процесс. Однако настоящее решение - понять Зачем машина сталкивается с проблемой нехватки памяти; самая частая причина:

  • не настроено или недостаточно места для подкачки;
  • утечка памяти в каком-то приложении;
  • плохо настроенная база данных (например, слишком большой буфер InnoDB);
  • слишком мало памяти для реальной нагрузки.

Похоже, ваши журналы повреждены. Попробуйте воссоздать файлы журнала InnoDB, переместив существующие файлы ib_logfile (ы) в сторону и перезапустив MySQL. Если это не сработает, вероятно, есть повреждение данных.

InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery

  1. Когда база данных падала, мы получали это. Механизм Innodb пытается самопроизвольно восстановиться. Использовать innodb_force_recovery для принудительного запуска механизма хранения InnoDB

  2. Если это происходит регулярно, одновременно проверьте наличие каких-либо cron или любой logrotation (/etc/logrotate.d/mysql) запускается.

  3. Проверьте, не заканчивается ли у вас память. Если на том же сервере работает Apache или другой процесс, возможно, вам потребуется больше памяти. Проверьте ситуацию с вашим свопом

    cat /proc/swaps

    Считайте, что добавить своп в таком случае

  • Если вы перезапустите MySQL с innodb_force_recovery затем сбросьте поврежденные базы данных.

    mysqldump -u root -p –all-databases > all_dbs.sql

  • После дампа, выключите MySQL, переместите файлы ib * из каталога / var / lib / mysql /.

    mkdir /var/lib/ib_files/ mv /var/lib/mysql/ib* /var/lib/ib_files/

  • Затем удалите innodb_force_recovery из /etc/my.cnf и запустите MySQL. Проверьте mysqld.log, если есть ошибка. Как только у вас будет чистый запуск MySQL, восстановите базы данных из дампа

    mysql -u root -p < all_dbs.sql

  • После завершения восстановления запустите восстановление базы данных, чтобы просто убедиться, что все в порядке:

    mysqlcheck –all-databases –repair

  • После ремонта перезапустите mysql еще раз

    service mysql restart