この「DeadlyKickMySQLSeries 1」のように、selectステートメントがMySQLで実行されていることがわかります。

一連の記事

• この「DeadlyKickMySQLSeries 1」のように、selectステートメントがMySQLで実行されていることがわかります。

• 生涯の友人がログをやり直し、binlog「Deadly KickMySQLSeriesII」

序文

チャット

最後の号では、クエリステートメントのクエリプロセスに基づいてMySQLの全体的なアーキテクチャを分析しました。同様に、この問題でも、導入としてクエリSQLステートメントを使用しています。クエリステートメントによって実行されるプロセス更新ステートメントも実行されることは確実です。

したがって、この問題の焦点はMySQLアーキテクチャ図ではありません。記事のタイトルは、REDOログとbinlogを理解することにも焦点を当てています。

1.ログをやり直す

最初のステップはテーブルユーザーを作成することであり、主キーはidであり、次は作成ステートメントです。

CREATE TABLE `user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `name` varchar(255) NOT NULL,
 `age` tinyint(4) NOT NULL,
 `time` int(11) NOT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

データを挿入する

insert into user (`name`,`age`,`time`) values ("咔咔","25",unix_timestamp(now()))

挿入されたデータの経過時間を26に変更するには、ステートメントを実行する必要があります

update user set age = 26 where id = 1;

最初の記事では、更新ステートメントと同じクエリステートメントの実行フローについて説明しました。ここでその写真を撮って、よく理解してください。

各モジュールの機能は、最初の記事に戻って確認できます。

/var/lib/mysqlMySQL 8.0では、図に示すように、REDOログファイルとbinlogログファイルはこのディレクトリにあります。

ファイル名ib_logfileはREDOログであり、UNDOの開始はロールバックログであり、ロールバックログの後の段階について詳しく説明します。

redo log（重做日志）是实现事务持久性必备要素、トランザクションがコミットされると、データベース内のデータは直接変更されませんが、最初に、関連する操作がREDOログに記録されていることを確認します。

InnodbストレージエンジンのREDOログのサイズは固定されています。上の図は、2つのファイルのセットが構成されていることを示しています。各ファイルのデフォルトサイズは48Mです。innodb_log_file_sizeパラメーターは、1つのファイルのサイズを制御するために使用されます。 MySQL 5.6.8以降のバージョンでは、デフォルトは48Mです。

次に、REDOログは48Mの操作を記録でき、REDOログは閉ループの循環書き込みです。設定したファイル数とファイルサイズが増えなくなりました。

write posは、ib-log-file-3ファイルの終了後、後方に移動しながら現在の位置を記録し、ib-logfilg-0ファイルに戻って書き込みを開始します。

チェックポイントは現在の消去位置を記録します。ファイルを循環的に書き込むには、同時に消去する必要があります。クリアデータの前提は、レコードをデータファイルに更新することです。

上の緑色の部分が書き込み可能な部分です。writeposがチェックポイントに追いついた場合、どうすればよいでしょうか。

書き込み位置のアドバンスは、更新操作が実行されるためであるため、レコードがデータファイルに更新されるまで更新操作を再度実行できず、チェックポイントが消去された後も更新操作を続行できることを理解する必要があります。

innodb_log_file_sizeの設定には、いくつかの計算ルールもあります。これについては、以下で紹介します。

innodb_log_file_sizeの設定が小さすぎると、REDOログファイルが頻繁に切り替えられ、データベースのチェックポイントが頻繁にトリガーされるため、データファイルに更新されるレコードの数が増え、IOのパフォーマンスに影響します。

同様に、大規模なトランザクションがあり、すべてのREDOログログがいっぱいであるが完了していない場合、ログを切り替えることができず、MySQLが直接ブロックされます。

innodb_log_file_size設定が大きすぎます。IOパフォーマンスは大幅に向上しますが、MySQLが再起動またはクラッシュすると、REDOログファイルが大きすぎるため、回復時間が長くなります。そして、この回復時間はしばしば制御不能です。

妥当なREDOログのサイズと量を設定した後、Innodbは、データベースが異常に再起動した場合でも、以前に送信されたレコードが失われないようにすることができます。これは、クラッシュセーフとも呼ばれます。

ここでは、クラッシュセーフの理解はそれが何であるかについては言及しません、そして以下の記事はあなたに理解させるでしょう。

2.プロジェクトの状況に応じてinnodb_log_file_sizeを設定する方法

最適化せずに、パラメーターinnodb_log_files_in_groupに3〜4個のパラメーターを設定するだけで十分です。

innodb_log_file_sizeのサイズ設定または最適化設定に注目してください。

MySQL 8.0より前では、一定期間に生成されたトランザクションログ（やり直しログ）のサイズは通常計算され、MySQLログファイルには少なくとも1時間のビジネスログが含まれている必要があります。

ここでのログの量は一段时间、ご自身のビジネス状況に応じて決定する必要があります。外部で使用されるログの量は、1分のログと1時間のログで計算されます。

まず、MySQLクライアントのコマンドページャーを見てみましょう。MySQLの日常業務では、ページャーの表示モードを設定することで、作業効率を大幅に向上させることができます。

mysql> show engine innodb status\ G select sleep (60); show engine innodbstatus\ G;現在、1分以内にシーケンスの値を確認するために、返された結果に応答しないページャーgrepシーケンスを実行できます。

nopagerを実行するようにポケットベルを設定することは禁止されています。コマンドが実行されない場合、コマンドは次に再起動するまで無効になりません。

ここで、Ka Kaは仮想マシン上で行われる操作です。1分間操作がないことがわかりますので、値は前後で同じなので、テストサーバーでテストできます。

この方法で計算された値select (后边数据-前面的数据)/1024/1024*60 asMB_per_hour;は、1時間後のREDOログのサイズです。

ただし、この方法を使用して計算することは適切ではなく、1分間の忙しいビジネスまたはビジネスのアイドル時間で計算された値には大きな誤差があります。

適切な方法は、1日の複数の時点を特定し、スクリプトを使用して定期的に実行し、対応する値を記録してから平均値を取得することです。これにより、計算されたエラーが最小限に抑えられます。

シーケンスとは何ですか？各binlogが生成されると、値は1から始まり、その後増加し、トランザクションが増えるごとに1ずつ増加します。

2. binlog

一般に、MySQLアーキテクチャは2つの層に分かれており、1つはサーバー層で、もう1つはストレージエンジン層です。

もちろん、サーバー層は機能面を担当し、ストレージエンジン層はストレージ関連の操作を処理します。

さらに、上記のREDOログはInnodbストレージエンジンレイヤーに固有であり、他のストレージエンジンにはありません。また、サーバーレイヤーにも独自のログレコードがあります。これは、後で説明するbinlogです。

REDOログとbinlogの違い

REDOログはInnodbエンジンに固有ですが、binlogはMySQLサーバーレイヤーに固有であり、すべてのエンジンで使用できます。

REDOログは、更新操作によって行われた変更を記録する物理ログであり、binlogは、更新ステートメントの実行ロジックを記録する論理ログです。

REDOログは周期的に書き込まれ、スペースは固定されます。たとえば、上記で4つの1GB REDOログファイルが構成され、binlogが追加で書き込まれます。このファイルが書き込まれた後、前のログを上書きせずに次のファイルが上書きされることはありません。 。これは、必要なデータに復元できる完全なbinlogファイルがある限りよく見られるものです。

MySQLに2つのログがあるのはなぜですか？

Innodbストレージエンジンがなくなる前は、MySQLのデフォルトのストレージエンジンはMyIsamですが、MyIsamには再起動リカバリ機能がなく、binlogログはアーカイブにのみ使用されます。

Innodbは、プラグインの形で別の会社によってMysqlに導入されています。binlogには再起動と復元の機能がないため、REDOログを使用して再起動と復元の機能を実現します。

これにより、Innodbストレージエンジンを使用すると2つのログが書き込まれます。

3. 2フェーズコミットとは何ですか？

REDOログとbinlogについてある程度理解した後、更新ステートメントの実行フローを見てみましょう。

ユーザーセットの更新age=age + 1ここで、id = 1;

• エグゼキュータは最初にエンジンレイヤーに移動して、id = 1の行を見つけます。IDは主キーであるため、この行は主キーインデックスツリーで見つかります。ID = 2の行が配置されているデータページがすでにメモリにある場合は、エグゼキュータに直接返されます。それ以外の場合は、メモリをディスクから読み取ってから返す必要があります。

• エグゼキュータは、ストレージエンジンから返されたid = 2の結果を取得した後、ageに1を追加します。これは、以前は25でしたが、現在は26であり、エンジンインターフェイスを呼び出してこの新しいデータ行を書き込みます。

• エンジンは最初にこのデータ行をメモリに更新し、同時に更新操作をREDOログに記録します。このとき、REDOログは準備状態になっています。次に、実行が完了し、トランザクションをいつでもコミットできることをエグゼキュータに通知します。

• 次に、エグゼキュータはこの操作のbinlogを生成し、binlogをディスクに書き込みます。

• エグゼキュータはエンジンのコミットトランザクションインターフェイスを呼び出し、エンジンはコミットされたばかりのREDOログをコミットコミット状態に変更し、更新が完了します。

ここで明確にする必要があります。更新SQLは最初にREDOログを書き込み、次にbinlogを書き込みます。これが、タイトルがと呼ばれる理由一生挚友redo log、binlogです。

4.2フェーズコミットが必要な理由

これは、REDOログとbinlogの間のロジックを一貫させるためです。次の2つの状況を参照してください。

最初にREDOログを書き込み、次にbinlogを書き込みます

• 更新ステートメントは年齢=年齢+1です

• REDOログにデータを書き込むと、MySQLプロセスが異常に再起動します

• 現時点では、binlogは書き込みを開始していません

• システム再起動後のデータ回復、この時点での値は26です

• スレーブライブラリを構築する必要がある場合は、binlogを使用してデータを復元する必要がありますが、現時点では、age =age+1の操作はbinlogに記録されません。

• その場合、この時点でのスレーブデータベースの更新は少なくなり、回復された経過時間は25のままであるため、マスターデータベースのデータに一貫性がなくなります。

最初にbinlogを書き込み、次にログをやり直します

• 更新ステートメントは年齢=年齢+1です

• binlogにデータを書き込むと、MySQLが異常に再起動します

• 現時点では、REDOログはまだ書き込まれていません

• MySQLシステムが再起動されます。この更新操作はREDOログには存在しないため、再起動後の値は25のままです。

• しかし、binlogの値はすでに26になります

• スレーブライブラリを構築する必要がある場合、スレーブライブラリの値は26であり、マスターライブラリの値は25であるため、マスタースレーブデータに一貫性がありません。

したがって、2フェーズ・コミットが使用されていない場合、元のデータベースとそのbinlogログによってリカバリーされたデータベース・データは不整合になります。

5.「KongYiji」では、REDOログとは何かを理解できます

中学9年生の中国語テキストの「コン・イージ」の記事を見てください。内容を覚えていなくても、タイトルはいつも覚えています！

このケースはDing氏の記事にも記載されていますが、Ding Laoがこのケースを柔軟に使用してREDOログについて話すことができるのはなぜですか？

本質的な理由は、知識のポイントが完全に理解されていないことです。ライフケースを使用してテクノロジーを説明することは、人々が理解するのが最も簡単で、忘れることは難しくありません。

「コン・イージ」の主人公は彼をホテルの店主と呼んでいます。店主は他のボスよりもはるかに効率的に仕事をするための2つの魔法の武器を持っています。1つは小さな黒板で、もう1つは元帳です。

クレジットを取得したい顧客がいる場合を想像してみてください。それを黒板に直接書く方が効率的ですか、それとも密集した帳簿をめくる方が速いのでしょうか。

店主は間違いなく最初にそれを黒板に記録することを選択し、次に人が少ないときや忙しくないときに黒板に記録を元帳に書き込みます。

一方、上司が黒板を持っていない場合は、最初に密集した帳簿でクレジット会計士の名前を見つけることしかできません。以前に追加のクレジットアカウントレコードがある場合は、もう一度検索して、あることを発見した後、なし、それからそれを追加します。

このプロセスは面倒であるだけでなく、非効率的で受け入れがたいものです。ホテルに多くのゲストがいる場合、上司はそれを記録できません。

同様に、この問題はMySQLにも存在します。更新ステートメントを実行するたびに、最初にレコードを検索してから更新する必要があります。プロセス全体のIOコストと検索コストは非常に高くなります。したがって、MySQLはホテルの店主の知恵を利用して、黒板を使用して実行効率を向上させます。

店主、黒板、MySQLの対応を誰もがよく理解できるように絵を描いてください。

ホテルの店主とMySQLの関係

6.REDOログパラメータの詳細な説明

事务的持久性就是通过重做日志来实现的。

トランザクションがコミットされると、データベース内のデータは直接変更されませんが、最初に、関連する操作がREDOログに記録されていることを確認します。

データベースは、対応するメカニズムに従って、メモリ内のダーティページデータをディスクにフラッシュします。

ログ書き込みプロセスをやり直します

上の図は、単純なREDOログ書き込みプロセスです。

上の図には、バッファプールとREDOログバッファという2つの見慣れない概念が示されています。これらは両方とも、Innodbストレージエンジンのメモリ領域の一部です。

REDOログファイルはディスクの場所にあります。

つまり、DML（挿入、更新、削除）操作がある場合、データは最初にバッファー・プールに書き込まれ、次にREDOログ・バッファーに書き込まれます。

REDOログバッファは、フラッシュメカニズムに従ってREDOログに書き込まれます。

このメカニズムの設定パラメータはinnodb_flush_log_at_trx_commit、パラメータはそれぞれ0、1、2です。

ブラシ戦略

上の図は、REDOログの書き込み戦略を示しています。

• このパラメーターの値が0の場合、トランザクションがコミットされた後、データはREDOログ・バッファーに保管され、その後、データは1秒ごとにディスク・ファイルに書き込まれます。

• このパラメータの値が1の場合、トランザクションがコミットされた後、REDOログバッファをメモリからディスクファイルにフラッシュする必要があります。トランザクションが正常に送信される限り、REDOログはディスクに存在する必要があります。

• このパラメータの値が2の場合、トランザクションがコミットされた後、REDOログバッファログはディスクファイルに直接入力するのではなく、ディスクファイルに対応するosキャッシュに書き込まれ、osキャッシュ内のデータは後に書き込まれます。 1秒。ディスクファイルに。

サーバーがトランザクションへの応答を異常に停止する方法（トランザクション書き込みプロセス）

• パラメータが0の場合、前の1秒間のログがログバッファ、つまりメモリに保存されます。マシンがダウンすると、1秒間のトランザクションデータが失われる可能性があります。

• パラメータが1の場合、データベースのIO要件は非常に高くなります。基盤となるハードウェアによって提供されるIOPSが比較的低い場合、ハードウェアIOの問題により、MySQLデータベースの同時実行性はすぐに向上しません。

• パラメータが2の場合、データはosキャッシュに直接書き込まれます。この部分はオペレーティングシステムに属します。オペレーティングシステムが部分的に破損または電源オフの場合、1秒以内のトランザクションデータは失われます。この戦略は、最初のもの。それははるかに安全であり、IO要件はそれほど高くありません。

まとめ

パフォーマンスについて：0> 2> 1

セキュリティについて：1> 2> 0

根据以上结论，所以说在MySQL数据库中，刷盘策略默认值为1，保证事务提交之后，数据绝对不会丢失。

「「

学習の粘り強さ、執筆の忍耐力、共有の忍耐力は、カカが彼女のキャリア以来支持してきた信念です。この記事が巨大なインターネットであなたに少しの助けをもたらすことを願っています、私はカカです、次の号でお会いしましょう。

」

{{o.name}}

{{m.name}}