我正在尝试在几个月没用过的 VPS 上启动并运行 mysql（当时它还在运行）。我正在使用 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
我已经在 Google 上搜索了所有错误代码，也尝试了 innodb 恢复标志，但都无济于事。我真的很困惑，希望有人能帮忙。谢谢`
编辑：我备份了我想要挽救的数据库的文件夹，然后删除并安装了 mariadb 以使其启动并运行，然后我将数据库文件夹复制回来。
它现在正在运行，但其中一个表无法访问。如果我对其进行检查：
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
编辑2：然后我对桌子进行了简单的“维修”，一切正常。令人沮丧的是，给出的错误表明存在硬件问题，并让我在谷歌上搜索所有错误代码，而这其实很简单。哦，活到老学到老！
答案1
我会在这里发表评论，以防其他人遇到同样的问题并且 Google 将他们发送到这里并且他们不想像上面提到的那样重新安装 MariaDB。
要解决此问题，您只需移动或删除 aria_log.######## 文件，然后启动 MariaDB。这是我的日志和我使用的命令所在的位置。
mv /var/lib/mysql/aria_log.00000102 /var/lib/mysql/bak.aria_log.00000102
service mariadb start
答案2
- 检查可用空间
- 检查 cron（ls -l /etc/cron.daily）
- 检查日志系统。$DATADIR 可能有太多日志，在这种情况下，请终止所有 mysql 进程和 mysqld 进程并从 $DATADIR 中删除所有中继 bin 日志，然后重新启动进程。最后，连接到数据库并发出“刷新日志”。
- 从 my.cnf 尝试删除 expire-logs-days 和 max_binlog_size 条目（因为没有 bin_log 的 expire_logs_days 条目可能会导致崩溃）并查看是否能解决问题。
答案3
我通过备份表、删除 mariadb、安装 mariadb 来修复这个问题，这样它就可以成功启动，然后复制回表。一个表损坏了，修复后就修复了。