MySQLの（InnoDBの分析）：06 ---チェックポイント（チェックポイント）テクノロジー

I.はじめに

• 既に述べた前記事（https://blog.csdn.net/qq_41453285/article/details/104083744）、CPU速度、ディスク速度のギャップを調整するためにプールをバッファリングするように設計されました。そのため、バッファプール内の最初のページの動作が完了しています。もしこの時点ような更新または削除レコードのページの変更などのDML文、ページが汚れています。これは、ページバッファプールよりもディスクの新バージョンです。データベースの新バージョンでは、ページの必要がディスクにバッファプールからのリフレッシュを

DのACID特性（持続性）の

• ページが変更されるたびに、新しいバージョンがディスクにページを更新する場合は、その後、このオーバーヘッドが非常に大きいです。ホットデータが数ページに設定した場合は、データベースのパフォーマンスが非常に悪くなります。バッファプールからページの新しいバージョンがディスクにフラッシュされたときにダウンタイムが発生した場合一方、データを復元することはできません
• するために、データ損失の問題が発生回避、現在のトランザクションデータベースシステムは、一般的にすることを、ログ先行書き込み戦略を採用しているときに、トランザクションのコミット、最初のページを変更し、その後、REDOログを書くこと。ダウンタイムは、REDOログによるデータの損失による発生した場合、データの復旧を完了させます。DのACIDトランザクションが必要なこと

第二に、なぜチェックポイントの技術設計

• 、次のシナリオを検討してREDOログは無限に大きくすることができるならば、プールはすべてのデータベースからのデータをバッファリングするために十分な大きさである一方で、それがディスクにバッファプールバックをリフレッシュするページの新しいバージョンには必要ありません。ダウンタイムが発生した場合、データは発生の時にデータベース全体のシステムダウンタイムの再実行ログを回収することができるので、しかし、2つの前提条件を必要とします。
  • 1.すべてのデータのバッファプールは、データベースをキャッシュすることができます
    • 最初の前提条件については、経験豊富なユーザは、データベースがちょうど創造の初めであるとき、テーブルにデータがない知っています。バッファプールキャッシュは確かにすべてのデータベースファイルをすることができます。しかし、市場の推進と、利用者の増加は、製品がますます注目、使用も増えているされています。データベースのバックエンドのストレージ容量の充電で、この時点では確かに成長していきます。MySQLの現在の3TBは珍しいことではありません持っているが、それはメモリの非常にまれである3TB
  • 2. REDOログは無線増やすことができます
    • 第二の前提条件に対応する：REDOログは無限に大きくすることができます。多分それはあるが、それは容易ではないながら、運用・保守まで、コストが高すぎる必要です。SAまたはDBAはもちろん、特定のスキルやデバイスのサポートを必要とREDOログが使用可能なディスク容量のしきい値に近いされているかどうか、いつ分かりませんし、ストレージデバイスは、動的な拡張をサポートするために
• ：上記の2つの条件が満たされた場合でも、その後、考慮すべき場合があるデータベースのダウンタイム後の回復時間が。データベースは数ヶ月のために実行されているときときでも数年、ダウンタイムが発生した場合、再適用REDOログは非常に長い時間がかかるだろう、この時間は、コードは非常に大きく、回復もあります

• チェックポイント（チェックポイント）技術の目的は、以下の質問に対処することです。
  • データベースのリカバリ時間を短縮
  • プールが十分でない場合には、汚れたページがディスクにフラッシュされています
  • REDOログが利用できない場合は、汚れたページをフラッシュします
• データベースのダウンタイムが発生した場合、前のチェックポイント・ページがディスクにリフレッシュ戻ってきたので、データベースは、すべてのログを再実行する必要はありません。そのため、データベースはチェックポイントの回復後にログをやり直す必要があります。これは大幅に回復時間を短縮します
• また、プールが利用できない場合、LRUアルゴリズムに従って、このページはダーティページは、あなたがチェックポイントを強制する必要がある場合は、ダーティページがディスクブラシへページの新しいバージョンで、最も最近使用されたページをオーバーフローします
• 使用不能が発生したREDOログ REDOログ用に設計された現在のトランザクションデータベースシステムがリサイクルされているので、より多くの苦しんでいるコストや管理からの、無限に成長することはできません。REDOログは、再利用可能な部品は、REDOログがもはやデータベースのダウンタイムが発生した場合、すなわち、回復操作は、このように、この部分は再利用覆われていてもよい、REDOログ・データベースにこの部分を必要としない、必要とされていることを意味していないかもしれません。この時点では、REDOログにも使用する必要がある場合は、少なくともREDOログの現在の場所にページをリフレッシュするためにチェックポイント、バッファプールを強制する必要があります

第三に、ログシーケンス番号LSN

• LSNのバージョンでマークされているのInnoDBの目的のために。LSNは、単位はバイトで、8バイトの数です。
• 各ページにはLSN、REDOログもLSN、チェックポイントもLSNを持っています。情報を表示するには、次のコマンドで表示することができます。

show engine innodb status\G;

 

四、シャープチェックポイントおよびファジーチェックポイント

• InnoDBストレージエンジンでは、チェックポイントは、条件とダーティページととても複雑なの発生を時間を選択します。はるかに少ないディスクにバッファプールの後ろにブラシ汚れのページへのよりも何もないかのチェックポイント。違いがあることであるたびにリフレッシュするために、ディスク・ページの数は、どこダーティページの時間がかかる、と何時間駆動のチェックポイント
• InnoDBストレージエンジン内部、すなわち、2チェックポイントがあります。
  • シャープチェックポイント
  • ファジーチェックポイント

シャープチェックポイント

