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

Question

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 Почтовый сервер

2

centos mysql centos6 mysql5.5

Источник

RussellHarrower 12 май '15 в 11:09

2 ответа

Другие вопросы по тегам centos mysql centos6 mysql5.5

Simon Greenwood 25 май '15 в 17:14 2015-05-25 17:14 · Answer 1 · 2015-05-25 17:14

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

0

Источник

Simon Greenwood 25 май '15 в 17:14

shodanshok 01 окт '19 в 16:29 2019-10-01 16:29 · Answer 2 · 2019-10-01 16:29

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

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

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

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

Infra DBA 12 май '15 в 14:06 2015-05-12 14:06 · Answer 3 · 2015-05-12 14:06

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

Всякий раз, когда сбой базы данных, мы привыкли получить это. Механизм Innodb пытается спонтанно восстановиться. Используйте innodb_force_recovery, чтобы заставить механизм хранения InnoDB запускаться
Если это происходит регулярно, в то же время проверьте cron или любой logrotation (/etc/logrotate.d/mysql) срабатывает.
Проверьте, не хватает ли памяти. Если 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