このホワイトペーパーでは説明した構造とMySQLのInnoDBトランザクションエンジンの基本的な知識の実装だけでなく、REDOログ、ログ特性を。この参考文献の末尾にテキストを参照してください。
トランザクションを実装
トランザクション分離は、データベースロックの原子により達成分離、再実行ログの耐久性やログを取り消す（REDOログがトランザクションの耐久性を達成するため、請求）が達成され、やり直しログおよびアンドゥログされていますリカバリ操作の種類
ページの動作を変更するために、トランザクションをコミット回復をやり直し、および特定のバージョンにロールバック行を元に戻します。
通常、物理のREDOログ・レコード・ページは、物理的な修正操作で各ラインに応じたアンドゥログレコードの論理的使用です。
REDOログ
ログの2つの部分
このログは、一つの部分が2つの部品を有しているメモリ内のバッファの再実行ログ（バッファをREDOログ）、揮発性であり、第二の部分長持ちであるREDOログ・ファイル（REDOログファイル）。
コミット時の力のログ（ログ・ファイルに書き込まれるログ）
InnoDBはトランザクションストレージエンジンはであるエンジン、あるメカニズムをコミット時に強制ログ -トランザクションの耐久性を達成するために、トランザクションがコミットされたときに、トランザクションは、トランザクションを保留中の、持続性のためのすべてのREDOログ・ファイルのログに書き込まれなければならないがCOMMIT操作が完了するまでは完全ではありません。
2つのログ（なし読み出し動作、ランダムアクセス）の特徴
このうち、REDOログは、トランザクションとMVCC機能をロールバックを支援するためにログイン取り消し、トランザクションの耐久性を確保するために、REDOログ、二つの部分（二つの部分をやり直しと元に戻す）が含まれています。
- REDOが順番に書かれているREDOログ・ファイル操作を読んだとき、あなたは、データベースを実行する必要はありません
- そして、アンドゥログは、ランダムアクセス（恐らくはロールバック）が必要です
ログは、ログファイルに書き込まれていることを確認してください
O_DIRECTオプションを使用しない場合、データベースは、（図のアプローチを以下れるO_DIRECTオプションは、直接、このオプションを使用して、文書IOオペレーションのLinuxシステムではオプションである、ファイル・システム・キャッシュを経由せず、直接ディスクに書き込み）
データベースのパフォーマンスを向上させます
性能を向上させるために、私たちが選ぶことができるように、我々は、非常に時間がかかり、fsyncを操作がディスクに書き込まれている知っているトランザクションのコミット時にログがREDOログ・ファイルに書き込まれていない、しかし、サイクルの後に、この動作のfsync中の時間を待つことなく、トランザクションがコミットされるまで、一度のfsync操作を余儀なくされました。
短所：データベースがダウンした場合には、いくつかのログがディスクにフラッシュされていないとして、取引が一定期間続く失われます。
しかし、ことを覚えておいて、このメソッドは、トランザクションのACID特性を失い、大量のデータを挿入するとき、そうするために、1を挿入した後ではなく、コミット操作よりも、一度の操作をコミットし、挿入後に行うべきです取引時に取引方法をロールバックすることができます状態の始めにロールバックされます。
ストレージ構造をREDOログ
512のバイトがエンジンに格納されているREDOログ、InnoDBエンジンのために、確立されたREDOログ。これは、REDOログ・バッファは、REDOログ・ファイルがにあることを意味し、「ブロック」と呼ば維持する方法、「REDOログ・ブロック」（ディスクのセクタサイズが512バイトです）。
REDOログ・ブロック内のページ数より大きい512バイトを生成した場合、その後、複数のメモリブロックを分割する必要がログをやり直します。512バイトであるため、REDOログ・ブロックがアトミック、無二重書き込み技術を保証することができます書き込みます。
次の外観：バッファ構造をREDOログ！
接着重点讲一下，FIRST_REC_GROUP 的意思
重做日志组（重做日志文档的组合）
log group 为重做日志组，其中与许多重做日志文档，InnoDB 实际只有一个log group（源码支持多个，但是在配置文档中禁止了）。
它是一个逻辑上的概念，实际上没有一个存储的物理文档来表示log group信息。
它由许多个重做日志文档组成，每个日志文档的大小都是相同的。在 InnoDB 的 1.2版本之前，重做日志文档的总大小小于 4GB，之后提高为512 GB .
重做日志文档存储的就是log buffer中保存的 log block，也是按照块的方式去存储。
log buffer 的提交
-
当事务提交的时候
-
当log buffer 中有一般的内存空间已经被使用时
-
log checkpoint时
存在以上三种情况的时候，内存中的log block会刷新到磁盘上
LSN (Log Sequence Number/日志序列号)
在InnoDB引擎中，LSN占用8字节，并且单调递增。LSN表示的含义有：
- 重做日志的写入的总量
- checkPoint的位置
- 页的版本
如果当前重做日志的LSN为1000，一个事务写入了100字节的重做日志，那么LSN变为1100，又有事务T2写入了200字节的重做日志，那么lsn就变成了1300
LSN不仅记录在重做日志中，还存在每个页中，在每个页的头部，有一个值为FIL_PAGE_LSN，记录了该页的LSN.
在该页中，LSN表示该页最后刷新时 LSN 的大小，因为重做日志记录的是每个页的日志，因此页中的LSN用来判断页是否需要进行恢复操作。
如：
页P1的LSN为10000，那么数据库启动的时候,InnoDB检测到写入重做日志的LSN为13000，且事务已经提交。
その後、データベースはリカバリ操作、P1ページへのREDOログにする必要があります。
少ないP1ページよりLSN LSNをREDOログ場合はP1ページLSNは、ページが更新されている表しているので、あなたは、再実行する必要はありません。
コマンドにSHOW ENGINE INNODB STATUS状況LSNを参照するには、以下のパラメータのログ一部が表示されます
- ログシーケンス番号は（ログそれらをキャッシュする）現在のLSNを表し
- ログインはまでフラッシュLSNのREDOログ・ファイルにフラッシュ表します
- で、最後のチェックポイントLSNの表現がディスクにフラッシュ
回復
起動時にInnoDBストレージエンジンにかかわらず、データベースが最後に正常にシャットダウンされたかどうか、回復しようとするの、チェックポイントがLSNが回復プロセスの間に、ディスクページにフラッシュ表し、回復ログチェックポイントの一部のみが始まりました。
参考文献：
https://juejin.im/post/5c3c5c0451882525487c498d#heading-17
「MySQLストレージエンジン技術インサイダー--InnoDB」
オリジナル：大列 MySQLのトランザクション・ログ・--REDOログ・