web-dev-qa-db-ja.com

大量のスペースを使用するmysqldump

サーバーがあり、/パーティションのサイズは20GBです。

データベースは/mnt/mysql-dataパーティションに保存され、サイズは500GBです。

ここに問題があります。 mysqldumpを実行すると、/パーティションが100％いっぱいになります。すでにtmpdirを/mnt/mysql-data/tmpに移動しました。私のデータベースは全体で約40 GBですが、/mnt/mysql-data/backupsでバックアップしたいのですが、/パーティションが100％までいっぱいになるため、続行できません。私のmysqldumpコマンドは次のとおりです：mysqldump --all-databases > /mnt/s3share/backup.sql";

サーバーの詳細：

  • 10.2.22-MariaDB-log MariaDBサーバー

  • CentOS Linuxリリース7.7.1908（コア）

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        7.8G     0  7.8G   0% /dev
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           7.8G  217M  7.6G   3% /run
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
/dev/xvda2       24G  2.4G   20G  11% /
/dev/xvda1      976M  168M  757M  19% /boot
tmpfs           1.6G     0  1.6G   0% /run/user/1000
/dev/xvdc1      500G  123G  378G  25% /mnt/mysql-data
tmpfs           1.6G     0  1.6G   0% /run/user/1001

MariaDB [db_inbox]> show global variables like "%tmp%";
+----------------------------+----------------------+  
| Variable_name              | Value                |  
+----------------------------+----------------------+  
| default_tmp_storage_engine |                      |  
| encrypt_tmp_disk_tables    | OFF                  |  
| encrypt_tmp_files          | OFF                  |  
| innodb_tmpdir              |                      |  
| max_tmp_tables             | 32                   |  
| slave_load_tmpdir          | /mnt/mysql-data/tmp  |  
| tmp_disk_table_size        | 18446744073709551615 |  
| tmp_memory_table_size      | 16777216             |  
| tmp_table_size             | 16777216             |  
| tmpdir                     | /mnt/mysql-data/tmp  |  
+----------------------------+----------------------+  
10 rows in set (0.00 sec)

更新＃1：

*.sqlバックアップが/mnt/s3share/backups/としてマウントされているs3fsフォルダーに書き込まれ、そのキャッシュが/tmpに書き込まれている必要があることを忘れました。これが、理由である可能性があります。 SQLダンプの作成中に/がいっぱいになります。ただし、バックアップを実行して/tmpの変更を監視すると、成長が見られません。 /tmpでlsofコマンドを実行すると、巨大なファイルが削除されているのがわかります。これでいいの？

mysqlamazon-s3mariadbs3fsmysqldump
1
Christian Noel

OK、s3bucketキャッシュディレクトリを/tmpから/mnt/mysql-data/tmpに移動することで、この問題を解決することができました。

Fuse.s3fsが/tmpに書き込んでいて、du -h /tmpを使用してどのファイルが成長しているかを追跡する方法がないことを私はほとんど知りませんでした。

私が実行していたコードはmysqldump --all-databases > /mnt/s3share/backup.sqlで、s3shareはFuse.s3fsを使用してマウントされ、/tmpをターゲットとするキャッシュディレクトリがあります。これが、mysqldumpがルート/で増大するすべてのストレージ使用を引き起こしていると私が思った理由です。

Fuse.s3fsのキャッシュディレクトリを/mnt/mysql-data/tmpに変更した後、問題は解決しました。

これは/tmpの前の私のマウントコマンドでした：

datastore /mnt/s3share Fuse _netdev,allow_other,use_cache=/tmp,passwd_file=$PASSWDFILE 0 0

次に、これは新しいマウントコマンド/mnt/mysql-data/tmpです：

datastore /mnt/s3share Fuse _netdev,allow_other,use_cache=/mnt/mysql-data/tmp,passwd_file=$PASSWDFILE 0 0

1
Christian Noel

Innodb_％変数とdatadirを見てください。テーブルスペースのようなものがまだどこかにある可能性があります。

それができない場合は、mysqldumpの実行中にduを使用してルート膨張が発生するディレクトリを確認してください。

1
Gordan Bobic