web-dev-qa-db-ja.com

MySQLデータベースは、ダンプファイルに対してどのくらいの大きさになりますか？

MySQLデータベースに〜52GBのダンプを復元しています。 ibdata1ファイルはすでにダンプファイルのサイズを超えており、復元はまだ不完全です。 MySQLダンプファイルのサイズがわかっている場合、ibdata1ファイルの最終的なサイズを見積もる方法はありますか？

mysqlinnodbrestore
7
aetodd

あなたの質問の言葉だけから、私は以下のことを疑っています：おそらく innodb_file_per_table が無効になっています。

注：次の情報は、無効になっているinnodb_file_per_tableに基づいています

InnoDBテーブルにデータを挿入すると、すべてとその祖母がibdata1として知られるシステムテーブルスペースファイルに配置されます。 ibdata1には実際には何が含まれていますか？

  • テーブルデータ
  • テーブルインデックス
  • メタデータ
  • MVCC情報

最初にibdata1を膨らませている間のテーブルデータとインデックス。メタデータは、単にデータディクショナリ+テーブルごとに割り当てられたtablespace_idsのリストです。

MVCC（Multiversioning Concurrency Control） はどうですか？これは、トランザクションの分離、ロールバック、元に戻すログ、secondayrインデックスの挿入バッファー、および二重書き込みバッファーをサポートするように設計されたsystremオブジェクトを表します。

InnoDBインフラストラクチャをクリーンアップする必要があります。私はすでにこれを行う方法と理由についてStackExchangeの投稿を書いています。

元の質問に戻りますが、リロード時にibdata1のサイズを推定する唯一の方法は、mysqldumpの前にこのクエリを実行することでした。

SELECT
    data_length/power(1024,3) InnoDBData,
    index_length/power(1024,3) InnoDBIndexes,
    (data_length+index_length)/power(1024,3) InnoDBSize
FROM
    information_schema.tables
WHERE
    engine='InnoDB';

これにより、データのサイズがGBで報告されます。 ibdata1を新たにリロードすると（innodb_file_per_tableが無効になっている場合）、これがサイズ見積もりの​​経験則でした。

ダンプファイルのサイズからは、データページとインデックスページの合計サイズの合計が、ダンプの作成元のibdata1のサイズよりもはるかに小さいため、判断が困難です。その違いは、MVCCシステムオブジェクト（ロールバックセグメント、元に戻すログ、二重書き込みバッファー、セカンダリインデックス挿入バッファー）の肥大化によるスペースの残りになります。別の見方をすると、データページはインデックスページよりも多く、逆もまた同様です。これは、インデックスが多すぎるか、デザインが悪いか、またはデータの量が適切であることが原因である可能性があります。

6
RolandoMySQLDBA