👻

MySQLバイナリログ削除によるディスク容量の解放

shimadama

2025/04/02に公開

MySQL

tech

 MySQLのバイナリログを理解して容量問題を解決する突然のディスク容量不足に悩まされていませんか？MySQLを使った開発環境で「なぜかストレージがいっぱい」という経験をした方は多いはず。今回はその主犯格となりうる「バイナリログ」について徹底解説し、容量問題を根本から解決する方法をご紹介します。

 問題の発見から解決まで：調査過程
 最初の症状ある日、通常通り開発作業をしていると突然ビルドが失敗し始めました：
[webpack-cli] [Error: ENOSPC: no space left on device, write] {
  errno: -28,
  code: 'ENOSPC',
  syscall: 'write'
}
これはディスク容量不足を示すエラーです。何が起きているのか調べてみることにしました。

 ディスク使用量の確認まず、基本的なディスク使用量確認コマンドを実行しました：
df -h
結果は衝撃的でした：
Filesystem        Size    Used   Avail Capacity iused  ifree %iused  Mounted on
/dev/disk3s3s1   460Gi    10Gi    39Mi   100%    412k   403k   50%   /
/dev/disk3s1     460Gi   441Gi    39Mi   100%    1.9M   403k   83%   /System/Volumes/Data
... 省略 ...
特に注目すべきは、/System/Volumes/Dataパーティションが441GBも使用しており、わずか39MBしか空き容量がないことです！macOSではこのパーティションにユーザーデータが保存されるため、これがアプリケーションのエラーの原因です。

 大きなファイルの特定次に、どのファイルが容量を占有しているのか調査しました：
sudo find / -type f -size +100M | sort -nr
このコマンドは、100MB以上のファイルを探し出します。しかし結果は膨大で、すぐには原因を特定できませんでした。

 システムデータの分析macOSのストレージ管理画面を確認すると、「システムデータ」が380GB以上を占めていることが判明：
システムデータの内訳を確認するため、さらに調査を進めました。

 MySQLのデータディレクトリ調査開発環境ではMySQLを使っていたため、そのデータディレクトリを確認してみました：
du -sh /opt/homebrew/var/mysql
結果、MySQLのデータディレクトリが約350GB使用していることが判明しました。異常です！

 犯人の特定：バイナリログファイルMySQLディレクトリ内の詳細を確認すると、大量の「binlog」ファイルが存在することが分かりました：
find /opt/homebrew/var/mysql -name "binlog.*" -ls
結果：
-rw-r----- 1 user staff 1.0G binlog.000543
-rw-r----- 1 user staff 1.0G binlog.000544
...（さらに数十個のファイル）
各ファイルが約1GBで、合計70GB以上のディスク容量を消費していました！さらに調査を続けると、MySQLのバイナリログが自動的に生成され続け、過去数か月間蓄積されていたことが分かりました。

 原因の理解調査の結果、これらのファイルはMySQLのバイナリログと呼ばれるもので、データベースの変更操作を記録するために使われることが分かりました。本番環境では重要な機能ですが、開発環境では不要なものでした。
デフォルトでは1GBごとに新しいログファイルが作成され、自動削除の設定がなければ際限なく蓄積されていくのです。

 バイナリログとは？バイナリログ（binary log）はMySQLのデータベース変更操作を記録するファイルです。具体的には：
データの挿入、更新、削除などの操作
テーブル構造の変更（CREATE TABLE, ALTER TABLEなど）
その他データに影響を与える操作
これらの操作がバイナリログに時系列で記録されます。ファイル名は通常 binlog.000001, binlog.000002 のように連番形式です。

 なぜバイナリログは必要なの？本番環境では、バイナリログは以下の重要な目的で使用されます：

レプリケーション（複製）: マスターサーバーからスレーブサーバーへのデータ同期

Point-in-Timeリカバリ: 特定時点までのデータベース復元

監査: データ変更の追跡

 開発環境での問題点本番環境では重要なバイナリログですが、ローカル開発環境では多くの場合不要です。なぜなら：
レプリケーションを使用していない
細かい時点へのリカバリが必要ない
バックアップ戦略が異なる
それにも関わらず、デフォルトでは有効化されているため、知らないうちに大量のディスク容量を消費します。

 実際のインパクト私の環境では、次のようなコマンドで巨大なバイナリログファイルを発見しました：
