web-dev-qa-db-ja.com

MySQLデータベースがダンプ/インポート後に大きくなるのはなぜですか?

2つのVPSがあり、最初から2番目にDBを移行する予定です。元のDBは約15 GBのストレージを使用しており、7 GBのSQLをダンプすることができました。ただし、SQLを2番目のVPSにインポートすると、ストレージが2倍になり、32GBになります。

私の質問は:

  • ダンプ+インポートだけで、DBが15 GBから32 GBになるのはなぜですか?
  • どうすればこれを回避できますか?

以下に詳細をいくつか示します。

  • 両方のVPSは完全に同じではなく、MySQLバージョンも同じです。ソースDBはバージョン5.5.47です。受信DBはバージョン5.7.13です。
  • 受信DBは新しくインストールされ、空です。
  • SQLをダンプするために使用したコマンドは、mysqldump -u <username> -p --all-databases --add-drop-database --max_allowed_packet=16777216 --single-transaction > full_dump.sqlです。 max_allowed_pa​​cketを設定している理由は、受信DBと同じ値を持つためです
  • これが適切かどうかはわかりません。 mysqldumpコマンドでsingle-transactionを指定しないと、エラーが発生しますmysqldump: Got error: 2006: MySQL server has gone away when using LOCK TABLES
  • ソースDBストレージの分散は、受信DBとは異なります:

    14858M/var/lib/mysql

    14483M/var/lib/mysql/ibdata1

    365M/var/lib/mysql/wordpress

  • これは受信DBストレージの分布です:

    31558M/var/lib/mysql

    31306M/var/lib/mysql/wordpress

    337M /var/lib/mysql/wordpress/wp_wfLeechers.ibd

    101M /var/lib/mysql/wordpress/wp_1059_posts.ibd

  • テーブルの最適化を実行しようとしましたが、影響はありません
4
Kenaz Chan

最初に目にしたのは、使用しているMySQLのバージョンです。

あなたが言った

  • ソースDBはバージョン5.5.47です
  • 受信DBはバージョン5.7.13です。

MySQLのこれら2つのバージョンは、innodb_file_formatに異なるデフォルト値を使用します

MySQL 5.7には、 Documentation で説明されているように、InnoDBを格納する新しい方法があります。ご注意ください:

Barracuda ファイル形式は、圧縮または動的行形式と、圧縮、大きな変数のページ外ストレージなどの関連機能を使用するために必要です-length columns、および大きなインデックスキープレフィックス(innodb_large_prefixを参照)。この制限は、一般的なテーブルスペースに格納されているテーブルには適用されません。

データに大きな可変長の列がある場合、再読み込みの結果として、BTreeインデックスの外部にデータとインデックス情報が格納され、ページがさらに分割される可能性があります。 これの詳細については、DYNAMICおよびCOMPRESSED行フォーマットを参照してください 。新しいInnoDBファイル形式機能の多くはMySQL 5.7で非推奨になり、将来のリリースでは最終的にはなくなる予定です。

提案#1

非推奨ですが、MySQL 5.7サーバーで innodb_file_format をAntelopeに設定し、MySQLを再起動して、mysqldumpをリロードできます。

提案#2

MySQL 5.7の代わりにMySQL 5.5/5.6をマスターとして使用します。マスターでMySQLを再起動し、mysqldumpをマスターにリロードします。

提案#3

すべてのMySQL 5.7 InnoDBテーブルでALTER TABLE innodbtable ROW_FORMAT=COMPRESSED;を実行します。

試してみる !!!

2
RolandoMySQLDBA

おそらく古いテーブルはMyISAMでした。 (行う SHOW CREATE TABLEまたはダンプ内を覗いてください。)また、新しいテーブルはInnoDBにする必要がありました。

長い目で見れば、この変化は良いことです。

このような変更では、2倍のサイズの増加が予想されます。

0
Rick James