【问题标题】:Can't start mysql after downgrade, can't run mysql_upgrade, can't change root password降级后无法启动mysql,无法运行mysql_upgrade,无法更改root密码
【发布时间】:2016-12-08 03:57:41
【问题描述】:

我将 mysql 服务器从 5.7.14 降级到 5.6.32。

这样做之后,我假设我应该按照我遇到的说明运行 mysql_upgrade。

但是,为此,我需要提供我拥有的 root 用户/p。但是,当我尝试这样做时,它似乎不接受那些:

mysql_upgrade -u root -p

输入密码:

寻找“mysql”为:mysql

寻找“mysqlcheck”为:mysqlcheck

错误:获取服务器版本失败!可能是由于未经授权的访问。

致命错误:升级失败

所以我尝试通过创建一个类似以下内容的初始化文件来重置密码: 为'root'@'localhost'设置密码=密码('abcd1234'); 然后用 mysqld_safe --init-file=/home/root/mysql-init &

调用它

但是这个好像不行,大概是因为mysql无法正确启动而抛出错误。

0802 12:50:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

2016-08-02 12:50:46 0 [Warning] TIMESTAMP with implicit DEFAULT value is 

2016-08-02 12:50:46 0 [Note] /usr/sbin/mysqld (mysqld 5.6.32) starting as process 2635 ...

2016-08-02 12:50:46 2635 [Note] Plugin 'FEDERATED' is disabled.

/usr/sbin/mysqld: Unknown storage engine 'InnoDB'

2016-08-02 12:50:46 2635 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.

2016-08-02 12:50:46 2635 [Note] InnoDB: Using atomics to ref count buffer pool pages

2016-08-02 12:50:46 2635 [Note] InnoDB: The InnoDB memory heap is disabled

2016-08-02 12:50:46 2635 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins

2016-08-02 12:50:46 2635 [Note] InnoDB: Memory barrier is not used

2016-08-02 12:50:46 2635 [Note] InnoDB: Compressed tables use zlib 1.2.3

2016-08-02 12:50:46 2635 [Note] InnoDB: Using Linux native AIO

2016-08-02 12:50:46 2635 [Note] InnoDB: Using CPU crc32 instructions

2016-08-02 12:50:46 2635 [Note] InnoDB: Initializing buffer pool, size = 128.0M

2016-08-02 12:50:46 2635 [Note] InnoDB: Completed initialization of buffer pool

2016-08-02 12:50:46 2635 [Note] InnoDB: Highest supported file format is Barracuda.

2016-08-02 12:50:46 2635 [Note] InnoDB: The log sequence numbers 2512357 and 

2512357 in ibdata files do not match the log sequence number 2512396 in $

2016-08-02 12:50:46 2635 [Note] InnoDB: Database was not shutdown normally!

2016-08-02 12:50:46 2635 [Note] InnoDB: Starting crash recovery.

2016-08-02 12:50:46 2635 [Note] InnoDB: Reading tablespace information from the .ibd files...

2016-08-02 12:50:46 2635 [Note] InnoDB: Restoring possible half-written data pages

2016-08-02 12:50:46 2635 [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
17:50:46 UTC - mysqld got signal 11 ;

这似乎让我陷入了一个循环,我无法运行 mysql_upgrade 来升级数据库,但我无法成功重置 root 密码(尽管我 99.9% 确定我有正确的 root密码,它似乎不接受它。)

堆栈跟踪..

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+0x35)[0x8e2375]

/usr/sbin/mysqld(handle_fatal_signal+0x494)[0x666da4]

/lib64/libpthread.so.0[0x398620f790]

/usr/sbin/mysqld[0xac1017]

/usr/sbin/mysqld[0xac25fd]

/usr/sbin/mysqld[0xa3de77]

/usr/sbin/mysqld[0x9822dd]

/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5aa958]

/usr/sbin/mysqld[0x6f01e1]

/usr/sbin/mysqld(_Z11plugin_initPiPPci+0xbb6)[0x6f4046]

/usr/sbin/mysqld[0x59ce38]

/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x425)[0x5a2055]

/lib64/libc.so.6(__libc_start_main+0xfd)[0x3985e1ed5d]

/usr/sbin/mysqld[0x593ba5]

有什么建议吗?谢谢

【问题讨论】:

  • 信号 11 是一个段错误......这意味着你有某种内存访问冲突。也许是链接问题,错误地解决了包依赖关系?

标签: mysql


【解决方案1】:

您遇到的指示完全错误。唯一重要的说明是那些from MySQL

支持的降级方式包括:

就地降级:涉及关闭新的 MySQL 版本,用旧的替换新的 MySQL 二进制文件或包,并在现有数据目录上重新启动旧的 MySQL 版本。 同一发行系列中的 GA 版本之间的降级支持就地降级。例如,从 5.7.10 降级到 5.7.9 支持就地降级。

逻辑降级:涉及使用mysqldump 转储新 MySQL 版本中的所有表,然后将转储文件加载到旧 MySQL 版本中。 支持逻辑降级,用于同一发行系列中的 GA 版本之间的降级以及版本级别之间的降级。 例如,从 5.7.10 降级到 5.7.9 以及从 5.7 降级时支持逻辑降级到 5.6。

有关过程,请参阅Performing an In-place DowngradePerforming a Logical Downgrade

注意我的粗体。您唯一受支持的选项是使用mysqldump 提取数据库的副本,然后将其导入旧版本。希望你有一些备份!

【讨论】:

  • 是的,我就是从那里得到指示的。但是,我试图进行就地降级而不是逻辑降级。我能够恢复 5.7.14 组件,并尝试逻辑降级的操作。但是,这也不起作用,因为这个更改:dba.stackexchange.com/questions/136320/… 最终,我不得不在降级、恢复、从跳过表开始、然后重新创建表、读取用户和重新授予权限之后对 mysql.user 表进行核对。这是有趣的一天。
【解决方案2】:

我试图进行就地降级而不是逻辑降级。

我能够恢复 5.7.14 组件,并尝试逻辑降级的操作。

但是,这也不起作用,因为this 更改为用户表结构。最终,我不得不在降级、恢复、使用 skip-grant-tables 选项启动服务后对 mysql.user 表进行核对,然后重新创建表、重新添加我的用户并重新授予权限。这是愉快的一天。

【讨论】:

    猜你喜欢
    • 2019-08-10
    • 2021-04-23
    • 2020-06-07
    • 1970-01-01
    • 2012-01-27
    • 2012-10-12
    • 2013-09-06
    • 2016-10-13
    • 1970-01-01
    相关资源
    最近更新 更多