giip
SES案件登録
Aurora MySQLbinlogレプリケーションCDCパラメータAurora

Aurora MySQLでbinlogの保持時間を確認・設定する方法

公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13

結論

Aurora MySQLのbinlog保持時間は、`CALL mysql.rds_show_configuration;` で確認し、`CALL mysql.rds_set_configuration('binlog retention hours', 24);` で設定します。単位は時間で、`NULL` や 0 ならRDSは不要と判断したbinlogを早期に削除します。DMSのCDCなどでbinlogを読む構成では、消費側が停止しても追いつける長さにしてください。あわせて `binlog_format` が `ROW` かも確認します。

この文書の適用条件

対象製品Aurora MySQL(MySQL互換エディション)
確認バージョンAurora MySQL 2.x(MySQL 5.7互換)/ 3.x(MySQL 8.0互換)。`SHOW MASTER STATUS` の可否はバージョンにより異なるため要確認
適用環境Amazon Aurora(AWS)
必要権限`mysql.rds_set_configuration` はRDSのマスターユーザー相当の権限が必要。`SHOW BINARY LOGS` は `REPLICATION CLIENT` 権限
実行影響確認系は影響なし。保持時間の変更は設定変更、`binlog_format` の変更は再起動を伴う、`PURGE BINARY LOGS` はログの削除
再起動保持時間の変更は不要。`binlog_format` の変更はライターインスタンスの再起動が必要
最終検証日2026-08-13

そのまま実行できるコマンド

現在のbinlog保持時間を確認する参照のみ
対象
Aurora MySQL 2.x / 3.x
権限
ストアドプロシージャの実行権限(通常はマスターユーザー)
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: mysql スキーマのストアドプロシージャ実行権限(通常はマスターユーザー)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
CALL mysql.rds_show_configuration;

`name` が `binlog retention hours` の行が保持時間です。値が `NULL` なら明示設定が無い状態で、RDSは不要と判断したbinlogを早期に削除します。同じ結果セットに他のRDS設定も含まれます。

binlogの現在の設定値を確認する参照のみ
対象
Aurora MySQL 2.x / 3.x
権限
接続権限(グローバル変数の参照)
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: 接続権限(グローバル変数の参照のみ)
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能
SELECT
    @@global.log_bin           AS log_bin_enabled,
    @@global.binlog_format     AS binlog_format,
    @@global.binlog_row_image  AS binlog_row_image,
    @@global.binlog_checksum   AS binlog_checksum;

Aurora MySQLでは `binlog_format` を `OFF` 以外に設定するとbinlogが有効になります。DMSのCDCや一般的なレプリケーションでは `ROW` が前提です。`binlog_row_image` が `MINIMAL` だと変更列以外の値が記録されず、CDC側で必要な情報が欠ける場合があります。

現存するbinlogファイルと位置を確認する参照のみ
対象
Aurora MySQL 2.x / 3.x(ライターインスタンス)
権限
`REPLICATION CLIENT` 権限
変更作業
なし(参照のみ)
Production実行
可能
-- 対象: Aurora MySQL 2.x / 3.x(ライターインスタンス)
-- 権限: REPLICATION CLIENT 権限
-- 変更作業: なし(参照のみ)
-- Production 実行: 可能

-- 1) 現存するbinlogファイルとサイズ
SHOW BINARY LOGS;

-- 2) 現在の書き込み位置(Aurora MySQL 3.x の一部バージョンでは
--    SHOW BINARY LOG STATUS に置き換えられているため、エラーになる場合はそちらを使う)
SHOW MASTER STATUS;

`SHOW BINARY LOGS` の合計サイズが保持時間の設定によって増減します。ファイル名はAurora MySQLでは `mysql-bin-changelog.NNNNNN` の形式です。`SHOW MASTER STATUS` はMySQL 8.0系の新しいバージョンで別名に置き換えられているため、実行できるかどうかは自環境で確認してください(要確認)。

