MySQLのbinlog（バイナリログ）は、データを変更した操作を時系列で記録するログで、レプリケーションと「特定時点への復旧」の土台になります。この記事では、binlog が有効かどうかの確認、ファイル一覧と中身の読み方、保持期間とディスク容量の管理、WordPress サイトでの活用場面までを順に説明します。復旧手順そのものを深掘りするのではなく、日常の確認と運用設定に焦点を当てます。
binlogに記録されるもの・されないもの
binlog には、INSERT・UPDATE・DELETE や CREATE TABLE など、データや構造を変更する操作が記録されます。SELECT のような読み取りだけの操作は記録されません。誰がどのページを見たかを調べるログではなく、「データベースに何が書き込まれたか」の履歴です。
用途は主に次の3つです。
- レプリケーション: ソース（旧称マスター）の binlog をレプリカが受け取り、同じ変更を再生します。
- ポイントインタイムリカバリ: 夜間のフルバックアップを戻したあと、binlog を再生して障害直前の状態まで近づけます。
- 変更の調査: 「いつ、どのテーブルの行が消えたか」を後から追う手がかりになります。
binlogが有効か確認する
まず現在の設定を確認します。MySQL 8.0 以降は binlog が既定で有効、MySQL 5.7 以前や MariaDB は既定で無効です（2026年10月現在）。ただし、パッケージやホスティング事業者の設定で変わっていることがあるため、実際の値を見るのが確実性の高い方法です。
SHOW VARIABLES LIKE 'log_bin%';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';log_bin が ON なら有効です。log_bin_basename には保存先とファイル名の接頭辞が表示されます。MySQL 8.0 で名前を指定していない場合、データディレクトリに binlog.000001 のような連番ファイルと、一覧を管理する binlog.index が作られます。
無効だった場合は、設定ファイル（my.cnf や mysqld.cnf など、環境で場所が異なります）に次のように書き、MySQL を再起動します。再起動はサイトが一時停止するため、アクセスの少ない時間帯に、バックアップを取ってから行ってください。
[mysqld]
server_id = 1
log_bin = /var/lib/mysql/binlog
binlog_expire_logs_seconds = 604800 # 7日server_id はレプリケーションで各サーバーを区別する番号で、binlog を使うなら明示しておくと後で困りません。
なお、Amazon RDS などのマネージドサービスでは、binlog は自動バックアップの設定と連動し、保持期間もサービス独自の方法で設定します。共用のレンタルサーバーでは、利用者が binlog の設定やファイルに触れられないことが一般的です。手順は各サービスのドキュメントを確認してください。
binlogの一覧と現在位置を見る
ファイルの一覧とサイズは SHOW BINARY LOGS; で確認できます。現在書き込み中のファイル名と位置を知るには、MySQL 8.4 以降では SHOW BINARY LOG STATUS; を使います。8.0 系では従来の SHOW MASTER STATUS; が使えますが、8.4 で廃止されています。MariaDB では SHOW MASTER STATUS; が引き続き使えます（2026年10月現在）。
SHOW BINARY LOGS;
SHOW BINARY LOG STATUS; -- MySQL 8.0 系では SHOW MASTER STATUS;SQL から直接イベントを覗くこともできます。大量に出力されるので、LIMIT を付けるのが無難です。
SHOW BINLOG EVENTS IN 'binlog.000012' LIMIT 20;mysqlbinlogで中身を読む
詳しく読むには、MySQL に付属する mysqlbinlog コマンドを使います（MariaDB では mariadb-binlog という名前が使われます）。binlog の形式が ROW（現在の既定）の場合、行の変更はバイナリで記録されているため、そのままでは読めません。--base64-output=DECODE-ROWS と -v（または -vv）を付けると、擬似的な SQL として表示されます。
# 時刻で範囲を絞って表示する例
sudo mysqlbinlog --base64-output=DECODE-ROWS -vv \
--start-datetime="2026-10-27 09:00:00" \
--stop-datetime="2026-10-27 10:00:00" \
/var/lib/mysql/binlog.000012 | less読み方のポイントは次のとおりです。
# at 12345の数字がイベントの位置（ポジション）で、復旧時に「ここまで再生する」と指定する目印になります。### DELETE FROM wordpress_db.wp_postsのような行のあとに、@1=@2=の形で列の値が並びます。列名ではなく列の順番で表示される点に注意してください。--start-datetimeなどの時刻は、mysqlbinlogを実行したマシンのタイムゾーンで解釈されます。サーバーが UTC で動いている場合は時刻のずれに気を付けます。
binlog には投稿内容やユーザー情報も含まれます。ファイルを手元にコピーして調べる場合は、個人情報を含むデータとして扱い、作業後に削除してください。
保持期間とディスク容量を管理する
binlog は放っておくと増え続け、ディスクを使い切ると MySQL が書き込めなくなり、WordPress のデータベース接続エラーにつながります。容量管理は binlog 運用の要です。
MySQL 8.0 以降の保持期間は binlog_expire_logs_seconds で秒単位に指定し、既定は30日です。古い expire_logs_days は 8.0 で非推奨になり、新しいバージョンでは削除されています。設定ファイルに書くほか、実行中のサーバーには次のように反映できます。
SET PERSIST binlog_expire_logs_seconds = 604800; -- 7日手動で整理する場合は、OS の rm でファイルを消してはいけません。binlog.index との整合が崩れ、レプリケーションや起動に影響します。PURGE BINARY LOGS を使います。
PURGE BINARY LOGS TO 'binlog.000010'; -- 000010 より前を削除
PURGE BINARY LOGS BEFORE '2026-10-01 00:00:00';レプリカがある構成では、レプリカがまだ読み終えていないファイルを消すと同期が止まります。各レプリカで SHOW REPLICA STATUS を確認し、読んでいるファイルより前だけを削除してください。保持期間は「フルバックアップの間隔より長く」が目安で、毎日バックアップなら最低でも数日分を残しておくと、バックアップの失敗が1回あっても復旧の道が残ります。
1ファイルの最大サイズは max_binlog_size（既定 1GB）で決まり、超えると次の番号に切り替わります。FLUSH BINARY LOGS; で手動で切り替えることもできます。
WordPressサイトでの活用場面
WordPress は、ページを表示するだけでもトランジェントや予約実行（WP-Cron）の情報を wp_options に書き込むことがあり、アクセス数のわりに binlog が大きくなる場合があります。容量が急に増えたら、mysqlbinlog の出力からどのテーブルへの書き込みが多いかを数えると、原因のプラグインや処理を絞り込めます。
sudo mysqlbinlog --base64-output=DECODE-ROWS -v /var/lib/mysql/binlog.000012 \
| grep -oE '### (INSERT INTO|UPDATE|DELETE FROM) [^ ]+' | sort | uniq -c | sort -rn | head誤って記事を一括削除した、プラグインの不具合でデータが書き換わった、といった場合には、binlog から該当時刻と位置を特定し、フルバックアップと組み合わせて直前の状態に戻せる可能性があります。このとき mysqldump --single-transaction --source-data=2（8.0.26 より前は --master-data=2）でダンプを取っておくと、ダンプに binlog の開始位置がコメントとして記録され、どこから再生すればよいかが分かります。
復旧作業は本番に直接行わず、別のサーバーやステージングで再生して結果を確認してから切り替えるのが安全です。
まとめ
- binlog はデータを変更した操作の履歴で、レプリケーションと特定時点への復旧に使う
SHOW VARIABLES LIKE 'log_bin%';で有効か確認する。MySQL 8.0 以降は既定で有効、MariaDB は既定で無効- 一覧は
SHOW BINARY LOGS、現在位置は 8.4 以降SHOW BINARY LOG STATUS（8.0 系はSHOW MASTER STATUS） - 中身は
mysqlbinlog --base64-output=DECODE-ROWS -vvで読み、時刻・位置で範囲を絞る。個人情報を含むため扱いに注意 - 保持期間は
binlog_expire_logs_secondsで設定し、手動削除はPURGE BINARY LOGSを使う。rmは使わない - 設定変更や復旧の前にはバックアップを取り、ステージングで手順を確認する