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
InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery
Всякий раз, когда база данных разбивалась, мы получали это. Механизм Innodb пытается восстановиться спонтанно. Используйте innodb_force_recovery, чтобы заставить механизм хранения InnoDB запуститься
Если это происходит регулярно, проверьте, не сработал ли любой
cronили любойlogrotation(/etc/logrotate.d/mysql).Проверьте, не кончилась ли память. Если Apache или другой процесс, запущенный на том же сервере, вероятно, нуждается в большем количестве памяти. Проверьте ситуацию с вашим swap
cat /proc/swapsУчтите, что добавьте swap в этом случае
Если вы перезагрузите 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 -repairAfter repair, restart mysql again
service mysql restart
Похоже, ваши журналы повреждены. Попробуйте воссоздать лог-файлы InnoDB, сдвинув с места существующие файлы ib_logfile(ов) и перезапустив MySQL. Если это не сработает, вероятно, у вас повреждены некоторые данные.
.Это старый вопрос, но ответ может быть полезен другим .. .
Одной из частых причин «внезапных» сбоев MySQL / MariaDB является убийца OOM ядра - в основном, если машине не хватает оперативной памяти, ядро уничтожает процесс, наиболее потребляющий оперативную память.
Убийца OOM ядра частично настраивается, поэтому нужно иметь возможность «защитить» важный процесс. Однако настоящее решение состоит в том, чтобы понять , почему машина сталкивается с нехваткой памяти; наиболее частая причина:
- не настроено или недостаточно места подкачки;
- утечка памяти в каком-то приложении;
- плохо настроенная база данных (например, слишком большой буфер InnoDB);
- слишком мало памяти для фактическая рабочая нагрузка.