Question

我有一种情况，我不知道最好的出路。我有一个正在运行的虚拟机，由于停电而停止了。在下一次启动时，mysql开始崩溃。 /var/log/mysqld.log以下行重复了1000次，直到我关闭了mysql守护进程。

Version: '5.5.29'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MySQL Community Server (GPL) by Remi
180529 14:47:06  InnoDB: Assertion failure in thread 139810525968128 in file trx0purge.c line 829
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
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.
12:47:06 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=30408704
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 = 359993 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 0x100000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x78569e]
/usr/libexec/mysqld(handle_fatal_signal+0x493)[0x66faf3]
/lib64/libpthread.so.0(+0xf500)[0x7f286c73d500]
/lib64/libc.so.6(gsignal+0x35)[0x7f286ab848a5]
/lib64/libc.so.6(abort+0x175)[0x7f286ab86085]
/usr/libexec/mysqld[0x830064]
/usr/libexec/mysqld[0x8303d1]
/usr/libexec/mysqld[0x8ec3ef]
/usr/libexec/mysqld[0x8e2d75]
/usr/libexec/mysqld[0x82ed25]
/usr/libexec/mysqld[0x821f2c]
/usr/libexec/mysqld[0x824c43]
/lib64/libpthread.so.0(+0x7851)[0x7f286c735851]
/lib64/libc.so.6(clone+0x6d)[0x7f286ac3a11d]
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.
180529 14:47:06 mysqld_safe Number of processes running now: 0
180529 14:47:06 mysqld_safe mysqld restarted
180529 14:47:06 [Note] Plugin 'FEDERATED' is disabled.
180529 14:47:06 InnoDB: The InnoDB memory heap is disabled
180529 14:47:06 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180529 14:47:06 InnoDB: Compressed tables use zlib 1.2.3
180529 14:47:06 InnoDB: Using Linux native AIO
180529 14:47:06 InnoDB: Initializing buffer pool, size = 479.0M
180529 14:47:06 InnoDB: Completed initialization of buffer pool
180529 14:47:06 InnoDB: highest supported file format is Barracuda.
180529 14:47:06  InnoDB: Waiting for the background threads to start
180529 14:47:07 InnoDB: 1.1.8 started; log sequence number 9832719702
180529 14:47:07 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
180529 14:47:07 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
180529 14:47:07 [Note] Server socket created on IP: '0.0.0.0'.

my.cnf的内容是：

[mysqld]
query_cache_limit=30M
max_allowed_packet=999M
query_cache_size=250M
innodb_file_per_table=1
thread_stack=1M
key_buffer=29M
thread_concurrency=4
table_cache=128
innodb_buffer_pool_size=479M
thread_cache_size=4
join_buffer_size=14M
# Settings user and group are ignored when systemd is used (fedora >= 15).
# If you need to run mysqld under different user or group,
# customize your systemd unit file for mysqld according to the
# instructions in http://fedoraproject.org/wiki/Systemd
user=mysql

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# Semisynchronous Replication
# http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html
# uncomment next line on MASTER
;plugin-load=rpl_semi_sync_master=semisync_master.so
# uncomment next line on SLAVE
;plugin-load=rpl_semi_sync_slave=semisync_slave.so

# Others options for Semisynchronous Replication
;rpl_semi_sync_master_enabled=1
;rpl_semi_sync_master_timeout=10
;rpl_semi_sync_slave_enabled=1

# http://dev.mysql.com/doc/refman/5.5/en/performance-schema.html
;performance_schema


[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

根据建议，我可以尝试恢复InnoDB，但只是想确保我真的做得对，它不会对整个数据库造成任何损害。

Answer 1

看起来你有InnoDB损坏，如果没有数据库的备份，你必须按照MySQL文档中描述的InnoDB强制恢复过程： https://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

通常，算法如下所示：

将innodb_force_recovery指令添加到my.cnf文件（/etc/my.cnf CentOS,/etc/mysql/my.cnf Debian like systems）。将启动器的参数值设置为1并尝试启动mysql服务器。如果失败，请将其增加到2并尝试启动它。继续增加它直到MySQL服务器启动。 innodb_force_recovery的最大值为6。
启动服务器时，使用mysqldump
接下来，启动恢复过程，但在创建整个mysql数据目录的备份之前，默认为/var/lib/mysql：
```
# grep data /etc/my.cnf
  datadir=/var/lib/mysql
```
停止MySQL服务器，从/var/lib/mysql目录
从my.cnf文件中删除innodb_force_recovery指令，添加skip_gran_tables指令，这样就可以在没有管理员密码的情况下连接到服务器并启动MySQL服务器。
从步骤2中创建的转储中还原数据库。在还原之前，应将数据库创建为create database db_name。

毕竟不要忘记删除skip_gran_tables指令并重新启动MySQL服务器以应用更改。

Answer 2

建议考虑你的my.cnf-ini [mysqld]部分

#sort_buffer_size=?????  # lead with # to allow default to work for you.

并发布当前值，以便我们知道您尝试使用的内容。

请在您的问题中发帖，完整的my.cnf-ini。

Answer 3

对my.cnf-ini [mysqld]部分的建议

使用以下＃删除或带领以允许默认值为您工作，请

query_cache_limit=30M
max_allowed_packet=999M
query_cache_size=250M
thread_stack=1M
key_buffer=29M
thread_concurrency=4
thread_cache_size=4
join_buffer_size-14M

这种缓解可能会让您继续并避免大量的RAM占用空间。使用MySQLCalculator.com 2分钟将说明为什么不应该使用您要求的值。

在主机不安全重启后，mysqld在启动时崩溃

3 个答案: