Не стартует mysql, помогите разобраться

[olorin]

Добрый день! Возможно глюк, а скорее моя криворукость. 17.05.16 среди дня упали сайты с ошибкой

Код: [Выделить]

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
Лог mysql:

Код: [Выделить]

160520 10:02:14 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is depr$
160520 10:02:14 [Note] Plugin 'FEDERATED' is disabled.
160520 10:02:14 InnoDB: The InnoDB memory heap is disabled
160520 10:02:14 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160520 10:02:14 InnoDB: Compressed tables use zlib 1.2.3.4
160520 10:02:14 InnoDB: Initializing buffer pool, size = 128.0M
160520 10:02:14 InnoDB: Completed initialization of buffer pool
160520 10:02:14 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 321933278
160520 10:02:14  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 322427845
160520 10:02:14  InnoDB: Error: page 428 log sequence number 322951756
InnoDB: is in the future! Current system log sequence number 322427845.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
160520 10:02:14  InnoDB: Assertion failure in thread 139870044301120 in file fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
07:02:14 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 346701 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0x7f3608a4fa49]
/usr/sbin/mysqld(handle_fatal_signal+0x483)[0x7f36089140c3]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x7f360765acb0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35)[0x7f3606cc70d5]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x17b)[0x7f3606cca83b]
/usr/sbin/mysqld(+0x5d32a0)[0x7f3608ac52a0]
/usr/sbin/mysqld(+0x5c82c7)[0x7f3608aba2c7]
/usr/sbin/mysqld(+0x5c905c)[0x7f3608abb05c]
/usr/sbin/mysqld(+0x5caa03)[0x7f3608abca03]
/usr/sbin/mysqld(+0x5b71da)[0x7f3608aa91da]
/usr/sbin/mysqld(+0x580a39)[0x7f3608a72a39]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x41)[0x7f3608916791]
/usr/sbin/mysqld(+0x30fb71)[0x7f3608801b71]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xad4)[0x7f3608805294]
/usr/sbin/mysqld(+0x285916)[0x7f3608777916]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x624)[0x7f360877b384]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f3606cb276d]
/usr/sbin/mysqld(+0x27f169)[0x7f3608771169]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.Попытка запуска:

Код: [Выделить]

root@ubuntu:~# /etc/init.d/mysql start
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service mysql start

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start(8) utility, e.g. start mysql
start: Job failed to start
Соответственно при mysql -u root -p ошибка:

Код: [Выделить]

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)
В /var/run/mysqld сокет не создается.
Попытки вручную ни к чему не привели.

Конфигурация my.cnf

Код: [Выделить]

[client]
port            = 3306
socket          = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
#
# * Basic Settings
#
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

Попытка реконфигурации mysql проходит без проблем, но сервис не стартует.

Решил проблему, как мне казалось, удалением файлов ib_logfile0, iblogfile1, ibdata1 из /var/lib/mysql  - перезагрузка сервера, mysql работает.
Выгрузил базы из бекапа.
Но не долго счастье длилось, через 2 дня ситуация один в один, снова падает mysql
На данный момент все поднято выше описанным методом, но что-то я делаю не так.   
Есть ли какие мысли?

 

[AnrDaemon]

Есть мысль, что вы окончательно угробили свою БД.
А проблема была вовсе не в MySQL, просто у вашего сервера BIOS слетел и дата на 2000 год откатилась.

[olorin]

А с чего видно, что BIOS откатился на какую-то дату. Я не заметил изменения системной даты.   

[AnrDaemon]

Вы и логи не читали.

[Doctor_y]

root@ubuntu:~# /etc/init.d/mysql start
Rather than invoking init scripts through /etc/init.d, use the service
utility, e.g. service mysql start

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the start utility, e.g. start mysql
start: Job failed to start
 

Я не спец. в Ubuntu, пользуюсь по необходимости, но в первом абзаце он тебе пишет, что вместо запуска init скриптов, запусти командой service mysql start.

В логе mysql пишет, что база данных не закрыта нормально и пытается ее восстановить. Но безуспешно. Поэтому не запускается.

Innodb это не текстовый myIsam и восстановить его без backupa практически не возможно (если система его сама не восстановила). Так что подмени базу если есть backup или создавай снова.

[AnrDaemon]

Он даже пишет, почему восстановить невозможно…

[Doctor_y]

Он даже пишет, почему восстановить невозможно…

Ну, вообщем, да. Я только не понимаю, ну пользуешься mysql, ну почитай про форматы баз и таблиц. Ведь наверняка не пользуется транзакциями, иначе здесь не было вопросов про это. Ну делай MyIsam, они практически не убиваемые.

[AnrDaemon]

InnoDB формат по умолчанию уже лет пять. Последние версии MySQL позволяют полностью отключить поддержку MyISAM на уровне движка сервера.

[Doctor_y]

InnoDB формат по умолчанию уже лет пять. Последние версии MySQL позволяют полностью отключить поддержку MyISAM на уровне движка сервера.

Так же позволяет отключить InnoDB. Я с 3 докачевал до 5.5.46. Записей в таблицах около 5 млн за 10 лет. Даже не заметил какого либо снижения производительности. А по дефолту да - InnoDB. Но это же не значит, что она лучше. Выбор между встроенными транзакциями и надежностью. Вот пример.

[AnrDaemon]

Транзакции = надёжность.