sudo find /opt/homebrew/var/mysql -name "binlog.*" -type f -ls
または macOS の場合：
sudo find /System/Volumes/Data/opt/homebrew/var/mysql -name "binlog.*" -type f -ls
結果は衝撃的でした：
-rw-r----- 1 user staff 1.0G binlog.000543
-rw-r----- 1 user staff 1.0G binlog.000544
...（さらに数十個のファイル）
各ファイルが約1GBで、合計70GB以上のディスク容量を消費していました！

 解決策：2ステップアプローチ
 ステップ1：既存バイナリログを削除まず、既存のバイナリログファイルを削除します：
# MySQLを停止
brew services stop mysql

# バイナリログファイルを削除
# パスはお使いの環境に合わせて調整してください
rm /opt/homebrew/var/mysql/binlog.0*
rm /opt/homebrew/var/mysql/binlog.index

# macOSでの一般的なパス
# rm /System/Volumes/Data/opt/homebrew/var/mysql/binlog.0*
# rm /System/Volumes/Data/opt/homebrew/var/mysql/binlog.index

# MySQLを再起動
brew services start mysql
注意: この操作は本番環境では絶対に行わないでください！開発環境限定の操作です。本番環境ではバックアップ戦略に基づいた適切な管理が必要です。

 ステップ2：バイナリログを無効化次に、今後バイナリログが生成されないように設定を変更します：
MySQL設定ファイルを編集：
sudo vim /opt/homebrew/etc/my.cnf
以下の設定を [mysqld] セクションに追加：
[mysqld]
# その他の設定...

# バイナリログを無効化
disable-log-bin
MySQLを再起動：
brew services restart mysql

 設定の確認正しく設定されたか確認するには：
mysql> SHOW VARIABLES LIKE 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
OFF と表示されていれば成功です！

 バイナリログが作成されるタイミングバイナリログはいつ作成されるのでしょうか？主に次のタイミングです：

データ変更操作時: INSERTやUPDATEなどの操作が実行されるたび

ファイルサイズ制限到達時: デフォルトでは1GBに達すると新ファイル作成

MySQLサーバー再起動時: 再起動の度に新しいログファイル作成
特にデータベースのリストア操作後、アプリケーションのテスト実行などで大量のデータ操作が行われると、知らないうちに大量のバイナリログが生成されることがあります。

 この対策は誰に有効？
個人開発者: ラップトップの貴重なSSD容量を節約

チーム開発: 新メンバーのセットアップ時にハマりがちな問題を予防

CI/CD環境: テスト環境のディスク容量問題を解消

 驚きの効果：容量が大幅に減少！バイナリログファイルを削除し、機能を無効化した結果は驚くべきものでした：
なんと使用容量が 494.06 GB から 213.57 GB へ と、約 280 GB も削減することができました！これは単純なファイル削除だけで達成できる劇的な改善です。

 まとめMySQLのバイナリログは本番環境では重要な機能ですが、開発環境では不要なディスク容量の消費につながります。今回紹介した2つのステップで：
既存のバイナリログファイルを削除
バイナリログ機能を無効化
これにより、開発環境のディスク容量問題を効果的に解決できます。
ディスク容量に余裕ができると、開発作業もストレスフリーに。「なぜか容量不足」という謎の問題に悩まされている方は、ぜひバイナリログをチェックしてみてください！
これがあなたの開発環境を救う簡単な対策です。皆さんのお役に立てれば幸いです。質問やコメントがあれば、ぜひ下のコメント欄でお知らせください。
本記事の設定は開発環境向けです。本番環境ではバイナリログが重要な役割を持つため、無効化は推奨しません。

株式会社GroovesPublication

Grooves所属メンバーの個人発信をまとめたPublicationです。記事内容はあくまでも個人の見解であり、会社としてレビュー等はしておりません。あらかじめご了承ください。

MySQLのバイナリログを理解して容量問題を解決する

問題の発見から解決まで：調査過程

最初の症状

ディスク使用量の確認

大きなファイルの特定

システムデータの分析

MySQLのデータディレクトリ調査

犯人の特定：バイナリログファイル

原因の理解

バイナリログとは？

なぜバイナリログは必要なの？

開発環境での問題点

実際のインパクト

解決策：2ステップアプローチ

ステップ1：既存バイナリログを削除

ステップ2：バイナリログを無効化

設定の確認

バイナリログが作成されるタイミング

この対策は誰に有効？

驚きの効果：容量が大幅に減少！

まとめ

Discussion