binlog保持時間を設定する
対象
Aurora MySQL 2.x / 3.x
権限
RDSのマスターユーザー相当の権限(一般アプリケーションユーザーでは実行できない)
変更作業
あり(binlogの保持ポリシーの変更)
Production実行
可能。ただしストレージ消費が増えるため事前に見積もること
-- 対象: Aurora MySQL 2.x / 3.x
-- 権限: RDSのマスターユーザー相当(一般ユーザーではアクセス拒否になる)
-- 変更作業: あり(binlog の保持時間ポリシーを変更する)
-- Production 実行: 可能。ただしストレージ消費が増えるため事前に見積もること

-- 保持時間は「時間」単位で指定する(例: 24時間)
CALL mysql.rds_set_configuration('binlog retention hours', 24);

-- 設定後の値を確認する
CALL mysql.rds_show_configuration;

-- 明示設定を解除して既定の挙動(早期削除)に戻す場合
-- CALL mysql.rds_set_configuration('binlog retention hours', NULL);

第2引数は時間数です。日数ではありません。`NULL` を設定すると明示設定が解除され、RDSが不要と判断した時点でbinlogが削除されるようになります。設定を短くした直後は、まだ読み終えていないCDC消費側が追いつけなくなる可能性があるため、消費側の遅延を確認してから縮めてください。

binlog_format を ROW に変更する(再起動が必要)
対象
Aurora MySQL(DBクラスターパラメータグループ)
権限
IAM: `rds:ModifyDBClusterParameterGroup`, `rds:RebootDBInstance`
変更作業
あり(クラスターパラメータの変更 + ライターインスタンスの再起動)
Production実行
再起動を伴うため不可。メンテナンス時間帯に計画実行する
# 対象: Aurora MySQL(DBクラスターパラメータグループ)
# 権限: IAM rds:ModifyDBClusterParameterGroup, rds:RebootDBInstance
# 変更作業: あり(クラスターパラメータ変更 + ライターインスタンス再起動)
# Production 実行: 不可(再起動を伴うためメンテナンス時間帯に計画実行)

# 1) 現在値と反映方法を確認する
aws rds describe-db-cluster-parameters \
  --db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
  --query "Parameters[?ParameterName=='binlog_format' || ParameterName=='binlog_row_image'].{Name:ParameterName,Value:ParameterValue,Apply:ApplyType}" \
  --output table

# 2) binlog_format を ROW に変更する(クラスター単位のパラメータ)
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name example-aurora-mysql-cluster-params \
  --parameters '[
    {"ParameterName":"binlog_format","ParameterValue":"ROW","ApplyMethod":"pending-reboot"}
  ]'

# 3) ライターインスタンスを再起動して反映する(接続断が発生する)
aws rds reboot-db-instance --db-instance-identifier example-aurora-instance

`binlog_format` はDBクラスターパラメータグループ側の設定です。DBパラメータグループ(インスタンス単位)で探しても見つかりません。反映には再起動が必要で、接続断を伴います。binlogを有効にすると書き込み処理にログ生成の負荷が加わりますが、その大きさはワークロードによるため、事前に検証環境で計測してください(本記事では数値を示しません)。

古いbinlogを手動で削除する(最終手段)
対象
Aurora MySQL 2.x / 3.x(ライターインスタンス)
権限
MySQL 8.0互換では `BINLOG_ADMIN`、5.7互換では `SUPER` 相当。RDSではマスターユーザー
変更作業
あり(binlogファイルの削除。元に戻せない)
Production実行
原則不可。消費側の読み取り位置を確認してからのみ
-- 対象: Aurora MySQL 2.x / 3.x(ライターインスタンス)
-- 権限: MySQL 8.0互換は BINLOG_ADMIN、5.7互換は SUPER 相当(RDSではマスターユーザー)
-- 変更作業: あり(binlog ファイルを削除する。削除したログは復元できない)
-- Production 実行: 原則不可。全ての消費側の読み取り位置を確認してからのみ実施する

-- 1) 先に消費側(レプリカ・DMS・CDC)がどこまで読んでいるかを確認する
SHOW BINARY LOGS;

