redoLogを使用しない場合の問題：
Innodb ベースの 页 ディスクは1つのユニットとして相互作用するため 、トランザクションは数バイトのデータページのみを変更する可能性があります。これは、2番目のアプローチを採用した場合、今度はディスクへのデータの全ページに変更し、リソースの浪費になります。
たとえば、図（ページ構造）は論理的に連続したデータの行ですが、ディスク上のそれらの位置は連続的ではなく、ランダムである可能性があります。このページ全体をディスクに永続化するのはランダムIOです。このとき、ディスク内の対応する位置を1つずつ見つけて、BufferPoolの最新のページデータをディスクに更新する必要があります。ランダムなIOの問題のため、このプロセスは非常に遅くなります。
やり直しを使用する
redo log これは2つの部分で構成されています。1つはメモリ内のログバッファ（redo log buffer ）で、もう1つは ディスク上のログファイル（ redo logfile）です。
mysqlDML ステートメントが 実行されるたび に、レコードが最初redo log bufferに書き込まれ 、次に複数の操作レコードが後の時点で一度に書き込まれ redo log fileます。最初にログを書き込んでからディスク に書き込むこの 手法はMySQL、このWAL(Write-Ahead Logging) 記事でよく言及される 手法 です。
コンピュータのオペレーティングシステムでuser space は、通常、ユーザースペース（）のバッファデータを ディスクに直接書き込むことはできません。カーネルスペース（kernel space ）バッファ（）は、中央のオペレーティングシステムのカーネルスペース（）を 通過する必要があり OS Buffer ます。
したがって、 redo log buffer 書き込み redo logfile は実際に最初に書き込まれ OS Buffer 、次にfsync() ブラシへのシステムコールを 介して redo log file
、プロセスは次のようになります。
mysql 3種類 のredo log buffer 書き込み redo log fileタイミングに対応 、
永続性はいつですか？これはトランザクションに関連しています。たとえば、トランザクションが開かれて更新が実行された場合、この時点で永続化する必要がありますredo logか？
現時点では必要ありません。トランザクションが実際にコミットされた場合にのみ持続します。トランザクションのロールバックは確かに永続化する必要はありません。
これはinnodb_flush_log_at_trx_commit パラメーターを介して構成でき 、各パラメーター値の意味は次のとおりです。
osbuffer、オペレーティングシステムのバッファ。
たとえば、ファイルを書き込むには、write-> osおよびflush-> diskです。
トランザクションがコミットされると、REDOログは保持されます
mysqlがハングアップした場合、myqlを再度起動すると、古いページデータとREDOログページデータがディスクから検出され、変更されたデータが取得されます。
REDOLOGを使用するのが速いのはなぜですか？
mysqlの起動後、ファイル（ib_logfile、デフォルトは48M）がディスクで開かれるため、データが更新されている限り、REDOログログ（更新SQL）がこのファイルの最後に書き込まれます。この書き込みは順次書き込みです。ファイル自体がすでに存在するためです（シーケンスIO）。このIOの読み取りおよび書き込み速度は、2番目の方法よりもはるかに高速です。
REDOLOGに2つのファイルが周期的に書き込まれるのはなぜですか？
もちろん、ファイルのサイズと数を構成することもできます。
チェックポイントメカニズムを使用して、ib_logfile0とib_logfile1がいっぱいになり、その後ib_logfile0に切り替えると、checkponintメカニズムがトリガーされます。この時点でib_logfile0がいっぱいであることが判明すると、ib_logfile0に対応するBufferPoolのページデータがディスクにフラッシュされます。 、およびスペースは継続使用のためにクリアされます。
リフレッシュする時間
-
ログのフラッシュをやり直す
buffer poolページが変更されると、このダーティページの制御ブロックがフラッシュリンクリストに挿入されます。制御ブロックにoldest_modificationは、ロード時buffer poolのmtrの最初の変更の開始に対応するlsn値と、newest_modification各mtr変更の終了時点での対応するlsn値。制御ブロックは昇順でoldest_modification格納されます。1つのmtrが複数のページを変更する可能性があるため、
oldest_modification/newest_modificationは複数の制御ブロックで同じである可能性があります。 - ログバッファスペースが不足していて、空きスペースが半分未満の場合
- トランザクションがコミットされると、バッファプール内のダーティページが最初にフラッシュされない場合がありますが、損失を防ぐために、その中のログバッファをフラッシュする必要があります。
- バックグラウンドスレッドのタイミングが点滅
- サーバーが正常にシャットダウンされたとき
- チェックポイント中：フラッシュリストからダーティページをバッチでフラッシュする：システムがページを頻繁に変更し、ダーティページをフラッシュできない場合、時間内にチェックポイントを設定できず、ユーザースレッドを直接使用して、フラッシュリスト内の最も早く変更されたダーティページを同期できます。 。ディスクなので、これらのダーティページに対応するREDOログは役に立たないので、チェックポイントを設定できます
MySQLデータディレクトリでは、（innodb_log_group_home_dir保存場所を決定することにより、保存形式は名前で知られるログファイルグループです）ib_logfile0... nという名前のファイル、ファイル数はファイル名サフィックスを決定し、ファイル数はシステムパラメータによって決定されますinnodb_log_files_in_group。各ファイルのサイズがinnodb_log_file_size指定されます。
ファイルは、ib_logfile順次および周期的に書き込まれるlog bufferブロックごとに上書きされます。
チェックポイント：バッファプール内のダーティページをディスクにフラッシュします。
InnoDBストレージエンジン内には、次の2つのチェックポイントがあり
ます。1。シャープチェックポイント
2.ファジーチェックポイント
シャープチェックポイントは、データベースが閉じられると、すべてのダーティページをディスクにフラッシュします。これはデフォルトの作業モードです。つまり、パラメーター：innodb_fast_shutdown = 1 。
データベースが実行されているとき、InnoDBストレージエンジンはファジーチェックポイントを内部的に使用して、ダーティページの一部のみを更新します。
ファジーチェックポイントのいくつかの状況：
1。MasterThreadチェックポイントは
非同期で更新され、バッファプールのダーティページリストからディスクに一定の割合のページが1秒ごとまたは10秒ごとに更新されます。非同期更新、つまり、InnoDBストレージエンジンはこの時点で他の操作を実行でき、ユーザークエリスレッドはブロックされません。
2. FLUSH_LRU_LISTチェックポイント
InnoDBストレージエンジンは、LRUリストで使用できる空きページがほぼ100あることを確認する必要があります。InnoDB 1.1.xより前では、ユーザークエリスレッド（mysql5.6が別のプロセスのページクリーナーに配置された後）は、LRUリストに操作に十分なスペースがあるかどうかを確認します。そうでない場合は、LRUアルゴリズムに従って、LRUリストの最後にあるページをオーバーフローさせます。これらのページにダーティページがある場合は、チェックポイントが必要です。
パラメータの設定：innodb_lru_scan_dept：LRUリストで使用可能なページ数を制御します。値のデフォルトは1024です。3
。非同期/同期フラッシュチェックポイント
REDOログが利用できず、ページを強制的にディスクにリフレッシュする必要がある状況を指します。このとき、ダーティページリストでページが選択されています。
この状況は、REDOログの可用性を確保するためです。率直に言って、ループでカバーできるREDOログの部分が小さすぎる、つまり、非常に短時間で大量のREDOログが生成されます。 。
最適化
REDOログを増やしたり、ファイルの数を増やしたりして、ディスクフラッシュの頻度を減らし、ディスクIOを減らすことができますが、もう1つの問題は、mysqlの再起動に時間がかかることです。