MySQL 服务无法启动。服务没有报告任何错误。
5个回答
展开全部
MySQL数据库在升级到5.7版本后,和之前的版本有些不一样,没有data文件夹,我们都知道MySQL数据库文件是保存在data文件夹中的,网上有人说把5.6版本的data文件夹拷贝一个,这种说法听听都不靠谱,我也试了,确实能够登录,但是无法修改管理员密码,下面还是给个标准的解决方法。
安装好MySQL5.7后,打开cmd命令窗口,并且进入到MySQL安装目录中的bin目录,然后输入如下命令回车即可:
mysqld --initialize-insecure --user=mysql
执行完上面命令后,MySQL会自建一个data文件夹,并且建好默认数据库,登录的用户名为root,密码为空,后面的操作就跟之前版本一样了
安装好MySQL5.7后,打开cmd命令窗口,并且进入到MySQL安装目录中的bin目录,然后输入如下命令回车即可:
mysqld --initialize-insecure --user=mysql
执行完上面命令后,MySQL会自建一个data文件夹,并且建好默认数据库,登录的用户名为root,密码为空,后面的操作就跟之前版本一样了
本回答被网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
慧咨环球
2024-02-09 广告
2024-02-09 广告
选择一个适合自己公司的仓库管理系统需要考虑以下几个因素:1. 公司的业务需求:不同公司的业务需求不同,需要选择适合自己业务需求的仓库管理系统。例如,有些公司需要管理多个仓库,有些公司需要管理拣货和打包等操作,有些公司需要管理库存和采购等环节...
点击进入详情页
本回答由慧咨环球提供
展开全部
先删除 mysql 下的data文件夹 然后 mysqld --initialize (初始化)
这样做完全正确。。。
这样做完全正确。。。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
我遇到同样的错误,折腾了好久才摸索出来。网上的解决办法都试过了,没有确实可行的。最终总结出来,终于解决了。
我的下载的是mysql-5.7.9绿色版出的问题。最终解决过程供你参考:
1、下载的mysql-5.7.9,出现你的问题。试了各种办法无法解决。有网友说mysql-5.7.9版本有问题。我改下载了5.6.27版本,尝试不成功。但报错变为:无法启动mysql服务,发生错误1067。解决办法:my.ini 添加 tmpdir = D:\mysql-5.6.27-winx64\data。问题解决。
2、后来我对比了mysql-5.7.9与5.6.27,发现mysql-5.7.9-winx64没有data目录,mysql-5.6.27-winx64\data\mysql,存了不少数据文件。原来调试5.7.9的版本时,记得日志报告一直有mysql.user、mysql.plugin不存在的提示。(原以为这些文件会自动生成)。后来把这个mysql-5.6.27-winx64\data下的mysql文件夹整个复制到5.7.9版本中的同目录下。问题解决。
我的下载的是mysql-5.7.9绿色版出的问题。最终解决过程供你参考:
1、下载的mysql-5.7.9,出现你的问题。试了各种办法无法解决。有网友说mysql-5.7.9版本有问题。我改下载了5.6.27版本,尝试不成功。但报错变为:无法启动mysql服务,发生错误1067。解决办法:my.ini 添加 tmpdir = D:\mysql-5.6.27-winx64\data。问题解决。
2、后来我对比了mysql-5.7.9与5.6.27,发现mysql-5.7.9-winx64没有data目录,mysql-5.6.27-winx64\data\mysql,存了不少数据文件。原来调试5.7.9的版本时,记得日志报告一直有mysql.user、mysql.plugin不存在的提示。(原以为这些文件会自动生成)。后来把这个mysql-5.6.27-winx64\data下的mysql文件夹整个复制到5.7.9版本中的同目录下。问题解决。
本回答被提问者和网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
2021-01-11 · MySQL开源数据库领先者
关注
展开全部
故障处理
移除当前使用的 redo log 文件,然后可以试着启动数据库,结果启动失败!
提示:
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
这样的错误,这是因为 MySQL writer 线程按照配置的时间间隔以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候,新写入磁盘的 page 包含了较新的 LSN,此时系统 system 表空间头的 LSN 并没有同步更新,通常这是检查点线程的工作。在正常的崩溃恢复中,MySQL 可以借助 redo log 来进行前滚和回滚,但是此时 redo log 已经被我们删掉了,MySQL 无法进行恢复操作。此时,我们设置 innodb_force_recovery=3 来强制启动 MySQL,仍然启动不成功,改成 4 后启动了!
再使用 mysqldump 导出备份,结果噩梦又降临了!MySQL 又 crash 了。
提示:
InnDB: Failed to find tablespace for table......
设置参数 innodb_force_recovery=5,数据库仍然启动失败,再设置成 6,启动成功!用 sqldump 顺利把数据备份出来了!
再初始化数据库,把刚刚备份的数据库导入,数据库恢复成功完成!
参数说明
这里的关键是设置 innodb_force_recovery 参数,对应这个参数的说明如下:
1. SRV_FORCE_IGNORE_CORRUPT:忽略检查到的 corrupt 页;
2. SRV_FORCE_NO_BACKGROUND:阻止主线程的运行,如主线程需要执行 full purge 操作,会导致 crash;
3. SRV_FORCE_NO_TRX_UNDO:不执行事务回滚操作;
4. SRV_FORCE_NO_IBUF_MERGE:不执行插入缓冲的合并操作;
5. SRV_FORCE_NO_UNDO_LOG_SCAN:不查看重做日志,InnoDB 存储引擎会将未提交的事务视为已提交;
6. SRV_FORCE_NO_LOG_REDO:不执行前滚的操作。
移除当前使用的 redo log 文件,然后可以试着启动数据库,结果启动失败!
提示:
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
这样的错误,这是因为 MySQL writer 线程按照配置的时间间隔以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候,新写入磁盘的 page 包含了较新的 LSN,此时系统 system 表空间头的 LSN 并没有同步更新,通常这是检查点线程的工作。在正常的崩溃恢复中,MySQL 可以借助 redo log 来进行前滚和回滚,但是此时 redo log 已经被我们删掉了,MySQL 无法进行恢复操作。此时,我们设置 innodb_force_recovery=3 来强制启动 MySQL,仍然启动不成功,改成 4 后启动了!
再使用 mysqldump 导出备份,结果噩梦又降临了!MySQL 又 crash 了。
提示:
InnDB: Failed to find tablespace for table......
设置参数 innodb_force_recovery=5,数据库仍然启动失败,再设置成 6,启动成功!用 sqldump 顺利把数据备份出来了!
再初始化数据库,把刚刚备份的数据库导入,数据库恢复成功完成!
参数说明
这里的关键是设置 innodb_force_recovery 参数,对应这个参数的说明如下:
1. SRV_FORCE_IGNORE_CORRUPT:忽略检查到的 corrupt 页;
2. SRV_FORCE_NO_BACKGROUND:阻止主线程的运行,如主线程需要执行 full purge 操作,会导致 crash;
3. SRV_FORCE_NO_TRX_UNDO:不执行事务回滚操作;
4. SRV_FORCE_NO_IBUF_MERGE:不执行插入缓冲的合并操作;
5. SRV_FORCE_NO_UNDO_LOG_SCAN:不查看重做日志,InnoDB 存储引擎会将未提交的事务视为已提交;
6. SRV_FORCE_NO_LOG_REDO:不执行前滚的操作。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询