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_packetを設定している理由は、受信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
- テーブルの最適化を実行しようとしましたが、影響はありません
最初に目にしたのは、使用している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;
を実行します。
試してみる !!!
おそらく古いテーブルはMyISAMでした。 (行う SHOW CREATE TABLE
またはダンプ内を覗いてください。)また、新しいテーブルはInnoDBにする必要がありました。
長い目で見れば、この変化は良いことです。
このような変更では、2倍のサイズの増加が予想されます。