Назад | Перейти на главную страницу

mysql не запускается, mysqld получил сигнал 11;

Я пытаюсь запустить mysql на VPS, которым я не пользовался несколько месяцев (когда он работал). Я использую MariaDB и все обновлено.

Журнал ошибок показывает следующее:

  systemd[1]: Starting LSB: Start and stop the mysql database server daemon...
  systemd[1]: Failed to reset devices.list on /system.slice/mysql.service: No such file or directory
  mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
  mysqld: 180123  4:52:41 [Note] /usr/sbin/mysqld (mysqld 10.0.32-MariaDB-0+deb8u1) starting as process 24959 ...
  mysqld: 180123  4:52:41 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
  mysqld: 
  mysqld: 180123  4:52:41 [Note] InnoDB: Using mutexes to ref count buffer pool pages
  mysqld: 180123  4:52:41 [Note] InnoDB: The InnoDB memory heap is disabled
  mysqld: 180123  4:52:41 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
  mysqld: 180123  4:52:41 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
  mysqld: 180123  4:52:41 [Note] InnoDB: Compressed tables use zlib 1.2.8
  mysqld: 180123  4:52:41 [Note] InnoDB: Using Linux native AIO
  mysqld: 180123  4:52:41 [Note] InnoDB: Using CPU crc32 instructions
  mysqld: 180123  4:52:41 [Note] InnoDB: Initializing buffer pool, size = 128.0M
  mysqld: 180123  4:52:41 [Note] InnoDB: Completed initialization of buffer pool
  mysqld: 180123  4:52:41 [Note] InnoDB: Highest supported file format is Barracuda.
  mysqld: 180123  4:52:41 [Note] InnoDB: The log sequence numbers 6768897232 and 6768897232 in ibdata files do not match the log sequence number 6768897252 in the ib_logfiles!
  mysqld: 180123  4:52:41 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
  mysqld: 180123  4:52:42 [Note] InnoDB: 128 rollback segment(s) are active.
  mysqld: 180123  4:52:42 [Note] InnoDB: Waiting for purge to start
  mysqld: 180123  4:52:42 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 6768897252
  mysqld: 180123  4:52:42 [Note] mysqld: Aria engine: starting recovery
  mysqld: recovered pages: 0% 10% 20% 30% 40% 50% 60% 70% 80% 90%180123  4:52:42 [ERROR] mysqld got signal 11 ;
  mysqld: This could be because you hit a bug. It is also possible that this binary
  mysqld: or one of the libraries it was linked against is corrupt, improperly built,
  mysqld: or misconfigured. This error can also be caused by malfunctioning hardware.
  mysqld: 
  mysqld: To report this bug, see https://mariadb.com/kb/en/reporting-bugs
  mysqld: 
  mysqld: We will try our best to scrape up some info that will hopefully help
  mysqld: diagnose the problem, but since we have already crashed,
  mysqld: something is definitely wrong and this may fail.
  mysqld: 
  mysqld: Server version: 10.0.32-MariaDB-0+deb8u1
  mysqld: key_buffer_size=16777216
  mysqld: read_buffer_size=131072
  mysqld: max_used_connections=0
  mysqld: max_threads=153
  mysqld: thread_count=0
  mysqld: It is possible that mysqld could use up to
  mysqld: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 352327 K  bytes of memory
  mysqld: Hope that's ok; if not, decrease some variables in the equation.
  mysqld: 
  mysqld: Thread pointer: 0x0
  mysqld: Attempting backtrace. You can use the following information to find out
  mysqld: where mysqld died. If you see no messages after this, something went
  mysqld: terribly wrong...
  mysqld: stack_bottom = 0x0 thread_stack 0x30000
  mysqld: /usr/sbin/mysqld(my_print_stacktrace+0x2e)[0xc047de]
  mysqld: /usr/sbin/mysqld(handle_fatal_signal+0x3af)[0x7362bf]
  mysqld: /lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f128077c890]
  mysqld: /usr/sbin/mysqld[0xae046a]
  mysqld: /usr/sbin/mysqld[0xadf4e1]
  mysqld: /usr/sbin/mysqld[0xae4307]
  mysqld: /usr/sbin/mysqld[0xae4a8e]
  mysqld: /usr/sbin/mysqld[0xac0495]
  mysqld: /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x5e)[0x73836e]
  mysqld: /usr/sbin/mysqld[0x5d0995]
  mysqld: /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x4b0)[0x5d1b70]
  mysqld: /usr/sbin/mysqld[0x529d85]
  mysqld: /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x55d)[0x52f8ad]
  mysqld: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f127f30db45]
  mysqld: /usr/sbin/mysqld[0x525361]
  mysqld: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
  mysqld: information that should help you find out what is causing the crash.
  mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended

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

изменить: я сделал резервную копию папки для базы данных, которую я хочу сохранить, затем удалил и установил mariadb, чтобы запустить его, затем я скопировал папку db обратно.

Сейчас он работает, но одна из таблиц недоступна. Если я сделаю ПРОВЕРКУ:

tblProducts: Table is marked as crashed and last repair failed
tblProducts: 22 clients are using or haven't closed the table properly
tblProducts: Table create_trd (8415420) > current max_transaction id (1). Table needs to be repaired or zerofilled to be usable
tblProducts: Size of indexfile is: 564641792 Expected: 17252352
tblProducts: Corrupt

edit2: Затем я сделал простой "ремонт" на столе, и все хорошо. Настолько разочаровывающе, что приведенные ошибки предполагали проблемы с оборудованием и заставляли меня гуглить все коды ошибок, когда это было что-то настолько простое. Да ладно живи и учись!

Я исправил это, сделав резервную копию таблиц, удалив mariadb, установив mariadb, чтобы он действительно запускался успешно, а затем скопировал таблицы обратно. Одна таблица была повреждена, и ремонт был исправлен.

  • Проверить свободное место
  • Проверьте cron (ls -l /etc/cron.daily)
  • Проверить систему регистрации. В $ DATADIR может быть слишком много журналов, и в этом случае завершите все процессы mysql и процессы mysqld и удалите все журналы релейных бункеров из $ DATADIR, а затем снова запустите процессы. Наконец, подключитесь к базе данных и выполните «очистить журналы».
  • Из my.cnf попробуйте удалить записи expire-logs-days и max_binlog_size (потому что наличие записи expire_logs_days без bin_log может вызвать сбой) и посмотрите, решит ли это проблему.