Mysql сбой / перезапуск, InnoDB: невозможно заблокировать./ibdata1. Не может убить через "стоп";

Мой сервер, кажется, падает / перезагружается при нагрузке, которая раньше не вызывала его сбой.

Как я могу устранить это?

VPS работает под управлением Centos 6.x, 8 ГБ оперативной памяти

  • Mysql аварийно завершает работу / перезапускает себя при нагрузках, которые раньше не выполнялись бы.
  • Эта ошибка: InnoDB: Unable to lock ./ibdata1, error: 11 выскакивает в журнале после сбоя. Может ли это быть просто из-за того, что mysql восстанавливается после сбоя и пытается перезапуститься, пока он полностью не умер?

Я не уверен, связано ли это со сбоем, как это видно во время попытки перезагрузки базы данных. Довольно много строк:

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

Журнал затем продолжается:

141207 18:58:06 [ERROR] Plugin 'InnoDB' init function returned error.
141207 18:58:06 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
141207 18:58:06 [ERROR] Failed to initialize plugins.
141207 18:58:06 [ERROR] Aborting

141207 18:58:06 [Note] /usr/libexec/mysqld: Shutdown complete

141207 18:58:06 mysqld_safe Number of processes running now: 1
141207 18:58:06 mysqld_safe mysqld process hanging, pid 15456 - killed
141207 18:58:06 mysqld_safe mysqld restarted
141207 18:58:06 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141207 18:58:06  InnoDB: Initializing buffer pool, size = 6.0G
141207 18:58:06  InnoDB: Completed initialization of buffer pool
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
141207 18:58:06  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...
InnoDB: Last MySQL binlog file position 0 14626, file name /var/lib/mysql/mysql-bin.000892
141207 18:58:06  InnoDB: Started; log sequence number 3 2358701171
141207 18:58:06 [Note] Recovering after a crash using /var/lib/mysql/mysql-bin
141207 18:58:06 [Note] Starting crash recovery...
141207 18:58:06 [Note] Crash recovery finished.
141207 18:58:06 [Note] Event Scheduler: Loaded 0 events
141207 18:58:06 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Похоже, не так много информации, которая может привести к тому, что MySQL теперь так слаб. Учитывая отсутствие изменений my.cnf или других изменений, я не думаю, что это проблема конфигурации.

Где мне искать лучшие данные по этому вопросу? Или есть более "жесткий" сброс настроек, который я могу сделать, чтобы вернуть вещи в нормальное состояние?

РЕДАКТИРОВАТЬ - Последние из журналов

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

Вот последний вывод из файла журнала, все после перезагрузки, которую я выполнил до запуска задачи. Насколько я могу судить, ничего, что могло бы объяснить причину крушения, верно?

141207 20:50:34 mysqld_safe Number of processes running now: 0
141207 20:50:34 mysqld_safe mysqld restarted
141207 20:50:35  InnoDB: Initializing buffer pool, size = 5.0G
141207 20:50:35  InnoDB: Error: cannot allocate 5368725504 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 36878736 bytes. Operating system errno: 12
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
141207 20:50:49  InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 3 2681111025
141207 20:50:49  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...
InnoDB: Doing recovery: scanned up to log sequence number 3 2686353408
InnoDB: Doing recovery: scanned up to log sequence number 3 2691596288
InnoDB: Doing recovery: scanned up to log sequence number 3 2696839168
InnoDB: Doing recovery: scanned up to log sequence number 3 2702082048
InnoDB: Doing recovery: scanned up to log sequence number 3 2707324928
InnoDB: Doing recovery: scanned up to log sequence number 3 2712567808
InnoDB: Doing recovery: scanned up to log sequence number 3 2717810688
InnoDB: Doing recovery: scanned up to log sequence number 3 2723053568
InnoDB: Doing recovery: scanned up to log sequence number 3 2728296448
InnoDB: Doing recovery: scanned up to log sequence number 3 2733539328
InnoDB: Doing recovery: scanned up to log sequence number 3 2738782208
InnoDB: Doing recovery: scanned up to log sequence number 3 2739356250
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 237115 row operations to undo
InnoDB: Trx id counter is 0 15792384
141207 20:50:50  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 157660, file name /var/lib/mysql/mysql-bin.000902
InnoDB: Starting in background the rollback of uncommitted transactions
141207 20:51:07  InnoDB: Rolling back trx with id 0 15789484, 237115 rows to undo

InnoDB: Progress in percents: 1141207 20:51:07  InnoDB: Started; log sequence number 3 2739356250
141207 20:51:07 [Note] Recovering after a crash using /var/lib/mysql/mysql-bin
141207 20:51:07 [Note] Starting crash recovery...
141207 20:51:07 [Note] Crash recovery finished.
 2 3 4141207 20:51:07 [Note] Event Scheduler: Loaded 0 events
141207 20:51:07 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution
 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
InnoDB: Rolling back of trx id 0 15789484 completed
141207 20:51:11  InnoDB: Rollback of non-prepared transactions completed
141207 20:51:20 [ERROR] /usr/libexec/mysqld: Table './bck_wpdb/bck_statpress' is marked as crashed and should be repaired
141207 20:51:20 [Warning] Checking table:   './bck_wpdb/bck_statpress'
141207 20:52:19 [ERROR] /usr/libexec/mysqld: Table './mdi_db1/mdi_statpress' is marked as crashed and should be repaired
141207 20:52:19 [Warning] Checking table:   './mdi_db1/mdi_statpress'

1 ответ

Эта запись в журнале является ключом к наиболее вероятной проблеме:

141207 20:50:34 mysqld_safe Number of processes running now: 0

Если непосредственно перед этой строкой нет слишком многословного блока сообщений журнала, включая трассировку стека, то MySQL фактически не падает... ядро ​​убивает его, потому что другой процесс (например, веб-сервер) предъявляет агрессивные требования к система для памяти. В отчаянной попытке ослабить давление и избежать надвигающегося системного сбоя или блокировки, ядро ​​разыскивает процесс для уничтожения.

$ cat /var/log/messages | egrep -i 'mysql|oom|kernel'

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

Все, что находится после записи в журнале, это просто MySQL, пытающийся перезапустить себя и восстановиться после уничтожения. В случае серьезной нехватки памяти, он не сможет перезапуститься сразу, потому что просто недостаточно системной памяти:

141207 20:50:35 InnoDB: Error: cannot allocate 5368725504 bytes of 
InnoDB: memory with malloc! Total allocated memory 
InnoDB: by InnoDB 36878736 bytes. Operating system errno: 12

В Linux Ошибка 12 действительно "не хватает памяти". И, опять же, это не MySQL, говорящий, что ему не хватает памяти, это ядро.


Также следует отметить, что 5 368 725 504 байта кажутся очень большим буферным пулом для 8 ГБ сервера, если только сервер не выполняет ничего, кроме запуска MySQL. Субъективное правило для разделяемых рабочих нагрузок - выделять не более 50% системной памяти для пула буферов.

Объем выделяемой здесь памяти запрашивается и удерживается MySQL и недоступен для других процессов. Как правило, с этим конкретным параметром чем больше, тем лучше... но только в пределах разумного, основанного на доступных ресурсах.

Другие вопросы по тегам