私の目標は、私のoptディレクトリの記憶領域を取り戻すことです。定期的なメンテナンスチェックにより、スペースが必要なときにサイズを小さくできるようにサイズを増やしたいと思います。
muttからメールを削除する前に、次のディスクサイズ出力が表示されます（省略）。
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 38314216 12189488 24155376 34% /
/dev/sda3 144053404 133666076 3046736 98% /opt
192.168.1.161:/home 237256704 51089408 175959040 23% /opt/www/etl/sftp-homes
オプティカルドライブスペースが不足している（上記の通り）：
だから私は以前の電子メール（ロギング）を削除してそれを使用しました。
>mutt
shift + D
~d>4m
q
muttはそのファイルを削除する操作を実行しているように見えるので、これはmuttで動作しているようです。しかし、dfは私にスペースを提供せず、まだ同じです。 muttがファイルサイズを保存して再起動する必要があるかもしれません。 ？ ？それとも、データベースのサイズを確保するためにmariadbを再起動/クリーンアップする必要がありますか？ ？ ？それともCentosを再起動する必要がありますか？ ？ ？ （極端に見える）そのディスクスペースをどのように再利用できますか？それともここに別のクリーニングソリューションがありますか？
ちなみに、muttを再起動する方法が見つかりませんか？そしてmariadbを再起動しても機能しません。ほとんどのファイルはibdata1に保存されます。
答え1
これはmariadbの問題のようです。
https://stackoverflow.com/questions/3456159/how-to-shrink-purge-ibdata1-file-in-mysql
https://www.thegeekstuff.com/2016/02/mysql-innodb-file-per-table/
同じ問題がここで詳細に説明されていますが、難しすぎます。基本的な大規模なMySQLシステムテーブルスペースアプローチには1つの主な欠点があります。
次のシナリオを考えてみましょう。 MySQLの複数のテーブルに100GBのデータをアップロードしました。
ibdata1ファイルのサイズは約100 GB以上になります。
# cd /var/lib/mysql
# ls -lh ibdata1
-rw-r-----. 1 mysql mysql 101G Jan 21 21:10 ibdata1
数日後、これらすべてのテーブルから約50 GBのデータを削除します。 ibdata1ファイルサイズは約50GB以上に縮小せず、約100GB以上に保たれます。
上記のシナリオでは、後でテーブルに 10 GB のデータを追加すると、ibdata1 ファイルのサイズは 110 GB に増やすことなく 100 GB のままになります。なぜなら、ファイルには上記の50 GBの削除データ内にまだ使用されていない領域があるからです。
問題は、ibdata1ファイルから50 GBのデータを削除した後、未使用のスペースを回復できないことです。これを行う方法がありますが、複雑すぎてMySQLデータベースをシャットダウンし、すべてのテーブルを削除するなどの作業が必要です。