-- 2) 指定ファイルより前のbinlogを削除する
PURGE BINARY LOGS TO 'mysql-bin-changelog.000123';

-- 3) 日時指定で削除する場合
-- PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00';

まだ読み終えていない消費側があるファイルを削除すると、レプリケーションやCDCは復旧できず、初期ロードからのやり直しになります。RDS / Auroraではbinlogの寿命は原則として `binlog retention hours` で管理し、手動削除は「ストレージが逼迫していて他に手段が無い」場合の最終手段としてください。

結果の読み方

意味確認するポイント
name(rds_show_configuration)設定項目名`binlog retention hours` の行を探す
value(rds_show_configuration)設定値(時間数)`NULL` なら明示設定なし。CDC消費側の最大停止許容時間より長いか
description(rds_show_configuration)設定項目の説明単位が時間であることを確認できる
Log_name(SHOW BINARY LOGS)binlogファイル名Auroraでは `mysql-bin-changelog.NNNNNN` 形式。最も古いファイルが保持期間の下限を示す
File_size(SHOW BINARY LOGS)ファイルサイズ(バイト)合計値がストレージ消費量。保持時間を延ばす前に合計を見積もる
binlog_formatbinlogの記録形式DMSのCDCや一般的なレプリケーションでは `ROW` が必要
binlog_row_imageROW形式で記録する列の範囲`MINIMAL` だとCDC側で必要な列が欠ける場合がある

こういう状況で使います

  • DMSのCDCタスクが「binlogが見つからない」系のエラーで停止した
  • 外部レプリカを一度止めて再開したら、追いつけずエラーになった
  • binlogを有効にした後、クラスターのストレージ使用量が増え続けている
  • `CALL mysql.rds_set_configuration(...)` を実行したらアクセス拒否になった
  • DMSのエンドポイントテストで、binlog設定に関する警告が出る

考えられる原因(可能性の高い順)

  1. 01

    保持時間が明示設定されていない

    `binlog retention hours` が `NULL` の場合、RDSは不要と判断したbinlogを早期に削除します。CDC消費側が一時停止すると、再開時に必要なbinlogが既に無いことがあります。

  2. 02

    保持時間が消費側の停止時間より短い

    消費側(DMSタスク、外部レプリカ)が保守や障害で止まる時間より保持時間が短いと、再開時に追いつけません。停止許容時間から逆算して設定する必要があります。

  3. 03

    `binlog_format` が `ROW` になっていない

    `STATEMENT` や `MIXED` では、CDCが必要とする行単位の変更内容を取得できません。Auroraではクラスターパラメータグループで設定します。

  4. 04

    実行ユーザーにRDSのマスターユーザー相当の権限が無い

    `mysql.rds_set_configuration` はRDSが提供するストアドプロシージャで、実行にはマスターユーザー相当の権限が必要です。アプリケーション用の一般ユーザーではアクセス拒否になります。

  5. 05

    手動 `PURGE BINARY LOGS` で必要なログを消した

    消費側がまだ読んでいないファイルを削除すると復旧できません。ストレージ逼迫時の暫定対処として実行され、後から発覚することがあります。

  6. 06

    フェイルオーバーで書き込み先が切り替わった

    ライターが切り替わると、binlogのファイル名と位置の連続性を消費側がどう扱うかが問題になります。CDC側の再開方式を確認してください。

確認手順

  1. 1

    保持時間の現在値を確認する

    参照のみ

    `CALL mysql.rds_show_configuration;` を実行し、`binlog retention hours` の値を確認します。参照のみで安全です。

  2. 2

    binlogが有効かつROW形式かを確認する

    参照のみ

    `@@global.log_bin` と `@@global.binlog_format` を参照します。`binlog_row_image` も併せて確認します。

  3. 3

    現存するbinlogの範囲と合計サイズを確認する

    参照のみ

    `SHOW BINARY LOGS` で最も古いファイルと合計サイズを見ます。保持時間を延ばす前の見積りにも使えます。

  4. 4

    消費側の読み取り位置と遅延を確認する

    参照のみ

    DMSならタスクのCDC遅延メトリクス、外部レプリカならレプリカ側のステータスで、どこまで読み終えているかを確認します。

  5. 5

    CloudWatchでストレージ使用量の推移を確認する

    参照のみ

    保持時間を延ばした場合の増加分を、実際の推移から見積もります。

  6. 6

    実行ユーザーの権限を確認する

    参照のみ

    `SHOW GRANTS;` で、`mysql.rds_set_configuration` を実行できるユーザーかを確認します。

