Проблема с MySQL

Но 2 в данном случае куда безопаснее 0. Ладно, тема не об этом. Пока что 2 сутки работает (тьфу-тьфу-тьфу).

Если кому-то интересно, то информирую. В dmesg найдено было еще следующее:

[ 1803.199382] INFO: task mysqld:2318 blocked for more than 120 seconds.

[ 1803.199718]       Tainted: P           ---------------    2.6.32-531.29.2.lve1.3.11.5.el6.x86_64 #1

[ 1803.200379] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[ 1803.201029] mysqld        D ffff88080b653290     0  2318   1784    0 0x00000000

[ 1803.201031]  ffff8807dd0dfa88 0000000000000086 ffff8807dd0dfa50 ffffffff811e657f

[ 1803.201033]  ffff8806ba552040 000000000002abf0 ffff88002838f230 ffff880800000001

[ 1803.201035]  ffff88002838f220 ffff88080b653858 0000000100000000 000000000001dcc0

[ 1803.201037] Call Trace:

[ 1803.201040]  [<ffffffff811e657f>] ? __find_get_block_slow+0xaf/0x130

[ 1803.201044]  [<ffffffffa009d0a2>] start_this_handle+0x272/0x490 [jbd2]

[ 1803.201048]  [<ffffffff810a2120>] ? autoremove_wake_function+0x0/0x40

[ 1803.201053]  [<ffffffffa009d4a5>] jbd2_journal_start+0xb5/0x100 [jbd2]

[ 1803.201061]  [<ffffffffa00dfd16>] ext4_journal_start_sb+0x56/0xe0 [ext4]

[ 1803.201067]  [<ffffffffa00cceb7>] ext4_da_write_begin+0xa7/0x230 [ext4]

[ 1803.201071]  [<ffffffffa009c9b7>] ? jbd2_journal_stop+0x1e7/0x2b0 [jbd2]

[ 1803.201075]  [<ffffffff81135fdc>] generic_file_buffered_write_iter+0xec/0x290

[ 1803.201078]  [<ffffffff811dcc37>] ? __mark_inode_dirty+0x147/0x190

[ 1803.201082]  [<ffffffff81136ce5>] __generic_file_write_iter+0x225/0x420

[ 1803.201086]  [<ffffffff81136f65>] __generic_file_aio_write+0x85/0xa0

[ 1803.201090]  [<ffffffff81137019>] generic_file_aio_write+0x99/0x110

[ 1803.201093]  [<ffffffff8105b9a0>] ? __dequeue_entity+0x30/0x50

[ 1803.201098]  [<ffffffffa00c0008>] ext4_file_write+0x58/0x190 [ext4]

[ 1803.201102]  [<ffffffff811ad152>] do_sync_write+0xf2/0x140

[ 1803.201105]  [<ffffffff811ad438>] vfs_write+0xb8/0x1a0

[ 1803.201108]  [<ffffffff811adec2>] sys_pwrite64+0x82/0xa0

[ 1803.201112]  [<ffffffff8100b102>] system_call_fastpath+0x16/0x1b

Также было найдено, как можно было повесить MySQL. Стабильно зависал от: "mysqlcheck --repair --use-frm --all-databases"

Дальше стал копать, почему же ядро блокирует процесс на 2 минуты (в теории якобы из-за нехватки I/O, если не ошибаюсь, хотя iowait очень маленький, на сервере RAID 10 из 4 SSD).

Найдено было следующее, CloudLinux в Cpanel ставит странный init.d скрипт для MySQL, который ограничивает ресурсы для процесса. Скорее всего для db_governor из комплекта. Его замена на обычный init.d скрипт дала плоды - блокировок нет, mysqlcheck выполнился трижды без ошибок.

Всем спасибо за участие!

Рискуем потерять данные при аварийной остановке MySQL

При аварийной остановке MySQL рискуем потерять только то что в кэше и не сбросилось на диск.

innodb_flush_log_at_trx_commit = 0 - ничего хорошего в этом совете нету. Разве что downtime и потеря данных вовсе не критичны. Но в таком случае зачем использовать innoDB, MyISAM также себя поведет в любом случае, - это к тому что innoDB кроме других особенностей и повышает безопасность (сохранность данных).

Поддерживаю Евгения, 2 в самый раз.

Не рискуем. Там нечего терять, если как ТС не баловаться с другими настройками innodb.

Во всяком случае, для веба 0 - это нормально. Подробности в документации.