データベース・ファイルによるMySQLデータのリカバリ
2372 ワード
このテーマは変に見えますが、問題は説明しにくくありません.サーバーの元のデータベースバージョンはMySQL 5です.1、いくつかの需要のため、データベースのバージョンをアップグレードする必要がありますが、アップグレードする前に、アプリケーションのデータベースをエクスポートするのを忘れて、データベースをMySQL 5にアップグレードします.6以降、元の5.1データベースサーバを上書きした後、このアプリケーションのデータがエクスポートされていないことに気づいた.したがって、5.1データベースのファイル(my.cnfでdatadirを検索するパス)だけが、データベースのsqlファイルをどのようにエクスポートするかという問題があります.sqlファイルをエクスポートした後、5.6のデータベースでやり直します.
Datadirのパスの下には、次のような構造があります.
既存のアプリケーションに影響を及ぼさないようにMySQL 5を1台選択しました.1バージョンの新しいマシンでリカバリします.そして当然abcdフォルダcopyを新しいマシン対応のdatadirに入れたい.
MySQLでmysql-serverに接続すると、show databasesでabcdのデータベースが表示され、abcdを選択してshow tablesを利用すると、a,b,cの3つのテーブルが表示されます.
しかし、残念ながら、テーブルにselectリクエストを行うと、table name not exist;うっとうしい.
しかし、datadirにはabcdとefghに対応するフォルダのほかにibdataなどのデータしか残っていないことを考えると、ibdataなどのデータは格納されたデータベースのデータだと推測し、いっそibdata 1と2つのlogファイルをすべて新しいマシンのdatadirディレクトリにコピーし、奇跡が起こり、データをselectすることができます.もちろん、mysqldumpでデータベースをsqlファイルにエクスポートし、5.6のMySQLでデータベースを再作成できます.Done!
しかし、ibdata 1と2つのlogファイルはいったい何なのか、恐ろしいことを思い出しました.まさかすべてのデータベースのデータはすべて1つのファイルの中に保存しますか??これは恐ろしくて、しかも私の認識を完全に覆して、もし主ならば、その分庫の意義は何ですか.だからこの問題は必ずはっきりさせなければならない.
根据frmファイルの説明では、frmはメタデータなどを含むテーブルの構造情報のみを格納することを知っています.frmはデータベースストレージエンジンとは関係ありません.つまり、インデックスとデータはストレージエンジンに関連しているため、テーブルのインデックス、データとは関係ありません.ではMyISAMエンジンは分かりやすいです.MYDはデータファイル、MYIはインデックスファイルです.ではInnodbにとっては?プライマリ・キーはクラスタ・インデックスであり、データと直接格納されていることがわかります.では、どこへ行きましたか.
『MySQL技術内幕』という本の紹介によると、innodbには表空間の概念が存在し、上の5.1の組織構造では、表空間を共有するフォーマットで、データを1つのファイルに格納し、ibdata 1を紹介し、ibdata 1はストレージエンジンに関連し、innodbストレージエンジンの下にしか現れず、mysql-serverのすべてのinnodbストレージエンジンの表である.データベースを問わずibdata 1に格納されます.もちろん、インデックスなどの他の情報も格納されます.MySQLでinnodb_を開くとfile_per_tableの後、各データベースに対応するフォルダの下に、各テーブルに2つの対応ファイルが存在し、1つは.frm、もう一つは.ibdファイル.この場合はプライベートテーブルスペースになります.しかしこのとき共有テーブル空間ibdata 1は,依然として存在する.でも、どうしてこんなデザインをするのか、よくわかりません..
ib_logfile 0とib_logfile 1は同じで、innodbによって生成されたREDOログです.この2つのファイルは同じで、2つあるのは、1つのファイルが破損した後、MySQL crash以降、innodbがデータを復元できないことを避けるためです.
Datadirのパスの下には、次のような構造があります.
|-
|-ibdata1
|-ib_logfile0
|-ib_logfile1
|-abcd( )
|-a.frm
|-b.frm
|-c.frm
|-efgh( )既存のアプリケーションに影響を及ぼさないようにMySQL 5を1台選択しました.1バージョンの新しいマシンでリカバリします.そして当然abcdフォルダcopyを新しいマシン対応のdatadirに入れたい.
MySQLでmysql-serverに接続すると、show databasesでabcdのデータベースが表示され、abcdを選択してshow tablesを利用すると、a,b,cの3つのテーブルが表示されます.
しかし、残念ながら、テーブルにselectリクエストを行うと、table name not exist;うっとうしい.
しかし、datadirにはabcdとefghに対応するフォルダのほかにibdataなどのデータしか残っていないことを考えると、ibdataなどのデータは格納されたデータベースのデータだと推測し、いっそibdata 1と2つのlogファイルをすべて新しいマシンのdatadirディレクトリにコピーし、奇跡が起こり、データをselectすることができます.もちろん、mysqldumpでデータベースをsqlファイルにエクスポートし、5.6のMySQLでデータベースを再作成できます.Done!
しかし、ibdata 1と2つのlogファイルはいったい何なのか、恐ろしいことを思い出しました.まさかすべてのデータベースのデータはすべて1つのファイルの中に保存しますか??これは恐ろしくて、しかも私の認識を完全に覆して、もし主ならば、その分庫の意義は何ですか.だからこの問題は必ずはっきりさせなければならない.
根据frmファイルの説明では、frmはメタデータなどを含むテーブルの構造情報のみを格納することを知っています.frmはデータベースストレージエンジンとは関係ありません.つまり、インデックスとデータはストレージエンジンに関連しているため、テーブルのインデックス、データとは関係ありません.ではMyISAMエンジンは分かりやすいです.MYDはデータファイル、MYIはインデックスファイルです.ではInnodbにとっては?プライマリ・キーはクラスタ・インデックスであり、データと直接格納されていることがわかります.では、どこへ行きましたか.
『MySQL技術内幕』という本の紹介によると、innodbには表空間の概念が存在し、上の5.1の組織構造では、表空間を共有するフォーマットで、データを1つのファイルに格納し、ibdata 1を紹介し、ibdata 1はストレージエンジンに関連し、innodbストレージエンジンの下にしか現れず、mysql-serverのすべてのinnodbストレージエンジンの表である.データベースを問わずibdata 1に格納されます.もちろん、インデックスなどの他の情報も格納されます.MySQLでinnodb_を開くとfile_per_tableの後、各データベースに対応するフォルダの下に、各テーブルに2つの対応ファイルが存在し、1つは.frm、もう一つは.ibdファイル.この場合はプライベートテーブルスペースになります.しかしこのとき共有テーブル空間ibdata 1は,依然として存在する.でも、どうしてこんなデザインをするのか、よくわかりません..
ib_logfile 0とib_logfile 1は同じで、innodbによって生成されたREDOログです.この2つのファイルは同じで、2つあるのは、1つのファイルが破損した後、MySQL crash以降、innodbがデータを復元できないことを避けるためです.