MySQLの声明の履行の過程について話を最初に、redoログおよびバイナリログの前に言えば。
1、コネクタへのクライアントの書き込み要求、コネクタは、アクセス許可を確認、接続を管理する責任があります。
この文は、キャッシュからの書き込みに、その後、キャッシュに、実行された場合は2、その後、パーサは、文法を検討する責任があります。
3、キャッシュが、それは一部を最適化することではありません。SQLの読み取りと書き込みを最適化するための責任、選択したインデックス。
図4は、エンジンを作動させるための責任アクチュエータ、続いて、その結果を返します。
次のステップは、第四の工程が実行されたかについて話し、ポイントを得ることです。
REDOログ
REDOログ（REDOログ）とビンログ（アーカイブログ）：クエリは同じではありませんが、更新プロセスは、2つの重要なログモジュール、我々は今日の話をしたい正確に何であるの主人公を必要とします。
InnoDBの更新操作がディスクに直接書き込まれていないが、最初のログは、それは、REDOログ、その後、ディスク上にブラシをかけるデシベル以下忙しい時間まで待っています。これは、効率的な書き込み操作のMySQLを保証します。なぜ、このような設計のでしょうか？すべての更新操作は、ディスクIOを最初のクエリがある必要があるため、ディスクへのブラシで見つかったデータを変更するだけでなく、IOは、それぞれの時間が非常に遅くなりそうするので、私は、メモリに記録することがあり、その後に記録redoログで、その後、ディスクへの戦略ブラシに従ってください。この技術はWAL技術と呼ばれています。もし理由だけで、メモリ、MySQLのクラッシュに記録されている言葉は、データの損失に変化をもたらす可能性があります。だから、InnoDBはクラッシュセーフことを確認するために、REDOログ。（注：MySQLはInnoDBのmysqlのに固有のものであるが、ほとんどの場合、今innnodbを選択します何のREDOログ、ではありません。）MySQLのクラッシュの後、回復がでREDOログからデータを読み込みます。
しかし、REDOログは、このような第3の時間が0のログファイルの報道で満たされるREDOログ4のGe 1Gを設定すると、サイズが限られています。
ビンログ
REDOログは保存し、クラッシュリカバリを担当するストレージエンジンレベルのログです。ビンログは、ログサーバ層です。
なぜ二人は、それがログに記録されていますか？
唯一の安全機能をクラッシュされていないビンログを依存しているため。そして、REDOログ・サイズ制限があります。
次のようにいくつかの違いがあるREDOログとビンログは、次のとおりです。
図1に示すように、異なる層に属する、ビンログサーバ層で、REDOログのみをログ蓄積層、唯一のInnoDBです。
図2に示すように、サイズが制限されているREDOログ、サイクル、及びそのような制限のバイナリログに書き込まれます。
3、こうした3 = IDをカウントするために、この行を追加するなど、オリジナルの論理文を、記録し、ビンログが論理ログで、「データ・ページの変更が行われた上で、」物理的なログレコードがあるREDOログ操作。
そして、更新ステートメントを実行するためのプロセスを見てみましょう。
図1に示すように、最初の行または複数行のデータに見られます。
図2に示すように、その後、変更されたデータがメモリに書き込まれ、そして、変更が再実行ログ・準備フェーズの再実行ログ内でこの時間を記述し、アクチュエータを提出することができる告げます。
図3に示すように、アクチュエータの受領後OK元の文のバイナリログに記録OKアクチュエータにサーバリターンは、ディスクに書き込まれます。
図4は、バイナリログ記録が完了した後、アクチュエータがエンジンに対応する層が準備状態からの状態変更をコミットREDOログ、エンジン層を伝えます。
これは2PCです。
最新のフルバックアップを見つけるために、前に私たちは、このような火曜日、火曜日として、ある時点にデータベースを復元したい場合は、火曜日のバイナリログのバックアップ実行時には、一時的なデータベースを取得します。
二相コミット、およびそれを行うための独立性にこれらの2つのステップを行うことはできませんか？次の二つの可能なシナリオを（行の列が0から1にカウント）を考えます：
1、最初のREDOログを行い、書き込みビンログ
REDOログ書き込みが成功した最初の場合は、崩壊するバイナリログを書いていない、とカウント列はビンログはこの1つの操作から欠落している、ビンログを使用して、データ復旧ながら、1に変更されているこの時間は、その後、ビンに登場回復と現在のdbデシベル比からログアウトし、矛盾がありました。
2、その後、ビンログ場合は最初に行うのログをやり直す書きます
仕上げビンログ場合は、書き込まれていないREDOログ、それは、クラッシュが何の回数= 1この変更はありません言うことデシベルを崩壊。矛盾があったので、この行のビンログデシベルで回収は、記録されています。
だから、REDOログのアップデートとビンログが2PCはまだ非常に必要ですか。
また。REDOログの設定項目が1に設定され、各トランザクションのREDOログ後の時間は、ディスクに更新できることを確認innodb_flush_log_at_trx_commitあります。これは、失われたように表示されません。
innodb_flush_log_at_trx_commit = 0は、ディスクが毎秒の書き込みを示しています。このようにして、データの1秒まで失うことが可能です。
2に設定すると、トランザクションのREDOログ・バッファは、OSのバッファ書き込まれた後の時間を表し、2番目は、（）はfsyncを呼び出すことですディスク上のログファイルにログにOSのバッファを書き込みます。MySQLの崩壊が、それはデータを失うことはありませんこの場合、データであれば、システムの崩壊は、1秒に失われます。
sync_binlogは、トランザクション後の各ビンログがディスクに永続化されていることを示す、1に設定推奨、あなたがレコードを失うことなく、異常な再起動後のbinlog MySQLを確保することができます。
ほとんどが疑問を持って、またデータもディスクに書き込む更新直接ディスクに書き込みログを書き込む、ディスクが書き込みされ、効率があなたと同じではありませんか？このようなREDOログ・InnoDBはあなたを気にしませんか？REDOログをディスク書き込みの形で添加するので、効率が非常に高く、次いで書き込まれるデータベースのデータを変更されるため、効率がはるかに低いです。