centos 7-MySQL5.7重新安装损坏的数据

disbfnqx  于 2021-06-23  发布在  Mysql
关注(0)|答案(0)|浏览(304)

我有一个安装了directadmin的centos 7虚拟机。它曾经运行MySQL5.6安装,使用DirectAdminCustomBuild2.0构建。我想要一些MySQL5.6中没有的功能(比如json操作),所以我使用上的指南从MySQL5.7中手动安装了MySQL5.7https://www.tecmint.com/install-latest-mysql-on-rhel-centos-and-fedora/.
直到几天前,当我需要重新构建custombuild安装时,它工作得还不错,而且显然是用5.6版重写了mysql安装。我没有备份数据库(我知道,真的很愚蠢,我很后悔)。
在custombuild覆盖之后,我使用相同的指南重新安装了mysql 5.7。当我现在尝试启动它时,我得到以下结果:

  1. [riccardo@server ~]$ sudo systemctl start mysqld
  2. [sudo] password for riccardo:
  3. Job for mysqld.service failed because the control process exited with
  4. error code. See "systemctl status mysqld.service" and "journalctl
  5. -xe" for details.

登录/var/log/mysqld.log时会显示以下内容:

  1. 2018-05-27T17:42:02.769069Z 0 [Warning] TIMESTAMP with implicit
  2. DEFAULT value is deprecated. Please use
  3. --explicit_defaults_for_timestamp server option (see documentation for
  4. more details).
  5. 2018-05-27T17:42:02.770667Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.22)
  6. starting as process 31752 ...
  7. 2018-05-27T17:42:02.773699Z 0 [Note] InnoDB: PUNCH HOLE support
  8. available
  9. 2018-05-27T17:42:02.773726Z 0 [Note] InnoDB: Mutexes and rw_locks use
  10. GCC atomic builtins
  11. 2018-05-27T17:42:02.773731Z 0 [Note] InnoDB: Uses event mutexes
  12. 2018-05-27T17:42:02.773734Z 0 [Note] InnoDB: GCC builtin
  13. __atomic_thread_fence() is used for memory barrier
  14. 2018-05-27T17:42:02.773739Z 0 [Note] InnoDB: Compressed tables use
  15. zlib 1.2.3
  16. 2018-05-27T17:42:02.773742Z 0 [Note] InnoDB: Using Linux native AIO
  17. 2018-05-27T17:42:02.773999Z 0 [Note] InnoDB: Number of pools: 1
  18. 2018-05-27T17:42:02.774100Z 0 [Note] InnoDB: Using CPU crc32
  19. instructions
  20. 2018-05-27T17:42:02.775492Z 0 [Note] InnoDB: Initializing buffer pool,
  21. total size = 128M, instances = 1, chunk size = 128M
  22. 2018-05-27T17:42:02.783306Z 0 [Note] InnoDB: Completed initialization
  23. of buffer pool
  24. 2018-05-27T17:42:02.786037Z 0 [Note] InnoDB: If the mysqld execution
  25. user is authorized, page cleaner thread priority can be changed. See
  26. the man page of setpriority().
  27. 2018-05-27T17:42:02.797885Z 0 [ERROR] [FATAL] InnoDB: Table flags are
  28. 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
  29. 2018-05-27 19:42:02 0x7efd82b32740 InnoDB: Assertion failure in
  30. thread 139627284604736 in file ut0ut.cc line 942

因此,看起来innodb数据已损坏。我试着开始使用

  1. [mysqld]
  2. innodb_force_recovery = x

在/etc/my.cnf中,x的值为1-6。这没用。至于我的问题:有没有可能在mysql的帮助下恢复数据?

暂无答案!

目前还没有任何答案,快来回答吧!

相关问题