数据库发生崩溃解决方案

因为在平时关闭虚拟机都是暴力关闭的  终于mysql崩溃了.

就在今天早上启动不了了.

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.
2023-06-28 08:45:46+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.29-1debian10 started.
2023-06-28 08:45:47+08:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2023-06-28 08:45:47+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.29-1debian10 started.
2023-06-28T00:45:47.686790Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.29) starting as process 1
2023-06-28T00:45:47.694247Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2023-06-28T00:45:47.703673Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-06-28T00:45:49.457414Z 1 [ERROR] [MY-012562] [InnoDB] We scanned the log up to 658605751. A checkpoint was at 658605781 and the maximum LSN on a database page was 0. It is possible that the database is now corrupt!
2023-06-28T00:45:49.457503Z 1 [ERROR] [MY-013183] [InnoDB] Assertion failure: log0recv.cc:4104 thread 140444693354240
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/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
00:45:49 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x56366316b300
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 = 7fbbd40eccd0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x56365dbe5c1d]
/usr/sbin/mysqld(print_fatal_signal(int)+0x303) [0x56365cc76633]
/usr/sbin/mysqld(my_server_abort()+0x6e) [0x56365cc7674e]
/usr/sbin/mysqld(my_abort()+0xa) [0x56365dbdfd7a]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x326) [0x56365debad16]
/usr/sbin/mysqld(recv_recovery_from_checkpoint_start(log_t&, unsigned long)+0x1a10) [0x56365dd866c0]
/usr/sbin/mysqld(srv_start(bool)+0x1fed) [0x56365de61cdd]
/usr/sbin/mysqld(+0x21f1af6) [0x56365dcc0af6]
/usr/sbin/mysqld(dd::bootstrap::DDSE_dict_init(THD*, dict_init_mode_t, unsigned int)+0x9f) [0x56365d9c04bf]
/usr/sbin/mysqld(dd::upgrade_57::do_pre_checks_and_initialize_dd(THD*)+0x19a) [0x56365dbb9aaa]
/usr/sbin/mysqld(+0x12640a6) [0x56365cd330a6]
/usr/sbin/mysqld(+0x268ba32) [0x56365e15aa32]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3) [0x7fbbe0c07fa3]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7fbbe03d5eff]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 1
Status: NOT_KILLED

解决方案  修改mysql文件为强制恢复数据.

这是我的本地路径    各位看官根据自己mysql的位置查找

/usr/local/src/mysql/conf

 

 如果6不行   就在0-6选择一个

重启服务以后将数据导出成sql文件

 然后重新安装mysql   将数据导入新安装的数据库

 

 

 数据回来了