Início / dba / Perguntas / 209295
Accepted
ad_on_is
Asked: 2018-06-12 05:18:39 +0800 CST

MySQL restaura dados perdidos após atualização de 5.7 -> 8.0.11

  • 772

Eu tenho um arquivo docker-compose onde uso a mysql:latestimagem oficial como meu servidor de banco de dados.

Após a docker pull mysqle docker-compose upa imagem atualizada de 5.7 -> 8.0.11

Esta atualização corrompeu todos os meus dados mysql.

Todos os .frmarquivos foram deletados.

Quando tento reiniciar o servidor mysql recebo o seguinte erro, mesmo cominnodb_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.

Procurei soluções de como restaurar dados de .ibdarquivos existentes, mas nada funciona.

O que eu tentei até agora

Como tenho uma cópia local do banco de dados, mas com dados desatualizados, esperava poder reimportar os dados de alguma forma.

1. Tentei reconstruir a tabela e importar o .ibdarquivo para o tablespace:

  • Criou uma instância separada do mysql
  • CREATE DATABASE new_db; USE new_db;
  • CREATE TABLE wp_options(...)para criar a estrutura da tabela com base no meu dump local que tenho.
  • alter table wp_options discard tablespace
  • Copiei o wp_options.ibdque eu quero restaurar na new_dbpasta
  • alter table wp_options import tablespace.

Nele 5.7me dá o erro:

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

No 8.0.11servidor apenas trava.

2. Crie um espaço de tabela e atribua-o à tabela

Me deparei com este: https://www.percona.com/blog/2016/10/03/mysql-8-0-general-tablespaces-file-per-database-no-frm-files/

Então eu corro:

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

o que me dá o seguinte erro, tanto on 5.7quanto 8.0.11.

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

1 respostas

  1. Best Answer

    Finalmente consegui restaurar os dados com sucesso. Meu problema foi que tentei restaurar os dados com um docker-compose, que de alguma forma não funcionou.

    Então eu tomei uma abordagem diferente

    1. Execute uma imagem do docker mysql:8e monte a pasta "corrupt" nela

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

    O servidor mysql foi iniciado sem problemas e consegui executar o mysql com

    mysql -u root -p.

    Mas quando eu executo o comando mysql>show databases;, ele me deu um erro como:

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

    2. Corrigir o erro de usuário não existente

    Uma rápida pesquisa no google me levou à resposta de alguém com o mesmo problema: https://stackoverflow.com/questions/49992868/mysql-errorthe-user-specified-as-a-definer-mysql-infoschemalocalhost-doe

    Qual é:

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

    3. Despejar banco de dados

    Finalmente consegui iniciar o mysql e despejar o banco de dados que pensei ter perdido

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

relate perguntas