redo logとbinlog

redo logとbinlog
 
redo log

redo log(REDOログ)は にあり、InnoDBエンジン特有の

である.

redo logは、物理ログ、すなわち、「あるデータページで何が変更されたか」

を格納する.

redo logはループ書きで、空間は一定で、使い切ることができます.

MySQLはWALテクノロジー--Write-Ahead-Loggingを使用しています.具体的にはredo logとは、更新が必要なレコードがある場合、InnoDBエンジンはまずレコードをredo logに書き、メモリを更新し、空き時間に操作レコードをディスクに更新します.

InnoDBエンジンのredo logのスペースは限られており、4つのファイルのセット、1つのファイル1 GB、合計4 GBです.この「一時記録板」がいっぱいになると、再び先頭からループして書きます.

redo logの書き込みは、perpareとcommitの段階に分けられる.
 
redo logがあれば、データベースが異常に再起動してもレコードが失われないことを保証できます.crash-safeと呼ばれます.
 
binlog

binlog(アーカイブログ)はserver にあり、Mysqlが持参したログモジュール

である.

binlogは、論理ログ、すなわち「元の文を記録する」を格納する.これにより、データベースのリカバリに使用できます.これは、ある時間に関連する文を再実行したことに相当します.

binlogは追加で書き込むことができます---binlogファイルは一定のサイズに書くと、前のファイルを上書きすることなく、次のファイルで継続的に書き続けます.

 
2つのログの使用プロセス

(アクチュエータ)表のupdateが必要な行

を読み出す.

(InnoDB)は、ロー情報がメモリ内にあるかどうかを問い合わせる.ない場合は、ディスクからメモリに読み込みます.その後、行データ

に戻る

(アクチュエータ)行データの変更、新規行

への書き込み

(InnoDB)新しいローをメモリに更新し、redo log(prepareフェーズ)

に書き込みます.

(アクチュエータ)binlog

に書き込む

(InnoDB)コミットトランザクション(commitフェーズ)

2段階コミットを使用するのは、リカバリ時にリカバリされたデータベースが元の状態と一致しないようにするためです.
 
MySQL crash時のデータ損失回避の設定
crashが発生したときに失われたのはメモリ内のデータに違いないことを知っています.以下の設定で永続化します.

innodb_flush_log_at_trx_commit = 1---トランザクションごとのredo logは、ディスク

に直接永続化されます.

sync_binlog = 1---各トランザクションのbinlogはディスク

に永続化されます.
 
リカバリと拡張

最近のフルバックアップ+対応する時点へのアーカイブログ(binlog)