対応方法

すぐに実施できる低リスクの対応

  • マスターユーザーで保持時間を設定する

    一般ユーザーで権限エラーが出る場合、RDSのマスターユーザーで実行します。権限を一般ユーザーに付与するのではなく、実行するユーザーを変える方が安全です。

  • 消費側の停止許容時間から必要な保持時間を決める

    参照のみ

    「保守で何時間止まりうるか」「障害から復旧するまで何時間かかりうるか」を積み上げ、それより長い値を設定します。

事前検討が必要な変更

  • binlogのストレージ消費を監視対象に入れる

    参照のみ

    保持時間を延ばすと、その分binlogがストレージを消費します。`SHOW BINARY LOGS` の合計サイズとクラスターのストレージ使用量を定期的に確認してください。

  • CDC消費側の遅延を監視する

    参照のみ

    遅延が保持時間に近づいたら警告が出るようにしておくと、binlogが消えて復旧不能になる前に気づけます。

再起動・サービス影響を伴う変更

  • `binlog_format` を `ROW` に変更する

    クラスターパラメータグループで変更し、ライターインスタンスを再起動します。接続断を伴うため計画停止が必要です。

  • `PURGE BINARY LOGS` で古いログを削除する

    削除したログは戻せません。全ての消費側の読み取り位置を確認したうえで、最終手段としてのみ実施してください。

  • CDCを張り直す

    専門家レビュー必須

    binlogが失われて追いつけない場合、初期ロードからのやり直しになります。所要時間と切り替え計画を先に決めてください。

!注意事項

  • `binlog retention hours` の単位は時間です。日数のつもりで小さい値を設定すると、CDCが追いつけなくなります。
  • 保持時間を延ばすほどbinlogがストレージを消費します。必要な長さと消費量の両方を見積もってから設定してください。
  • `PURGE BINARY LOGS` は削除したログを復元できません。消費側の読み取り位置を確認せずに実行しないでください。
  • `binlog_format` の変更はライターインスタンスの再起動を伴います。無停止では反映できません。
  • `mysql.rds_set_configuration` はマスターユーザー相当の権限を要求します。権限エラーを回避するためにアプリケーションユーザーへ広い権限を付与するのは避けてください。
  • binlogを有効にすると書き込み側に追加の処理が発生します。影響の大きさはワークロード依存のため、本記事では数値を示しません。検証環境で計測してください。

バージョン・環境による違い

Aurora MySQL 2.x(MySQL 5.7互換)`PURGE BINARY LOGS` の実行には `SUPER` 相当の権限が必要です。`SHOW MASTER STATUS` はそのまま使えます。
Aurora MySQL 3.x(MySQL 8.0互換)binlog操作の権限は `BINLOG_ADMIN` などの動的権限に分離されています。`SHOW MASTER STATUS` は新しいバージョンで別名に置き換えられている場合があるため、自環境で実行可否を確認してください(要確認)。
クラスターパラメータとインスタンスパラメータの区別`binlog_format` はDBクラスターパラメータグループ側にあります。インスタンス単位のDBパラメータグループを探しても設定できません。

これで解決しない場合に確認すること

  • CDC消費側の再開位置の保持方法を確認する

    DMSやレプリカが読み取り位置をどこに保存し、フェイルオーバー後にどう再開するかを確認します。

  • クラスターのストレージ使用量の推移を確認する

    binlogだけでなく、一時領域やスナップショットも含めて増加要因を切り分けます。

  • バックアップ保持期間との関係を整理する

    binlogの保持とバックアップ保持は別の設定です。復旧要件に対してどちらがどこまで効くのかを整理してください。

  • マスターユーザーの管理方法を確認する

    マスターユーザーの資格情報の保管と利用手順を決めておかないと、必要なときに設定変更ができません。

  • binlogを読む消費側の一覧を作る

    DMS、外部レプリカ、変更通知の仕組みなど、binlogに依存しているものを洗い出しておくと、保持時間の判断が速くなります。

