【mysql启动错误】请大神帮忙看下错误日志,分析下原因,指点一下解决方法,谢谢~
日志如下:
180430 10:09:59 mysqld_safe Logging to '/var/log/mysqld.log'.
180430 10:09:59 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-04-30 10:10:00 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-04-30 10:10:00 0 [Note] /usr/sbin/mysqld (mysqld 5.6.40) starting as process 10818 ...
2018-04-30 10:10:00 10818 [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000)
2018-04-30 10:10:00 10818 [Warning] Buffered warning: Changed limits: table_open_cache: 431 (requested 2000)
2018-04-30 10:10:00 10818 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Unknown storage engine 'InnoDB'
2018-04-30 10:10:00 10818 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
2018-04-30 10:10:00 10818 [Note] InnoDB: Using atomics to ref count buffer pool pages
2018-04-30 10:10:00 10818 [Note] InnoDB: The InnoDB memory heap is disabled
2018-04-30 10:10:00 10818 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-04-30 10:10:00 10818 [Note] InnoDB: Memory barrier is not used
2018-04-30 10:10:00 10818 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-04-30 10:10:00 10818 [Note] InnoDB: Using Linux native AIO
2018-04-30 10:10:00 10818 [Note] InnoDB: Using CPU crc32 instructions
2018-04-30 10:10:00 10818 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2018-04-30 10:10:00 10818 [Note] InnoDB: Completed initialization of buffer pool
2018-04-30 10:10:00 10818 [Note] InnoDB: Highest supported file format is Barracuda.
2018-04-30 10:10:00 10818 [Note] InnoDB: The log sequence numbers 2589937 and 2589937 in ibdata files do not match the log sequence number 2590220 in the ib_logfiles!
2018-04-30 10:10:00 10818 [Note] InnoDB: Database was not shutdown normally!
2018-04-30 10:10:00 10818 [Note] InnoDB: Starting crash recovery.
2018-04-30 10:10:00 10818 [Note] InnoDB: Reading tablespace information from the .ibd files...
2018-04-30 10:10:00 10818 [Note] InnoDB: Restoring possible half-written data pages
2018-04-30 10:10:00 10818 [Note] InnoDB: from the doublewrite buffer...
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
02:10:00 UTC - mysqld got signal 11 ;
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=8388608
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 = 68108 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 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0x8e9ceb]
/usr/sbin/mysqld(handle_fatal_signal+0x491)[0x675ca1]
/lib64/libpthread.so.0(+0xf5e0)[0x7f5c9aa765e0]
/usr/sbin/mysqld[0xa6f8d8]
/usr/sbin/mysqld[0xa71819]
/usr/sbin/mysqld[0x9dda11]
/usr/sbin/mysqld[0x91b298]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5b6028]
/usr/sbin/mysqld[0x6fe4e0]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x940)[0x704cb0]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x8ad)[0x5af9ed]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f5c9965cc05]
/usr/sbin/mysqld[0x5a24bd]
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.
180430 10:10:00 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
180430 10:12:33 mysqld_safe Logging to '/var/log/mysqld.log'.
180430 10:12:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2018-04-30 10:12:33 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-04-30 10:12:33 0 [Note] /usr/sbin/mysqld (mysqld 5.6.40) starting as process 12289 ...
2018-04-30 10:12:33 12289 [Warning] Buffered warning: Changed limits: max_open_files: 1024 (requested 5000)
2018-04-30 10:12:33 12289 [Warning] Buffered warning: Changed limits: table_open_cache: 431 (requested 2000)
2018-04-30 10:12:33 12289 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Unknown storage engine 'InnoDB'
2018-04-30 10:12:33 12289 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
2018-04-30 10:12:33 12289 [Note] InnoDB: Using atomics to ref count buffer pool pages
2018-04-30 10:12:33 12289 [Note] InnoDB: The InnoDB memory heap is disabled
2018-04-30 10:12:33 12289 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-04-30 10:12:33 12289 [Note] InnoDB: Memory barrier is not used
2018-04-30 10:12:33 12289 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-04-30 10:12:33 12289 [Note] InnoDB: Using Linux native AIO
2018-04-30 10:12:33 12289 [Note] InnoDB: Using CPU crc32 instructions
2018-04-30 10:12:33 12289 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2018-04-30 10:12:33 12289 [Note] InnoDB: Completed initialization of buffer pool
2018-04-30 10:12:33 12289 [Note] InnoDB: Highest supported file format is Barracuda.
2018-04-30 10:12:33 12289 [Note] InnoDB: The log sequence numbers 2589937 and 2589937 in ibdata files do not match the log sequence number 2590220 in the ib_logfiles!
2018-04-30 10:12:33 12289 [Note] InnoDB: Database was not shutdown normally!
2018-04-30 10:12:33 12289 [Note] InnoDB: Starting crash recovery.
2018-04-30 10:12:33 12289 [Note] InnoDB: Reading tablespace information from the .ibd files...
2018-04-30 10:12:33 12289 [Note] InnoDB: Restoring possible half-written data pages
2018-04-30 10:12:33 12289 [Note] InnoDB: from the doublewrite buffer...
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
InnoDB: wrong number of columns in SYS_INDEXES record
02:12:33 UTC - mysqld got signal 11 ;
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=8388608
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 = 68108 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 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x3b)[0x8e9ceb]
/usr/sbin/mysqld(handle_fatal_signal+0x491)[0x675ca1]
/lib64/libpthread.so.0(+0xf5e0)[0x7fd2754855e0]
/usr/sbin/mysqld[0xa6f8d8]
/usr/sbin/mysqld[0xa71819]
/usr/sbin/mysqld[0x9dda11]
/usr/sbin/mysqld[0x91b298]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5b6028]
/usr/sbin/mysqld[0x6fe4e0]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x940)[0x704cb0]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x8ad)[0x5af9ed]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fd27406bc05]
/usr/sbin/mysqld[0x5a24bd]
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.
180430 10:12:33 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
相关推荐
mysql服务无法启动报错误1067解决方法(mysql启动错误1067)
试了谷歌到的几种方法,都没有解决,然后突然想起在启动apache的时候,iis的端口占用情况(因为我的apache也使用了80端口),所以 打开命令行 netstat -aon|findstr “3306” 结果显示 默默的在内心深处骂了一句“靠”, 果然是端口占用,然后,顺藤摸瓜 tasklist|findstr “416” 结果显示 不得不联想到,优酷的攻城狮们的mysql数据库绝对不是使用的默认3306端口,然后杀掉explorer.exe进程,然后重起之,把那个可恶的小加速器配置为不隐藏在任务栏并且开机不启动,以防止以后遇到这类事情的时候找不到原因,然后关掉它 然后再运行ta
【Mysql进阶】5步玩转MySQL错误日志,你真的懂了吗?
通过以上五个步骤,相信你已经掌握了MySQL错误日志的使用技巧。错误日志是数据库故障排除的重要工具,通过分析日志,我们可以及时发现并解决各种问题,确保系统的稳定运行。下次遇到数据库问题时,不妨先从错误日志入手,或许你会有意想不到的收获哦!
MySQL进阶:深入解析MySQL错误日志
通过合理配置和使用MySQL的错误日志,我们可以及时发现和解决数据库运行中的问题,确保系统的稳定性和可靠性。错误日志不仅是数据库管理的重要工具,也是保障系统安全的有效手段。希望本文能帮助你更好地理解和利用MySQL错误日志,让你在数据库管理的道路上更进一步。🌟如果你有任何疑问或想要分享的经验,欢迎留言交流!💬通过上述内容,我们不仅介绍了MySQL错误日志的基本概念和用途,还详细说明了如何启用和配置错误日志,以及如何安全地管理和利用这些日志信息。
mysql启动错误之mysql启动报1067错误解决方法
解决方案: 1、在MY.INI文件中的 [mysqld] 中增加一行tmpdir=”D:/MySQL/data/”修改后,还是启动不了或者能启动但关机后又出现同样问题,接着我做了第二步,重启正常。 2、删除DATA目录下除数据库文件夹外的其他文件,重启mysql,问题解决。 您可能感兴趣的文章:mysql 启动错误1067 问题及解决方法mysql服务无法启动报错误1067解决方法(mysql启动错误1067 )MySQL启动错误解决方法
MySQL启动1053错误解决方法
操作系统:windows7 mysql版本:5.5.22 www.jb51.net 在使用命令mysqld –install servicename –defaults-file=’file_name’创建mysql服务时,系统 已提示创建服务成功,但是net start命令提示启动失败,并在services.msc中提示1053错误 解决办法: 在网上有人说是服务的“登录”选项卡里要设置成administrator; 也有人说是需要先把服务删除,在重新创建(可以先考虑这两方面); 但是试过以后发现不起作用,经过检查才发现原来还是由mysqld –install命令引起的,主要原因 在于–


