メインコンテンツへスキップ

VillageSQL is a drop-in replacement for MySQL with extensions.

All examples on this page work on VillageSQL. Install Now →
MySQL のバイナリログは、データベースに対するすべての変更(挿入、更新、削除、スキーマ変更)を記録します。レプリケーションとポイントインタイムリカバリの基盤です。ほとんどの本番 MySQL サーバーは、バイナリログを有効にして動作しています。

バイナリログの有効化

MySQL 8.0 ではバイナリログはデフォルトで有効です。確認するには次のようにします。
my.cnf / my.ini で構成します。
log_bin を設定すると、MySQL は binlog ファイルに mysql-bin.000001、mysql-bin.000002 のような名前を付け、それらすべてを列挙するインデックスファイル(mysql-bin.index)を作成します。

バイナリログの形式

MySQL は 3 つの binlog 形式をサポートしています。 ROW 形式が推奨されるデフォルトです。RAND() や UUID() のような非決定的な関数が関係していても正しくレプリケートされます。欠点はログファイルが大きくなることです。数百万行に影響する 1 つの UPDATE は、STATEMENT 形式では 1 つのステートメントになりますが、ROW 形式では影響を受けた行ごとに 1 つの行イベントになります。

バイナリログを有効にすべき場面と選ぶべき形式

MySQL 8.0 以降ではバイナリログはデフォルトで有効です。問題になるのはたいてい、どの形式を使うか、そしてそもそも有効のままにしておくかどうかです。 形式の確認と変更は次のようにします。

バイナリログの一覧表示と閲覧

すべてのバイナリログファイルを一覧表示します。
現在の binlog ファイルと位置を確認します。
SQL から binlog 内のイベントを閲覧します。

mysqlbinlog

mysqlbinlog ツールは、バイナリログファイルを人が読める SQL にデコードします。ポイントインタイムリカバリと監査に使われます。

ポイントインタイムリカバリ

フルバックアップとバイナリログを組み合わせると、バックアップ取得後の任意の時点に復元できます。 典型的なワークフロー:
  1. mysqldump --single-transaction --source-data でフルバックアップを取ります。
--source-data=2 は、binlog のファイル名と位置をダンプ内にコメントとして書き込みます。これが復旧の開始点です。
  1. フルバックアップを復元します。
  1. ダンプから binlog のファイルと位置を探します。
  1. その位置から、取り消したいイベントの直前まで binlog を再生します。

バイナリログの管理

古いバイナリログを手動でパージします。
binlog_expire_logs_seconds で自動パージします(MySQL 8.0 以降。expire_logs_days は削除されました)。
binlog ファイルを rm で直接削除してはいけません。インデックスファイルの一貫性を保つため、PURGE BINARY LOGS を使ってください。

よくある質問

バイナリログは書き込みパフォーマンスに影響しますか?

はい、ただし影響は小さいです。ROW 形式のログは、変更されたデータ量に比例するオーバーヘッドを追加します。書き込み中心のワークロードでは、オーバーヘッドは通常 5〜15% です。それによって得られる復旧とレプリケーションの能力を考えれば、ほぼ常に見合う価値があります。

特定のセッションだけバイナリログを省略できますか?

これは、さらに先へ伝播させる必要のないレプリカへのデータロードや、ポイントインタイムリカバリの範囲から除外したい一括操作に役立ちます。SUPER、SYSTEM_VARIABLES_ADMIN、または SESSION_VARIABLES_ADMIN が必要です。BINLOG_ADMIN だけでは不十分で、試みは ERROR 1227 で失敗します。

バイナリログがどれだけのディスク容量を使っているかを知るには?

またはディスク上で: du -sh /var/log/mysql/mysql-bin.*

トラブルシューティング

関連項目