web-dev-qa-db-fra.com

MySQL restaure les données perdues après la mise à jour de 5.7 -> 8.0.11

J'ai un fichier docker-compose où j'utilise l'image officielle mysql:latest Comme serveur de base de données.

Après un docker pull mysql Et un docker-compose up L'image mise à jour à partir de 5.7 -> 8.0.11

Cette mise à jour a corrompu toutes mes données mysql.

Tous les fichiers .frm Ont été supprimés.

Lorsque j'essaye de redémarrer le serveur mysql, j'obtiens l'erreur suivante, même avec innodb_force_recovery [1-6]

2018-06-05T19:19:14.624533Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2018-06-05 19:19:14 0x7fd24a8b6740  InnoDB: Assertion failure in thread 140541170509632 in file ut0ut.cc line 942
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.
19:19:14 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=8388608
read_buffer_size=131072
-> Executing /opt/docker/provision/entrypoint.d/05-permissions.sh
max_used_connections=0
-> Executing /opt/docker/provision/entrypoint.d/20-nginx.sh
max_threads=151
-> Executing /opt/docker/provision/entrypoint.d/20-php-fpm.sh
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 = 68195 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
mysqld(my_print_stacktrace+0x2c)[0x55d85cb951ec]
mysqld(handle_fatal_signal+0x479)[0x55d85c4c3e59]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fd24a4940c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fd248c20fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fd248c2242a]
mysqld(+0x628387)[0x55d85c49a387]
mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55d85cd63c8d]
mysqld(+0xf9ead1)[0x55d85ce10ad1]
mysqld(+0xf9f108)[0x55d85ce11108]
mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55d85ce1a230]
mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55d85cdcf1ee]
mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55d85cd9e34a]
mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55d85cd41e23]
mysqld(+0x6274fb)[0x55d85c4994fb]
mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55d85cd0ecdd]
mysqld(+0xd69f63)[0x55d85cbdbf63]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55d85c50ebff]
mysqld(+0xb138e6)[0x55d85c9858e6]
mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55d85c988ad0]
mysqld(+0x64a566)[0x55d85c4bc566]
mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55d85c4be121]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fd248c0e2e1]
mysqld(_start+0x2a)[0x55d85c4b480a]
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.

J'ai cherché des solutions pour restaurer des données à partir de fichiers .ibd Existants, mais rien ne fonctionne.

Ce que j'ai essayé jusqu'à présent

Étant donné que j'ai une copie locale de la base de données, mais avec des données obsolètes, j'espérais pouvoir réimporter les données d'une manière ou d'une autre.

1. J'ai essayé de reconstruire la table et d'importer le fichier .ibd Dans l'espace de table:

  • Création d'une instance mysql distincte
  • CREATE DATABASE new_db; USE new_db;
  • CREATE TABLE wp_options(...) pour créer la structure de la table en fonction de mon vidage local que j'ai.
  • alter table wp_options discard tablespace
  • Copié le wp_options.ibd Que je souhaite restaurer dans le dossier new_db
  • alter table wp_options import tablespace.

Sur 5.7 Cela me donne l'erreur:

ERROR 1815 (HY000): Internal error: Cannot reset LSNs in table `dnmc`.`wp_options` : Unsupported``

Sur 8.0.11, Le serveur tombe en panne.

2. Créer un espace de table et l'affecter à la table

Je suis tombé sur celui-ci: https://www.percona.com/blog/2016/10/03/mysql-8-0-general-tablespaces-file-per-database-no-frm-files/

Je lance donc:

CREATE TABLESPACE wp_options ADD DATAFILE "/var/lib/mysql/dnmc_orig/wp_options.ibd" Engine=InnoDB;

ce qui me donne l'erreur suivante, à la fois sur 5.7 et 8.0.11.

ERROR 3121 (HY000): Incorrect File Name '/var/lib/mysql/dnmc_orig/wp_options.ibd'.
mysql-5.7mysql-8.0
5
ad_on_is

J'ai finalement réussi à restaurer les données. Mon problème était que j'ai essayé de restaurer les données avec un docker-compose, ce qui n'a pas fonctionné.

J'ai donc adopté une approche différente

1. Exécutez une image docker de mysql:8 et y a monté le dossier "corrompu" 

docker run -d -e MYSQL_ROOT_PASSWORD=root -v /path/to/corrupt/folder:/var/lib/mysql --name mrestore mysql:8

Le serveur mysql a démarré sans aucun problème et j'ai pu exécuter mysql avec

mysql -u root -p.

Mais quand j'exécute la commande mysql>show databases; Cela m'a donné une erreur comme:

The user specified as a definer ('mysql.infoschema'@'localhost') does not exist

2. Correction de l'utilisateur n'existe pas d'erreur

Une recherche rapide sur Google m'a conduit à la réponse de quelqu'un ayant le même problème: https://stackoverflow.com/questions/49992868/mysql-errorthe-user-specified-as-a-definer-mysql-infoschemalocalhost- biche

Lequel est:

mysql -u root -p
mysql> SET GLOBAL innodb_fast_shutdown = 1;
mysql_upgrade -u root -p

3. Vider la base de données

Enfin, j'ai pu démarrer mysql et vider la base de données que je pensais avoir perdue

mysqldump -u root -p databasename > databasename.sql
4
ad_on_is