この文書の根拠と限界

製品の公式ドキュメントに基づく説明

Amazon RDS / Aurora の管理用ストアドプロシージャ `mysql.rds_show_configuration` / `mysql.rds_set_configuration`、MySQLのバイナリログ関連システム変数(`log_bin`、`binlog_format`、`binlog_row_image`)と `SHOW BINARY LOGS` / `PURGE BINARY LOGS` の公開仕様、およびAuroraのDBクラスターパラメータグループの公開仕様に基づきます。推奨保持時間やbinlog有効化による性能影響の数値は環境依存のため記載していません。

よくある質問

binlogの保持時間はどこで確認できますか?

`CALL mysql.rds_show_configuration;` を実行し、`binlog retention hours` の行を見ます。値が `NULL` なら明示的な設定が無く、RDSが不要と判断した時点で削除される状態です。

rds_set_configuration で権限エラーが出るのはなぜですか?

`mysql.rds_set_configuration` はRDSが提供する管理用ストアドプロシージャで、実行にはマスターユーザー相当の権限が必要だからです。アプリケーション用の一般ユーザーではアクセス拒否になります。一般ユーザーに権限を追加するのではなく、マスターユーザーで実行してください。

Productionで実行できますか?

確認系(`rds_show_configuration`、`SHOW BINARY LOGS`、グローバル変数の参照)は本番で実行できます。保持時間の変更はストレージ消費が増えるため見積りが必要で、`binlog_format` の変更は再起動を伴うため計画停止が必要です。`PURGE BINARY LOGS` は原則として本番で実行しないでください。

保持時間はどれくらいに設定すればよいですか?

一般的な推奨値ではなく、消費側の停止許容時間から決めます。「CDCが止まってから復旧するまでに最大どれくらいかかるか」を見積もり、それより十分に長い値を設定してください。長くするほどストレージを消費します。

binlog_format を変更するのに再起動は必要ですか?

必要です。`binlog_format` はDBクラスターパラメータグループの設定で、反映にはライターインスタンスの再起動が必要です。接続断を伴うため、メンテナンス時間帯に実施してください。

結果をどう判断しますか?

`binlog retention hours` が消費側の最大停止時間より短ければ設定不足です。`SHOW BINARY LOGS` の最も古いファイルの時刻が、消費側の読み取り位置より新しくなっていれば、既に追いつけない状態です。この場合は設定変更では回復せず、初期ロードからのやり直しになります。

この文書がカバーする質問

  • rds_set_configuration で権限エラーが出る
  • DMSのCDCでbinlogが見つからないと言われる
  • Aurora MySQLでbinlogを有効にしたい
  • binlogがストレージを圧迫している

リスク表示の意味

  • 参照のみデータと設定を変更しません。
  • 影響は限定的ですが、権限と負荷の確認が必要です。
  • 性能・ロック・コストに影響する可能性があります。
  • 障害・データ損失・復旧作業が発生する可能性があります。
  • 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

binlogの保持時間は「一度設定して忘れる」設定になりがちですが、実際にはCDC消費側の構成が変わるたびに妥当性が変わります。GIIPでは、保持時間の設定値・現存binlogの合計サイズ・CDC側の遅延を同じ画面で追えるようにし、遅延が保持時間に近づいた段階で通知するようにしています。binlogの削除や `binlog_format` の変更のように取り返しがつかない操作は自動化の対象から外し、必ず人の承認を通す設計にしています。

執筆・技術検証

GIIP プロダクション運用チーム

大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。

関連するナレッジ

関連サービス

binlog保持とCDC構成の点検を依頼する

同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。

binlog保持とCDC構成の点検を依頼する

ナレッジベース一覧へ