在Ubuntu上更新后无法启动mysql服务器16.04

问题描述:

我在我的服务器上使用mysql时遇到问题。更新后mysql停止在我的系统上工作。看起来它在启动后马上崩溃,所以我甚至无法备份我的数据库,因为服务没有运行。 我的MySQL错误日志中有如下内容:在Ubuntu上更新后无法启动mysql服务器16.04

tail -70 /var/log/mysql/error.log 
2017-07-27T06:56:20.080287Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080330Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=406] log sequence number 199107155900 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080336Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080432Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=208] log sequence number 199110108309 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080440Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080481Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=735] log sequence number 196716783961 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080488Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080530Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=378] log sequence number 199109175046 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080536Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080586Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=209] log sequence number 199110429878 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080598Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080641Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=342] log sequence number 199106867077 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080647Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27T06:56:20.080690Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=16395] log sequence number 199094094548 is in the future! Current system log sequence number 191999990814. 
2017-07-27T06:56:20.080701Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. 
2017-07-27 08:56:20 0xb7343700 InnoDB: Assertion failure in thread 3073652480 in file fut0lst.ic line 85 
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.7/en/forcing-innodb-recovery.html 
InnoDB: about forcing recovery. 
06:56:20 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. 
Attempting to collect some information that could help diagnose the problem. 
As this is a crash and something is definitely wrong, the information 
collection process might 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 = 75717 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+0x3c)[0x8a8b33c] 
/usr/sbin/mysqld(handle_fatal_signal+0x426)[0x837f356] 
[0xb77c0c14] 
[0xb77c0c31] 
/lib/i386-linux-gnu/libc.so.6(gsignal+0x39)[0xb738bea9] 
/lib/i386-linux-gnu/libc.so.6(abort+0x157)[0xb738d407] 
/usr/sbin/mysqld[0x8355dcf] 
/usr/sbin/mysqld(_Z19trx_undo_lists_initP10trx_rseg_t+0xddc)[0x8d394dc] 
/usr/sbin/mysqld[0x8d1d60f] 
/usr/sbin/mysqld[0x8d203ec] 
/usr/sbin/mysqld(_Z24trx_sys_init_at_db_startv+0x18cc)[0x8d2792c] 
/usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x5382)[0x8ceaa32] 
/usr/sbin/mysqld[0x8b98d0e] 
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x52)[0x83ccfd2] 
/usr/sbin/mysqld[0x88611a2] 
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x60f)[0x886916f] 
/usr/sbin/mysqld[0x8377795] 
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x83b)[0x837906b] 
/usr/sbin/mysqld(main+0x27)[0x8357917] 
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xb7378637] 
/usr/sbin/mysqld[0x836f4dc] 
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. 

似乎没有与InnoDB的一个问题。

因为我已经尝试过调整我my.conf文件,并添加以下行:

[mysqld] 
innodb_force_recovery = 4 

尝试重新启动(systemctl重启mysql.service)它仍然同样的问题后。

我也尝试完全重新安装MySQL服务器,但它仍然是同样的问题。

我也试图备份文件每次在/ var/lib中/ MySQL和运行:

mkdir /root/backup_mysql/ 
mv /var/lib/mysql/* /root/backup_mysql/ 
dpkg --configure mysql-server-5.7 

但即使它仍然是同样的问题。

你有什么想法如何解决这个问题?

+0

难道你不必担心数据吗? – sprksh

+0

你是什么意思?我的意思是说,我很担心数据,这就是为什么我打开这个线程。从lib目录移动文件暂时只是暂时性的,看看它是否会在mysql初始化为“新鲜”时发生。 –

+0

我的意思是你没有采取适当的转储更新之前。无论如何,我得到了答案。你有没有尝试innodb_force_recovery = 1。我已经设法在本地windows计算机上使用了很长时间。问题是相似的。 – sprksh

问题与tablespaceMySql数据库引擎InnoDb用于CRUD操作。

使用

[mysqld] 
innodb_force_recovery = 1 

让即使检测到损坏的页服务器运行。试图让SELECT * FROM tbl_name跳过损坏的索引记录和页面,这有助于转储表。

这似乎对你的情况有帮助的,以获取更多信息,请参阅mysql manual和相同的建议在错误日志。

如果在不理解其效果的情况下使用不同的值,最终可能会丢失数据。所以要小心。

如果数据不是那么重要,您可以从系统中完全删除mysql并仔细重新安装,这将有希望发挥作用。

如何完全删除mysql

转至/var/lib/mysql/类似于您的系统,删除mysql文件夹也从/etc/mysql文件夹中手动删除配置文件。

更新您的ubuntu存储库并重新安装mysql。

+0

我已经尝试过这(我想我试过值1,4 ,6为innodb_force_recovery(我发现这个提示也在其他线程),但它没有帮助解决问题。它仍然没有运行。 –

+0

@DannyKoppenhagen我编辑答案,试试看,并让我们知道结果是什么,因为它会帮助其他人 –

+0

谢谢你,这是我的问题的解决方案。我也能够从/ var/lib/mysql中复制我保存的文件,并且mysql正在与我的d再来一次。 –