MySQL ストアドプログラムのバイナリロギング メモ

そもそもバイナリログって？

• MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.2.4 バイナリログ
• テーブル作成操作やテーブルデータ変更などデータベース変更を記述する「イベント」が格納される
• マスターサーバーはスレーブサーバーへバイナリログに格納されているイベントを送信する
  • スレーブはイベントを実行してマスターと同じデータ変更を実行する
• データを変更しないSELECTやSHOWなどのステートメントは使用されない
  • すべてをログに記録するには MySQL :: MySQL 5.6 リファレンスマニュアル :: 5.2.3 一般クエリーログ を使う
• バイナリロギングはパフォーマンスに影響するがレプリケーションするには必須
• mysqladmin flush-logsで古いログを削除できる

要するにレプリケーションするために必要なイベントが記録されているログ。

ストアドプログラムのバイナリロギング

MySQL :: MySQL 5.6 リファレンスマニュアル :: 20.7 ストアドプログラムのバイナリロギング

• ロギングがステートメントレベルで行われる場合、ストアドプログラムに関して該当するバイナリロギングの問題がある
  • ※ストアドプログラム -> ストアドプロシージャ、ストアドファンクション、トリガー、イベント
• ステートメントがマスターとスレーブで別々の行に影響する場合がある
• SQLステートメントレベルでバイナリロギングが行われるときに起こる
• ルーチンorトリガーが実行されると行を変更は記録されるが変更をおこなったステートメントは記録されない
  • ストアドプロシージャーでいうCALLが記録されない

プログラムの内容は記録されず、行の変更のみ記録されてそれがレプリケーションに利用されるということ。

• ストアドファンクションを利用するための条件
  • CREATE ROUTINE or ALTER ROUTINEと、SUPER 権限が必要
  • CREATE FUNCTIONの際は DETERMINISTIC 、 NO SQL または READS SQL DATA の少なくとも 1 つを明示的に指定する必要
  • 上記を緩和するために log_bin_trust_function_creators に1に設定できる
• トリガーは DETERMINISTIC 指定がないので常に決定的
  • ただし UUID() などは注意が必要