web-dev-qa-db-ja.com

MySQLは5.7からのアップデート後に失われたデータを復元します-> 8.0.11

データベースサーバーとして公式の_mysql:latest_イメージを使用するdocker-composeファイルがあります。

_docker pull mysql_と_docker-compose up_の後、画像は5.7-> 8.0.11から更新されます

この更新により、すべてのmysqlデータが破損しました。

すべての_.frm_ファイルが削除されました。

Mysql-serverを再起動しようとすると、_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.
_

既存の_.ibd_ファイルからデータを復元する方法を探しましたが、何も機能しません。

これまでに試したこと

私はデータベースのローカルコピーを持っていますが、データが古いため、なんとかしてデータを再インポートできることを望んでいました。

1。テーブルを再構築し、_.ibd_ファイルをテーブルスペースにインポートしようとしました：

  • 別のmysqlインスタンスを作成しました
  • _CREATE DATABASE new_db; USE new_db;_
  • CREATE TABLE wp_options(...)を使用して、ローカルダンプに基づいてテーブルの構造を作成します。
  • _alter table wp_options discard tablespace_
  • _wp_options.ibd_フォルダーに復元したい_new_db_をコピーしました
  • _alter table wp_options import tablespace_。

_5.7_では、エラーが発生します。

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

_8.0.11_では、サーバーがクラッシュします。

2。テーブルスペースを作成し、それをテーブルに割り当てます

私はこれに遭遇しました： https://www.percona.com/blog/2016/10/03/mysql-8-0-general-tablespaces-file-per-database-no-frm-files/

だから私は走る：

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

_5.7_と_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

ようやくデータの復元に成功しました。私の問題は、docker-composeを使用してデータを復元しようとしたが、どういうわけか機能しなかったことでした。

だから私は別のアプローチをとりました

1。 mysql:8のDockerイメージを実行し、「破損した」フォルダーをマウントします

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

Mysql-serverは問題なく起動し、mysqlを

mysql -u root -p。

しかし、コマンドmysql>show databases;を実行すると、次のようなエラーが発生しました。

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

2。ユーザーが存在しないというエラーを修正する

簡単なグーグル検索は私に同じ問題を抱えている誰かの答えに導きました： https://stackoverflow.com/questions/49992868/mysql-errorthe-user-specified-as-a-definer-mysql-infoschemalocalhost- doe

それは：

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

3。データベースのダンプ

最後に、mysqlを起動して、失ったと思ったデータベースをダンプすることができました

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