• シャープチェックポイントが発生したデータベースは、ディスクへのすべてのダーティページが更新されますシャットダウンしたときにデフォルトの動作モードである、すなわち、パラメータinnodb_fast_shutdown = 1

ファジーチェックポイント

• データベースは、実行時にシャープチェックポイントを使用している場合は、データベースの可用性が大幅に影響を受けることになります。InnoDBはそうか、ページ、リフレッシュファジーチェックポイントを使用して汚れたページ更新の一部でしかありませんではなくフラッシュよりも、ディスクへのすべてのダーティ・ページを
• ファジーチェックポイントは、次の状況で発生します：
  • 1.Masterスレッドのチェックポイント
  • 2.FLUSH_LRU_LISTチェックポイント
  • 3.Async /同期フラッシュチェックポイント
  • 4.Dirtyページあまりにも多くのチェックポイント

①Masterスレッドのチェックポイント

• マスター・スレッド（後の記事意志の詳細）についてチェックポイントは、ほとんどで発生した第2のリフレッシュレートあたり10秒ごとまたはバッファプール内のダーティー・ページのリストからディスクへページの一定割合で。このプロセスは、この時点でInnoDBストレージエンジンは、他の操作を行うことができ、スレッドは、ユーザーのクエリをブロックしないこと、非同期であります

② FLUSH_LRU_LISTチェックポイント

• どのように動作します：
  • InnoDBストレージエンジンがする必要があるためFLUSH_LRU_LISTチェックポイントがある利用できるほぼ100空きページを持つことがLRUリストのニーズを確保します。使用可能な空きページ100が存在しない場合は、InnoDBは削除ページのLRUリストの末尾になりますこれらのページがあれば、ダーティページを持っている、あなたはチェックポイントである必要が
  • LRUリストからこれらのページは、そうFLUSH_LRU_LISTチェックポイントと呼ばれます
• InnoDBの1.1.xのバージョンには、事前に十分な空き領域操作LRUリストがあるかどうかをチェックする必要があり、ユーザーのクエリスレッドで発生し、明らかにユーザーのクエリ操作をブロックすることができます
• InnoDBの1.2.xのバージョンでのMySQL 5.6バージョンからは、このチェックは、別のスレッドに配置されたページ・クリーナーが行われ、ユーザーは、パラメータをinnodb_lru_scan_depthできLRUリストの使用可能なページ数を制御するために 1024年に、値のデフォルトは

show variables like 'innodb_lru_scan_depth'\G;

 

③Async/同期フラッシュチェックポイント

• チェックポイントが参照する非同期/同期のフラッシュREDOログ・ファイルは、ケースには利用できない、ページの一部を強制的にそれから必要性がディスクにフラッシュされている汚れたページはダーティページのリストから選択された時点で、
• それは、LSHのREDOログに書き込まれている場合redo_lsnで、checkpoint_lsnとして記録されたディスクの最新のLSNにページを更新する必要がありますが、定義することができます。

• そして、次の変数を定義します。

• 各REDOログ・ファイルのサイズは1ギガバイトであり、2つのREDOログ・ファイル、最大2GB REDOログ・ファイルの合計サイズを定義している場合。だから、async_water_mark = 1.5ギガバイト、sync_water_mark = 1.8ギガバイト、次のようになります。
  • checkpoint_age <async_water_markとき：あなたは、ディスクへのダーティページをフラッシュする必要はありません。
  • ときasync_water_mark <checkpoint_age <sync_water_mark：トリガー非同期フラッシュした後、checkpoint_age満たすためにリフレッシュして、リストからディスクフラッシュに十分な汚れたページをリフレッシュする<async_water_mark
  • checkpoint_age> sync_water_markのケースはめったにREDOログ・ファイル・セットが小さすぎる場合を除き、一般的には発生せず、負荷データのBULK INSERT操作が似て実行します。この時間トリガー同期フラッシュ操作の後、会うcheckpoint_age <async_water_markにリフレッシュして、リストからディスクフラッシュに十分な汚れたページをリフレッシュ
• したがって、非同期/同期フラッシュチェックポイントは、リサイクルREDOログの可用性を確保するため
• InnoDBの1.2.xのバージョンの前に、非同期はフラッシュチェックポイントは、すべてのユーザーがスレッドを照会し、汚れたページのリフレッシュのための待ち時間が完了しているユーザーのクエリスレッドの問題を発見し、同期フラッシュチェックポイントブロックしますブロックします。最初からInnoDB1.2.xバージョンは、リフレッシュ操作のこの部分は、それがユーザーのクエリスレッドをブロックしないで別のページクリーナースレッドに入れています
• 公式のMySQLのバージョンとは、表示またはリストからLRUリストフラッシュからのチェックポイントを実行され、ページを更新、非同期/同期のフラッシュの番号がわからないREDOログが生成されるので、しかしInnoSQLバージョンは、方法を提供することはできません以下で観察するためのコマンド：

show engine innodb status\G;

④Dirtyページあまりにも多くのチェックポイント

• 作品：チェックポイントを強制的にInnoDBストレージエンジンで、その結果、あまりにも多くの汚れのページで多くのダーティページTOO、。その目的は、十分なバッファページを確保するために、プールに一般的に利用可能です
• どのできるパラメータinnodb_max_dirty_pages_pctによって制御さ：
  • 75は、上に示した値を表すバッファプールのダーティページの数は、チェックポイントの75％の力を占有する場合、ディスクにリフレッシュダーティページの部分を。バージョンが75になった後のInnoDB 1.0.xのバージョン、90パラメータのデフォルトは、前

show variables like 'innodb_max_dirty_pages_pct'\G;