INNODBは、すべてのデータベースを1つのファイルに保存するのはなぜですか?
質問
Myisamが各テーブルを対応するファイルに保存するのに使用したことは便利でした。 InnoDBは多くの面で進歩を遂げましたが、InnoDBがすべてのデータベースを1つのファイルに保存する理由を疑問に思います(ibdata1
デフォルト)。
INNODBは、テーブルの個々のインデックスファイルでファイル内のデータの場所をマッピングすることを理解していますが、1つのファイルにすべてのデータを混合する理由がわかりません。さらに重要なことは、なぜサーバー上のすべてのデータベースのデータを組み合わせるのですか?
MyISAMの興味深い機能は、データベースフォルダーを別のマシンにコピー/貼り付けてから、データベースを使用することができることです(ダンプなし)。
解決
InnoDBのアーキテクチャには、4つの基本タイプの情報ページの使用が要求されます
- テーブルデータページ
- テーブルインデックスページ
- テーブルメタデータ
- MVCC データ(トランザクションの分離をサポートするため 酸コンプライアンス)
- ロールバックセグメント
- スペースを元に戻します
- ダブル書き込みバッファー(OSキャッシングへの依存を防ぐためのバックグラウンドライティング)
- 挿入バッファー(非統一セカンダリインデックスへの変更の管理)
デフォルトでは、 innodb_file_per_table 無効になっています。これにより、4つの情報ページタイプすべてがIBDATA1と呼ばれる単一のファイルを配置します。多くの人々は、複数のIBDATAファイルを作成することでデータを広げようとします。これにより、データとインデックスページの断片化につながる可能性があります。
これが私がよくある理由です デフォルトのIBDATA1ファイルを使用して、INNODBインフラストラクチャをクリーンアップすることをお勧めします.
INNODBが機能するインフラストラクチャのため、コピーは非常に危険です。 2つの基本的なインフラストラクチャがあります
- innodb_file_per_table disabled
- innodb_file_per_table enabled
innodb(innodb_file_per_table 無効)
と innodb_file_per_table 無効になっている、これらすべてのタイプのInnodb情報はIBDATA1内でライブです。 IBDATA1以外のINNODBテーブルの唯一の症状は、INNODBテーブルの.FRMファイルです。すべてのINNODBデータを一度にコピーするには、/var/lib/mysqlのすべてをコピーする必要があります。
個々のINNODBテーブルをコピーすることはまったく不可能です。データの論理的表現とそれに対応するインデックス定義として、テーブルのダンプを抽出するには、MySQLダンプが必要です。その後、同じサーバーまたは別のサーバー上の別のデータベースにそのダンプをロードします。
innodb(innodb_file_per_table 有効)
と innodb_file_per_table 有効になっている、テーブルデータとそのインデックスは、.frmファイルの横にあるデータベースフォルダーに存在します。たとえば、テーブルDB1.Mytableの場合、IBDATA1以外のINNODBテーブルの顕現は次のとおりです。
/var/lib/mysql/db1/mytable.frm
/var/lib/mysql/db1/mytable.ibd
システムテーブルスペース ibdata1
db1.mytableのすべてのメタデータはまだibdata1にあり、 それを回避する方法はまったくありません. 。 REDO LOGSとMVCCデータもIBDATA1とともにライブしています。
テーブルの断片化に関しては、IBDATA1に起こることを次に示します。
- innodb_file_per_table 有効になっています: :db1.mytablesを縮小できます
ALTER TABLE db1.mytable ENGINE=InnoDB;
またOPTIMIZE TABLE db1.mytable;
. 。これにより、/var/lib/mysql/db1/mytable.ibdが断片化せずに物理的に小さくなります。 - innodb_file_per_table 無効: :db1.mytablesを縮小することはできません
ALTER TABLE db1.mytable ENGINE=InnoDB;
またOPTIMIZE TABLE db1.mytable;
IBDATA1が付いているからです。実際にどちらのコマンドを実行しても、テーブルを隣接してより速く読み書きします。残念ながら、それはIBDATA1の終わりに発生します。これにより、IBDATA1が急速に成長します。 これは、私のInnoDBクリーンアップ投稿で完全に対処されています.
警告(または危険として ロボットは、失われた宇宙で言うでしょう)
.frmおよび.ibdファイルをコピーするだけである場合、あなたは傷ついた世界に並んでいます。 Innodbテーブルの.frmおよび.ibdファイルをコピーするのは良いだけです .ibdファイルのテーブルスペースIDがIBDATA1ファイルのメタデータのテーブルスペースIDエントリと正確に一致することを保証できる場合のみ.
私はこのテーブルスペースIDコンセプトについてDBA stackexchangeに2つの投稿を書きました
- Innodbのテーブル圧縮? (見出しの下で「データベースの復元」)
- ファイルが動き回られたInnoDBテーブルを回復する方法
これは、不一致の表空間IDが発生した場合に、任意の.ibdファイルをIBDATA1に再接続する方法に関する優れたリンクを示します。 http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file. 。これを読んだ後、.ibdファイルをコピーすることは非常にクレイジーであるという即時の認識に来る必要があります。
innodbの場合、あなたはこれを移動するために何かをするだけで必要です
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
Innodbテーブルのコピーを作成します。
別のDBサーバーに移行している場合は、mysqldumpを使用してください。
すべてのデータベースからのすべてのINNODBテーブルの混合に関して、実際にそうすることで知恵を見ることができます。雇用主のDB/Webホスティング会社では、同じMySQLインスタンス内の別のデータベースの別のデータベースに制約がマッピングされた1つのデータベースにテーブルがあるMySQLクライアントが1つあります。 1つの一般的なメタデータリポジトリを使用すると、複数のデータベースでトランザクションサポートとMVCCの操作性を可能にします。
他のヒント
INNODBあたりのテーブルをCNFに追加することにより、InnoDBをファイルごとにテーブルを保存することができます。
InnoDBは、基本レベルでデータのページを本当に気にかけています。実際、InnoDBをセットアップして、ファイルシステムのない生のブロックデバイスのみを使用できます。 http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html
Optimizeを介して使用されたスペースをより簡単に取り戻すことができるなど、ファイル用のテーブルを保存するのに便利です。
テーブルごとにファイルがあっても、INNODBはトランザクションであり、グローバルに共有されたIBDATA/ログファイルにその状態に関する情報を保存するため、IBDファイルを簡単にコピーすることはできません。
それはそれができないと言うことではありません。テーブルがオフラインの場合は、テーブルスペースを破棄/インポートして、周囲に.idbsをコピーできます http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html
これはデフォルトの動作ですが、必須ではありません。から テーブルごとのテーブルスペースを使用したMySQLドキュメント:
デフォルトでは、すべてのINNODBテーブルとインデックスは、システムのテーブルスペースに保存されます。別の方法として、保存できます 独自のファイルにある各innodbテーブルとそのインデックス. 。この機能は、この設定が有効になっているときに作成された各テーブルに独自のテーブルスペースがあるため、「複数のテーブルスペース」と呼ばれます。
その理由については、理由はおそらく2つのエンジン(MyisamとInnodb)の異なるアーキテクチャです。たとえば、INNODBでは、.ibdファイルを別のデータベースまたはインストールにコピーするだけではありません。説明(同じページから):
.ibdファイルの移植性に関する考慮事項
MyISAMテーブルファイルを使用してできる限り、データベースディレクトリ間で.ibdファイルを自由に移動することはできません。 INNODB共有テーブルスペースに保存されているテーブル定義には、データベース名が含まれています。テーブルスペースファイルに保存されているトランザクションIDとログシーケンス番号もデータベース間で異なります。