ロギングシステムの更新SQL文が実行されます

更新プロセス実行されたステートメント

実行された文の更新とクエリの実行プロセスフロー

注意：

そこタイムテーブルで更新動作している、とクエリキャッシュに関連付けられたテーブルがクリアされます

アナライザ、オプティマイザ、歴史やアクチュエータストレージエンジンを体験するだけでなく、より重要なのモジュールを記録

REDOログREDOログ

ビンログアーカイブログ

物理ログをredoログ

InnoDBエンジンは、独自のログモジュールであります

一緒に行って、そのキーポイントは、タスクでビジーではないが、更新操作の蓄積の多くになりますとき、ログを書き込むための時間をアップデートディスクを作成することですIOがディスクに書き込ま

InnoDB のREDOログ固定サイズであり、例えばセットとして構成されてもよい。4つのファイルは、各ファイルが1ギガバイト、この『ピンクシート』の合計を記録することができる4GBの動作を制御します。次の表に示すようにゼロから書かれて、それは、バックライト・サイクルの開始に最後に書き込まれ、

書き込みPOSは、ライト側のシフトは、最初に書いている間、現在のレコードの位置である3つのバックへのファイルの終了後に数字を0 文書の冒頭に。チェックポイントは、現在の場所を消去することですが、また戻ってサイクルが、レコードを消去する前に、データファイルを記録するために更新する必要があります。

POS書くとチェックポイント間の「ピンクシート」はまだ空の部分には、新しい操作を記録するために使用することができます。あなたがいる場合のPOS書き込みキャッチチェックポイントを表し、「ピンクシート」フル、もはや新しいアップデートを実行することはできません。この時間は、我々はいくつかのレコードを拭くために停止しなければならなかった、チェックポイントは、それを促進します。

では、REDOログ、InnoDBはデータベースが発生した場合でも、再起動を保証することができ、以前にこの能力を失われます提出が呼び出されたクラッシュセーフ

binlogの論理ログ

レイヤーは、サービスログモジュールであります

すべてのエンジンを使用することができます

バイナリログを追加記録することができ、アクチュエータの論理演算により生成されます

なぜ2つのログモジュールがあるのですか？

初め以来MySQLのではなかったのInnoDB エンジン。MySQLの自身のエンジンであるMyISAMテーブルが、MyISAMテーブルがありませんクラッシュセーフ機能を、バイナリログログはアーカイブに使用することができます。InnoDBは、プラグインを導入する別の会社でMySQLをのみに依存するので、バイナリログされていないクラッシュセーフ機能を、ので、InnoDBはロギングシステムの別のセットを使用する- つまり、REDOログ・達成するためにクラッシュセーフ機能を

両方のログを比較します：

REDOログInnoDBエンジンは一意である ;のbinlogは、MySQLサーバー層の実装である、すべてのエンジンを使用することができます。
物理的なレコードは、「ページの変更上のデータが行われたあるログREDOログ」; binlogの論理ログには、『このラインプラスワンのID = C 2のフィールドを』として、文の元のロジックを記録。
循環で書かれているREDOログ、固定スペースが不足します。ビンログが書かれて追加することができます。「追加の書き込みは、」一定のサイズに書かれている次の投稿に切り替わりますビンログファイルを参照し、以前のログが上書きされることはありません。

INNODBアクチュエータとデータ更新内部処理を行います

エンジンアクチュエータは、ラインID = 2を取るために誰かを見つけます。IDは、ラインの直接の使用を見つけるために、主キー、木の検索エンジンです。すでにメモリ内のこの行は、それがアクチュエータに直接返されるID = 2つのデータ・ページならば、そうでない場合、あなたは再びメモリにディスクを起動し、する必要があります。
ラインデータにエンジンを取得するためのアクチュエータ、例えば原稿がNであるように、この値に1を加算し、次に新しいデータを書き込むためにこのラインエンジンインタフェースを呼び出し、データの新しいラインを得るために、今N + 1です。

更新操作は、この場合、状態を準備REDOログレコードをログやり直すながらエンジン行は、メモリ内のこれらの新しいデータを更新します。その後エグゼクティブは、完全なトランザクションをコミットする準備ができて行って通知しました。

アクチュエータは、この操作BINLOG生成し、バイナリログがディスクに書き込まれます。

ちょうど（コミット）提出にREDOログに書き込まれたトランザクション・インタフェース・エンジンをコミットする実行エンジン通話状態、アップデートは完了です。

フローチャートが実行され、

図着色ボックスが表すInnoDBは内部的に行わ、

暗いボックスは、アクチュエータの実装を表します

なぜログは、2フェーズ・コミット」が必要？

キー：

redoログで準備しBINLOGの間に完了しコミット

binlogの前にメモリへの準備ができてredoログが、ディスクに書き込まれていません

binlogのredoログの後にディスクに書き込むことが可能な状態で提出されました。

redoログおよびバイナリログは2段階に分けている、依存しません

すなわち、データの変更は、また、上に記録された操作データを修正、既にメモリに完了しています

しかし、データベースのディスクファイルは、実際に書かれていません。

假设当前ID=2的行，字段c的值是0，再假设执行update语句过程中在写完第一个日志后，第二个日志还没有写完期间发生了crash

先写redo log后写binlog。假设在redo log写完，binlog还没有写完的时候，MySQL进程异常重启。由于我们前面说过的，redo log写完之后，系统即使崩溃，仍然能够把数据恢复回来，所以恢复后这一行c的值是1。
但是由于binlog没写完就crash了，这时候binlog里面就没有记录这个语句。因此，之后备份日志的时候，存起来的binlog里面就没有这条语句。
然后你会发现，如果需要用这个binlog来恢复临时库的话，由于这个语句的binlog丢失，这个临时库就会少了这一次更新，恢复出来的这一行c的值就是0，与原库的值不同。
先写binlog后写redo log。如果在binlog写完之后crash，由于redo log还没写，崩溃恢复以后这个事务无效，所以这一行c的值是0。但是binlog里面已经记录了"把c从0改成1"这个日志。所以，在之后用binlog来恢复的时候就多了一个事务出来，恢复出来的这一行c的值就是1，与原库的值不同。

注意

redo log用于保证crash-safe能力。innodb_flush_log_at_trx_commit这个参数设置成1的时候，表示每次事务的redo log都直接持久化到磁盘。这个参数建议你设置成1，这样可以保证MySQL异常重启之后数据不丢失。

sync_binlog这个参数设置成1的时候，表示每次事务的binlog都持久化到磁盘。这个参数建议你设置成1，这样可以保证MySQL异常重启之后binlog不丢失。

MySQLのログシステムSQL論理ログ物理ログ