mysql アーキテクチャ原則の詳細な図による説明

WBOY
リリース: 2022-05-17 21:01:52
転載
2537 人が閲覧しました

この記事では、mysql に関する関連知識を提供します。主にアーキテクチャ原則に関する関連内容を紹介します。MySQL Server のアーキテクチャは、上から順にネットワーク接続層とサービス層に大別できます。 、ストレージ エンジン層、システム ファイル層について、一緒に見ていきましょう。皆さんのお役に立てれば幸いです。

mysql アーキテクチャ原則の詳細な図による説明

推奨学習: mysql ビデオ チュートリアル

Mysql アーキテクチャの原則

1. Mysql アーキテクチャ

MySQL Server のアーキテクチャは、上からネットワーク接続層、サービス層、ストレージ エンジン層、システム ファイル層に大別できます。

mysql アーキテクチャ原則の詳細な図による説明

#ネットワーク接続層

    クライアント コネクタ: MySQL サーバーとの接続のサポートを提供します。現在、一般的な Java、C、Python、.NET など、ほとんどすべての主流のサーバー側プログラミング テクノロジをサポートしています。これらは、それぞれの API テクノロジを通じて MySQL との接続を確立します。
サービス層 (MySQL Server)

サービス層は MySQL Server の中核であり、主にシステム管理および制御ツール、接続プール、SQL インターフェイス、パーサー、クエリ オプティマイザー、および6 つのパートをキャッシュします。

  • 接続プール: クライアントとデータベース間の接続の保存と管理を担当し、1 つのスレッドが 1 つの接続の管理を担当します。

  • システム管理および制御ツール (管理サービスおよびユーティリティ): バックアップとリカバリ、セキュリティ管理、クラスター管理など。

  • SQL インターフェイス (SQL インターフェイス): クライアントから送信されたさまざまな SQL コマンドを受け入れ、ユーザーがクエリする必要がある結果を返すために使用されます。 DML、DDL、ストアド プロシージャ、ビュー、トリガーなど。

  • Parser (パーサー): 要求された SQL を解析して「解析ツリー」を生成します。次に、いくつかの MySQL ルールに従って解析ツリーが正当であるかどうかをさらに確認します。

  • クエリ オプティマイザー (オプティマイザー): 「解析ツリー」がパーサー文法チェックに合格すると、オプティマイザーに渡されて実行プランに変換され、クエリ オプティマイザーと対話します。ストレージエンジン。

    性別 = 1 のユーザーから uid、名前を選択;

    選択-->>投影-->>結合戦略

      場所に基づいて最初に選択ステートメントの選択は、すべてのデータをクエリしてからフィルタリングすることを意味するわけではありません;
    1. select クエリは、uid と名前に基づいて属性プロジェクションを実行しますが、すべてのフィールドは削除しません;
    2. 前の選択とプロジェクションをに接続します最後にクエリを生成します。 結果;
  • キャッシュ (キャッシュ&バッファ): キャッシュ メカニズムは、一連の小さなキャッシュで構成されます。たとえば、テーブル キャッシュ、レコード キャッシュ、権限キャッシュ、エンジン キャッシュなどです。クエリ キャッシュにヒットしたクエリ結果がある場合、クエリ ステートメントはクエリ キャッシュからデータを直接フェッチできます。

ストレージ エンジン層 (プラグ可能ストレージ エンジン)

    ストレージ エンジンは、MySQL でのデータの保存と取得を担当し、基礎となるシステム ファイルと対話します。 。 MySQL ストレージ エンジンはプラグインであり、サーバーのクエリ実行エンジンはインターフェイスを介してストレージ エンジンと通信し、インターフェイスは異なるストレージ エンジン間の違いを保護します。現在、ストレージ エンジンは数多くあり、それぞれに独自の特徴がありますが、最も一般的なものは MyISAM と InnoDB です。
システム ファイル層 (ファイル システム)

この層は、データベース データとログをファイル システムに保存し、ストレージ エンジンとの対話を完了する役割を果たします。これは物理層です。ファイルのストレージ層。主にログ ファイル、データ ファイル、設定ファイル、pid ファイル、ソケット ファイルなどが含まれます。

  • ログ ファイル
    • エラー ログ (エラー ログ)
      • デフォルトで有効になり、「%log_error%」のような変数を表示します。
    • ##一般的なクエリ ログ
      • 一般的なクエリ ステートメントを記録し、「%general%」などの変数を表示します。
      #バイナリ ログ
    • 上で実行された変更操作を記録します。 MySQL データベースを使用し、ステートメントの発生時刻と実行時刻を記録しますが、データベースを変更しない select や show などの SQL は記録しません。主にデータベースのリカバリとマスター/スレーブ レプリケーションに使用されます。
      • show variables like '%log_bin%'; //有効にするかどうか
      • show variables like '%binlog%'; //パラメータ view
      • show binary logs; // ログ ファイルの表示
      スロー クエリ ログ
    • 実行時間がタイムアウトになったすべてのクエリ SQL を記録します。デフォルトは 10 秒です。
      • show variables like '%slow_query%'; //有効かどうか
      • show variables like '%long_query_time%'; //Duration
    #構成ファイル
  • # は、my.cnf、my.ini などのすべての MySQL 構成情報ファイルを保存するために使用されます。
    データ ファイル
  • db.opt ファイル: このライブラリで使用されるデフォルトの文字セットと検証ルールを記録します。
    • frm ファイル: テーブル構造の定義情報など、テーブルに関するメタデータ (メタ) 情報が格納されます。各テーブルには frm ファイルが存在します。
    • MYD ファイル: MyISAM ストレージ エンジン専用で、MyISAM テーブルのデータを保存します。各テーブルには .MYD ファイルがあります。
    • MYI ファイル: MyISAM ストレージ エンジン専用であり、MyISAM テーブルのインデックス関連情報を保存します。各 MyISAM テーブルは .MYI ファイルに対応します。
    • ibd ファイルおよび IBDATA ファイル: InnoDB データ ファイル (インデックスを含む) を保存します。 InnoDB ストレージ エンジンには、排他的テーブル スペースと共有テーブル スペースという 2 つのテーブル スペース モードがあります。排他的テーブル スペースは .ibd ファイルを使用してデータを保存し、各 InnoDB テーブルは 1 つの .ibd ファイルに対応します。共有テーブルスペースは .ibdata ファイルを使用し、すべてのテーブルは 1 つ (または複数の自己構成) .ibdata ファイルを使用します。
    • ibdata1 ファイル: テーブル メタデータ、Undo ログなどを保存するシステム テーブル スペース データ ファイル。
    • ib_logfile0、ib_logfile1 ファイル: REDO ログのログ ファイル。
    pid ファイル
  • pid ファイルは、Unix/Linux 環境の mysqld アプリケーションのプロセス ファイルです。他の多くの Unix/Linux サーバー プログラムと同様に、次のように保存されます。独自のプロセス ID。
    ソケット ファイル
  • ソケット ファイルも Unix/Linux 環境でのみ使用できます。ユーザーは Unix/Linux 環境で TCP/IP ネットワーク経由で接続する必要はありません。 Linux 環境: 代わりに、Unix ソケットを直接使用して MySQL に接続します。
    #2. MySQL の動作メカニズム

#
  1. 接続 (コネクタと接続プール) を確立し、クライアント/サーバー通信プロトコルを通じて MySQL との接続を確立します。 MySQL クライアントとサーバー間の通信方式は「半二重」です。 MySQL 接続ごとに、接続が何を行っているかを識別するためのスレッド ステータスが常に存在します。
    • 通信メカニズム:
      • 全二重: 電話をかけるなど、同時にデータを送受信できます。
      • 半二重: 同時にではなく、データの送信または受信のいずれかの特定の瞬間を指します。たとえば、初期のトランシーバー
      • simplex: データの送信のみ、またはデータの受信のみが可能です。例: one-way street;
    • Thread status: show processlist; //ユーザーが実行しているスレッド情報を表示します。root ユーザーはすべてのスレッドを表示でき、他のユーザーはすべてのスレッドを表示できます。自分のスレッドのみを表示します;
      • id: スレッド ID、kill xx を使用できます;
      • user: このスレッドを開始したユーザー
      • Host: の IP とポート番号リクエストを送信したクライアント
      • db : 現在のコマンドが実行されるライブラリ
      • Command: このスレッドで実行されている操作コマンド
        • Create DB: ライブラリの操作作成中です
        • Drop DB: ライブラリ操作が削除されています
        • Execute: PreparedStatement を実行しています
        • Close Stmt: PreparedStatement を閉じています
        • Query: 実行中ステートメント
        • ##Sleep: クライアントがステートメントを送信するのを待っています
        • Quit: 終了中
        • ##Shutdown: サーバーをシャットダウンしています
        • # #Time: スレッドが現在の状態にある時間を示します。単位は秒です
        State: スレッドのステータス
      • Updating: 一致するレコードの検索と変更を行っています
      • Sleeping : クライアントが新しいリクエストを送信するのを待っています
          #Starting: リクエスト処理が実行されています
        • Checking table: データ テーブルをチェックしています
        • Closing table: テーブル内のデータを更新していますテーブルをディスクにコピーします。
        • ロック: レコードは他のクエリによってロックされています。
        • データの送信: 選択クエリの処理と結果のクライアントへの送信を同時に行います。
        • 情報: 通常、スレッドによって実行されたステートメントを記録し、デフォルトで最初の 100 文字を表示します。完全なプロセス リストを表示したい場合は、show full processlist;
      • クエリ キャッシュ (キャッシュ&バッファ) を使用します。これは、MySQL がクエリを最適化できる場所です。クエリ キャッシュがオンになっており、クエリ キャッシュ プロセス中にまったく同じ SQL ステートメントがクエリされた場合は、クエリ結果がクライアントに直接返されます。クエリ キャッシュがオンになっていない場合、またはまったく同じ SQL ステートメントがクエリされていない場合は、パーサーは構文解析と意味解析を実行し、「解析ツリー」を生成します。
    • 選択クエリと SQL ステートメントの結果をキャッシュします。
  2. 選択クエリを実行するときは、まずキャッシュにクエリを実行して、使用可能なレコード セットがあるかどうか、および要件が正確に満たされているかどうかを判断します。同じ (パラメータ値を含む) ので、キャッシュされたデータのヒットと一致します。
    • クエリ キャッシュがオンになっている場合でも、次の SQL はキャッシュできません:
    • クエリ ステートメントは SQL_NO_CACHE## を使用します。
    • #クエリ結果が query_cache_limit 設定を超えています
    • now() など、クエリ内に不確実なパラメータがいくつかあります。
      • 「% のような変数を表示」 query_cache%'; //クエリ キャッシュが有効かどうか、スペース サイズ、制限などを確認します
      • show status like 'Qcache%'; //より詳細なキャッシュ パラメータ、利用可能なキャッシュ スペース、キャッシュ ブロックを表示します。キャッシュサイズなど。
    • パーサー(Parser)は、クライアントから送信されたSQLを構文解析し、「解析木」を生成します。プリプロセッサはさらに、いくつかの MySQL ルールに基づいて「解析ツリー」が正当であるかどうかをチェックします。たとえば、データ テーブルとデータ列が存在するかどうかをチェックし、名前とエイリアスがあいまいかどうかを解析して、最終的に新しい「解析ツリー」。
    • クエリ オプティマイザー (Optimizer) は、「解析ツリー」に基づいて最適な実行プランを生成します。 MySQL は、最適な実行プランを生成するために多くの最適化戦略を使用します。これは、静的最適化 (コンパイル時の最適化) と動的最適化 (実行時の最適化) の 2 つのカテゴリに分類できます。
      • 等価変換戦略
        • 5=5 および a>5 は a > 5に変更されます
        • a 5 に変更されますa =5
        • ジョイント インデックスに基づいて、条件の位置などを調整します。
      • カウント、最小、最大、その他の関数を最適化します
        • InnoDB エンジンの最小値関数はインデックスを見つけるだけで済みます。 左端の
        • InnoDB エンジン max 関数は、右端のインデックス
        • MyISAM エンジン カウント (*) を見つけるだけで済みます。計算は必要なく、直接返されます
      • 事前にクエリを終了します。
        • limit クエリを使用して、後続のデータの走査を続行せずに、limit に必要なデータを取得します。
      • 最適化of in
        • MySQL for in 最初にクエリが並べ替えられ、次にバイナリ メソッドがデータの検索に使用されます。たとえば、(2,1,3) の ID は (1,2,3) になります;
    • クエリ実行エンジンは SQL の実行を担当します。これにより、クエリ実行エンジンはクエリ結果を取得し、SQL ステートメント内のテーブルのストレージ エンジン タイプと、対応する API インターフェイスと基礎となるストレージ エンジン キャッシュまたは物理ファイルの間の対話に基づいてクライアントに返します。クエリ キャッシュを有効にすると、SQL 文とその結果はクエリ キャッシュ (Cache&Buffffer) に完全に保存され、今後同じ SQL 文が実行された場合には結果が直接返されます。
      • クエリ キャッシュが有効な場合は、最初にクエリ結果をキャッシュします。
      • 返された結果が多すぎる場合は、増分モードを使用して返します。
      • 実行を開始するときは、最初に判断する必要があります。このテーブル T に対してクエリを実行する権限がありますか? そうでない場合は、権限なしのエラーが返されます (クエリ キャッシュがヒットした場合、クエリ キャッシュが結果を返すときに権限の検証が行われます)クエリはオプティマイザーの前にも呼び出されます。事前チェックで権限を確認します)。
      • 権限がある場合は、テーブルを開いて実行を続行します。テーブルが開かれると、エグゼキューターはテーブルのエンジン定義に基づいてエンジンによって提供されるインターフェイスを使用します。エグゼキュータの実行プロセスは次のとおりです:
        • select * from test where age > 10;
        • InnoDB エンジン インターフェイスを呼び出して、このテーブルの最初の行を取得し、年齢が 10 であるかどうかを判断します。値は 10 です。そうでない場合はスキップします。はいの場合は、この行を結果セットに保存します。
        • エンジン インターフェイスを呼び出して「次の行」を取得し、最後の行まで同じ判断ロジックを繰り返します。テーブルが取得されます。
        • エグゼキューターは、上記の走査プロセス中に条件を満たすすべての行で構成されるレコード セットを結果セットとしてクライアントに返します。

3. Mysql ストレージ エンジン

ストレージ エンジンは、MySQL アーキテクチャの 3 番目の層に位置しており、 MySQL担当 ファイルを扱うサブシステムであり、MySQLが提供するファイルアクセス層の抽象インタフェースをベースにカスタマイズされたファイルアクセス機構であり、この機構をストレージエンジンと呼びます。

show Engines コマンドを使用して、現在のデータベースでサポートされているエンジン情報を表示します。 mysql アーキテクチャ原則の詳細な図による説明

バージョン 5.5 より前は、MyISAM ストレージ エンジンがデフォルトで使用され、5.5 からは InnoDB ストレージ エンジンが使用されました。

  • InnoDB: トランザクションをサポートし、コミット、ロールバック、およびクラッシュ回復機能、トランザクション セキュリティを備えています;
  • MyISAM: トランザクションと外部キーをサポートしません、高速アクセス速度;
  • メモリ: メモリを使用してテーブルを作成します。データはメモリ内にあるため、アクセス速度は非常に速く、デフォルトではハッシュ インデックスが使用されますが、一度閉じるとデータは失われます。
  • Archive : アーカイブ タイプ エンジン。挿入および選択ステートメントのみをサポートします。;
  • Csv: データ ストレージに CSV ファイルを使用します。ファイルの制限により、すべての列に非 null を指定する必要があります。また、CSV エンジンは、インデックスとパーティションをサポートしているため、データ交換用の中間テーブルに適しています。
  • BlackHole: ブラック ホール、入ることはできますが、出ることはできません。入ると消えます。挿入されたデータはすべて保存されません。 ;
  • フェデレーション: リモート MySQL データベース内のテーブルにアクセスできます。ローカル テーブルはデータを保存せず、リモート テーブルの内容にアクセスします。
  • MRG_MyISAM: MyISAM テーブルのグループの組み合わせ。これらの MyISAM テーブルは同じ構造を持つ必要があります。マージ テーブル自体にはデータがありません。マージ操作は MyISAM テーブルのグループに対して操作できます。

InnoDB と MyISAM の比較

  • トランザクションと外部キー
    • InnoDB はトランザクションと外部キーをサポートし、セキュリティと整合性を備えており、大量の挿入や外部キーに適しています。更新操作
    • MyISAM はトランザクションと外部キーをサポートしていませんが、多数の選択クエリ操作に適した高速ストレージと取得を提供します
  • ロック メカニズム
    • InnoDB は行レベルのロックをサポートし、指定されたレコードをロックします。ロックはインデックスに基づいて実装されます。
    • MyISAM はテーブルレベルのロックをサポートしており、テーブル全体をロックします。
  • インデックス構造
    • InnoDB はクラスター化インデックス (クラスター化インデックス) を使用しており、インデックスとレコードは一緒に保存され、インデックスとレコードの両方がキャッシュされます。
    • MyISAMはノンクラスタードインデックス(ノンクラスタードインデックス)を採用しており、インデックスとレコードが分離されています。
  • 同時実行処理機能
    • MyISAM はテーブル ロックを使用するため、書き込み操作の同時実行率が低くなり、読み取り間のブロックがなくなり、読み取りと書き込みがブロックされます。
    • InnoDB の読み取りおよび書き込みのブロックは分離レベルに関連付けることができ、マルチバージョン同時実行制御 (MVCC) を使用して高い同時実行性をサポートできます
  • ストレージ ファイル
    • InnoDB テーブルは、.frm テーブル構造ファイルと .ibd データ ファイルの 2 つのファイルに対応します。 InnoDB テーブルは最大 64 TB をサポートします。
    • MyISAM テーブルは、.frm テーブル構造ファイル、MYD テーブル データ ファイル、および .MYI インデックス ファイルの 3 つのファイルに対応します。
      MySQL5.0 以降、デフォルトの制限は 256 TB です。
  • 該当するシナリオ
    • MyISAM
      • トランザクション サポートは必要ありません (サポートされていません)
      • 同時実行性が比較的低い (ロック メカニズムの問題)
      • データの変更は比較的小さく、主に読み取りです
      • データの一貫性要件は高くありません
    • InnoDB
      • トランザクション サポートが必要です (優れたトランザクション特性)
      • 行レベルのロックは、高い同時実行性への優れた適応性を備えています
      • データ更新がより頻繁なシナリオ
      • 高いデータ一貫性要件
      • ハードウェア デバイスメモリが大きく、InnoDB の優れたキャッシュ機能を使用すると、メモリ使用率が向上し、ディスク IO が削減されます。
    • 概要
      • どちらかを選択する方法エンジンが2つ?
      • トランザクションは必要ですか?はい、InnoDB
      • には同時変更がありますか?はい、InnoDB
      • は高速なクエリと少ないデータ変更を追求していますか?はい、MyISAM
      • ほとんどの場合、InnoDB を使用することをお勧めします

#InnoDB ストレージ構造

MySQL バージョン 5.5 以降、InnoDB がデフォルトでエンジンとして使用され、トランザクション処理に優れ、自動クラッシュ回復機能が備わっています。以下は公式の InnoDB エンジン アーキテクチャ図であり、主にメモリ構造とディスク構造の 2 つの部分に分かれています。

mysql アーキテクチャ原則の詳細な図による説明

InnoDB メモリ構造

メモリ構造には、主にバッファ プール、変更バッファ、アダプティブ ハッシュ インデックス、ログの 4 つの主要コンポーネントが含まれています。バッファ。

  • バッファ プール: BP と呼ばれるバッファ プール。 BP はページに基づいており、デフォルト サイズは 16K です。BP の最下層は、リンク リスト データ構造を使用してページを管理します。 InnoDB がテーブル レコードとインデックスにアクセスすると、それらはページ ページにキャッシュされ、後で使用することでディスク IO 操作が軽減され、効率が向上します。
    • ページ管理メカニズム
      • ページはステータスに応じて 3 つのタイプに分類できます。
        1. 空きページ: アイドル ページ、未使用
        2. クリーン ページ: 使用済みページを使用しています。データは変更されていません。
        3. #dirty page: ダーティ ページ、ページを使用しています。データは変更されています。ページ内のデータとディスク上のデータは矛盾しています。
      • 上記の 3 つのページ タイプについて、InnoDB は 3 つのリンク リスト構造を通じてそれを維持および管理します。
        1. フリー リスト: 空きバッファを表し、空きページを管理します
        2. フラッシュ リスト: を表しますディスクにフラッシュする必要がある バッファはダーティ ページを管理し、内部ページは変更時刻によってソートされます。ダーティ ページはフラッシュ リンク リストと LRU リンク リストの両方に存在しますが、相互に影響しません。LRU リンク リストはページの可用性とストレージを管理し、フラッシュ リンク リストはフラッシュ操作を管理します。汚れたページの。
        3. lru リスト: 使用中のバッファを示し、クリーン ページとダーティ ページを管理します。バッファは中間点に基づいています。フロントのリンク リストは新しいリスト領域と呼ばれ、頻繁にアクセスされるデータが格納され、63% を占めます; 後者 リンクされたリストは旧リスト領域と呼ばれ、使用頻度の低いデータが格納され、37% を占めます。
    • LRU アルゴリズムのメンテナンスの改善
        通常の LRU: 末尾削除方式、リンク リストの先頭から新しいデータが追加され、スペースが解放されたときに末尾から削除されます。
      • 修正 LRU: リンク リストが次のように分割されます。要素を追加する場合、新旧の 2 つの部分に分割されます テーブルの先頭からではなく、中央の中点の位置から挿入されます すぐにデータにアクセスすると、ページは新しいリストの先頭に移動しますアクセスされていない場合、古いリストの最後に徐々に移動し、削除されるのを待ちます。
      • 新しいページ データがバッファ プールに読み込まれるたびに、InnoDb エンジンは空きページがあるかどうか、および空きページが十分であるかどうかを判断します。空きページがある場合は、空きページが空きリストから削除され、 LRU リストに追加されます。空きページがない場合、LRU リンク リストのデフォルト ページは LRU アルゴリズムに従って削除され、メモリ空間は解放されて新しいページに割り当てられます。
    • バッファ プール構成パラメータ
      • show variables like '%innodb_page_size%'; //ページ サイズの表示
      • show variables like '%innodb_old% ' ; //lru リスト内の古いリスト パラメータを表示します
      • show variables like '%innodb_buffer%'; //バッファ プール パラメータを表示します
      • 推奨事項: innodb_buffer_pool_size を合計の 60% に設定しますメモリ サイズ -80%、キャッシュ競合を避けるために innodb_buffer_pool_instances を複数に設定できます。
    #変更バッファ: CB と呼ばれる書き込みバッファ。 DML 操作を実行するときに、BP に対応するページ データがない場合、ディスク ページはバッファ プールにすぐにロードされず、代わりにバッファの変更が CB に記録され、将来のデータが読み取られるときにデータがロードされます。結合されてBP.middleに復元されます。
  • ChangeBuffer は BufferPool スペースを占有します。デフォルトは 25%、許容最大値は 50% です。読み取りおよび書き込みのビジネス量に応じて調整できます。パラメータ innodb_change_buffer_max_size;
    • レコードが更新されると、レコードは BufferPool に存在し、メモリ操作として BufferPool 内で直接変更されます。レコードが BufferPool に存在しない (ヒットなし) 場合は、ディスクにデータを問い合わせることなく、メモリ操作が ChangeBuffer で直接実行され、ディスク IO が回避されます。次回レコードがクエリされると、最初にディスクから情報が読み取られ、次に ChangeBuffer から情報が読み取られてマージされ、最後に BufferPool にロードされます。
    • 書き込みバッファ、一意でない通常のインデックス ページにのみ適用可能
    • インデックスに一意性が設定されている場合、InnoDB は変更時に一意性検証を実行する必要があるため、ディスクにクエリを実行する必要があります。 IO 操作。レコードは BufferPool に直接クエリされ、その後バッファ プール内で変更されます。ChangeBuffer では操作されません。
    アダプティブ ハッシュ インデックス: アダプティブ ハッシュ インデックス。BP データのクエリを最適化するために使用されます。 InnoDB ストレージ エンジンはテーブル インデックスの検索を監視し、ハッシュ インデックスを構築すると速度が向上することが確認された場合、ハッシュ インデックスを構築するため、これを適応型と呼びます。 InnoDB ストレージ エンジンは、アクセスの頻度とパターンに基づいて、特定のページのハッシュ インデックスを自動的に作成します。
  • ログ バッファ: ログ バッファは、ログ ファイル (やり直し/元に戻す) に書き込まれるデータをディスクに保存するために使用され、ログ バッファの内容は定期的にディスク ログ ファイルに更新されます。ログ バッファがいっぱいになると、自動的にディスクにフラッシュされます。BLOB や複数行の更新などの大規模なトランザクション操作が発生した場合、ログ バッファを増やすとディスク I/O を節約できます。
  • LogBuffer は主に InnoDB エンジン ログの記録に使用されます。REDO ログと UNDO ログは DML 操作中に生成されます。
    • LogBuffer スペースがいっぱいになると、自動的にディスクに書き込まれます。innodb_log_buffer_size パラメータを増やすことで、ディスク IO の頻度を減らすことができます。
    • innodb_flush_log_at_trx_commit パラメータは、ログの更新動作を制御します。デフォルトは 1
      • 0: ログ ファイルの書き込みとディスク操作のフラッシュは 1 秒ごとに行われます。 (ログ ファイル LogBuffer の書き込み --> OS キャッシュ、OScache --> ディスク ファイルのフラッシュ)、データは最大 1 秒間失われます
      • 1: トランザクションのコミット、ログ ファイルの書き込み、ディスクのフラッシュがすぐに行われます。データは失われませんが、頻繁な IO 操作が発生します。
      • ##2: トランザクションが送信され、ログ ファイルが直ちに書き込まれ、ディスク フラッシュ操作が 1 秒ごとに実行されます
    ## InnoDB ディスク構造

InnoDB ディスクには、主にテーブルスペース、InnoDB データ ディクショナリ、二重書き込みバッファ、REDO ログ、および UNDO ログが含まれています。

テーブルスペース: テーブル構造とデータを保存するために使用されます。表スペースは、システム表スペース、独立表スペース、一般表スペース、一時表スペース、UNDO表スペースおよびその他のタイプに分類されます。
  • システム表スペース(システム表スペース)
    • InnoDB データ ディクショナリ、二重書き込みバッファ、変更バッファ、および元に戻すログを含むストレージ領域。システム表スペースには、デフォルトでシステム表スペース内の任意のユーザーによって作成された表データと索引データも含まれます。システム表領域は複数の表で共有されるため、共有表領域です。このスペースのデータ ファイルはパラメータ innodb_data_file_path によって制御され、デフォルト値は ibdata1:12M:autoextend (ファイル名は ibdata1、12MB、自動的に拡張されます) です。

        CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //创建表空 间ts1 CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //将表添加到ts1 表空间
        ログイン後にコピー
      独立テーブルスペース (テーブルごとのファイルテーブルスペース)
    • はデフォルトで有効になっており、独立テーブルスペースは単一テーブルのテーブルスペースである場合、テーブルはシステムテーブルスペースではなく独自のデータファイルに作成されます。 innodb_file_per_table オプションが有効になっている場合、テーブルはテーブルスペースに作成されます。それ以外の場合、innodb はシステム テーブルスペースに作成されます。各テーブル ファイルのテーブルスペースは .ibd データ ファイルによって表され、デフォルトでデータベース ディレクトリに作成されます。表スペース表ファイルは、動的 (動的) および圧縮 (圧縮) 行フォーマットをサポートします。

      一般表領域
    • 一般表領域は、create tablespace 構文を使用して作成された共有表領域です。一般的なテーブル スペースは、mysql データ ディレクトリの外部の他のテーブル スペースに作成でき、複数のテーブルを収容でき、すべての行フォーマットをサポートします。

      Undo テーブルスペース
    • Undo テーブルスペースは 1 つ以上の Undo ログ ファイルで構成されます。 MySQL 5.7 より前では、Undo はシステム テーブルスペースの共有領域を占有していましたが、5.7 以降、Undo はシステム テーブルスペースから分離されました。

        InnoDB によって使用される UNDO テーブルスペースは、innodb_undo_tablespaces 構成オプションによって制御されます。デフォルトは 0 です。パラメータ値 0 はシステム表スペース ibdata1 を使用することを意味し、パラメータ値が 0 より大きい場合は UNDO 表スペース undo_001、undo_002 などを使用することを意味します。
      一時表領域
    • セッション一時表領域とグローバル一時表領域の 2 つのタイプに分かれています。

        セッション一時表領域ユーザーが作成した一時テーブルとディスク内の一時テーブルを保存します。
        1. グローバル一時表領域には、ユーザー一時表のロールバック・セグメント(ロールバック・セグメント)が格納されます。 mysql サーバーが正常にシャットダウンまたは異常終了すると、一時テーブルスペースは削除され、起動するたびに再作成されます。
    • データ ディクショナリ (InnoDB データ ディクショナリ)
  • InnoDB データ ディクショナリは内部システム テーブルで構成されますルックアップ テーブル、インデックス、テーブル フィールドなどのオブジェクトのメタデータを含むテーブルで構成されます。メタデータは物理的に InnoDB システム テーブルスペースに配置されます。歴史的な理由により、データ ディクショナリのメタデータは、InnoDB テーブル メタデータ ファイル (.frm ファイル) に格納されている情報とある程度重複します。

    • Doublewrite Buffer (Doublewrite Buffer)
  • は、システム テーブル スペースに配置され、記憶領域です。 BufferPage ページがディスク上の実際の場所に更新される前に、データは Doublewrite バッファに保存されます。ページの書き込み中にオペレーティング システム、ストレージ サブシステム、または mysqld プロセスがクラッシュした場合、InnoDB はクラッシュ リカバリ中に Doublewrite バッファからページの適切なバックアップを見つけることができます。ほとんどの場合、二重書き込みバッファーはデフォルトで有効になっています。二重書き込みバッファーを無効にするには、innodb_doublewrite を 0 に設定します。 Doublewrite バッファを使用する場合は、innodb_flush_method を O_DIRECT に設定することをお勧めします。

    MySQL の innodb_flush_method パラメータは、innodb データ ファイルと REDO ログのオープン モードとフラッシュ モードを制御します。 fdatasync (デフォルト)、O_DSYNC、O_DIRECT の 3 つの値があります。 O_DIRECT を設定すると、データ ファイルの書き込み操作で、データをキャッシュせず、事前読み取りを使用せず、InnodbBuffer からディスク ファイルに直接書き込むようにオペレーティング システムに通知されることを意味します。
    • デフォルトの fdatasync は、最初にオペレーティング システムのキャッシュに書き込み、次に fsync() 関数を呼び出して、データ ファイルと REDO ログのキャッシュ情報を非同期にフラッシュすることを意味します。
    • やり直しログ
    • REDO ログは、クラッシュ回復中に不完全なトランザクションによって書き込まれたデータを修正するために使用されるディスク ベースのデータ構造です。 MySQL は循環的な方法で REDO ログ ファイルを書き込み、InnoDB のバッファ プールへのすべての変更を記録します。インスタンス障害(停電など)が発生し、データファイルへのデータの更新に失敗した場合、データベースの再起動時にデータベースをやり直して、データファイルを再度更新する必要があります。読み取りおよび書き込みトランザクションの実行中、REDO ログは生成され続けます。デフォルトでは、REDO ログは、ib_logfile0 および ib_logfile1 という名前の 2 つのファイルによってディスク上に物理的に表されます。
  • Undo ログ

    • Undo ログは、トランザクションの開始前に保存された変更されたデータのバックアップであり、トランザクションのロールバックの例外に使用されます。 Undo ログは論理ログであり、行ごとに記録されます。 UNDO ログは、システム表領域、UNDO 表領域、および一時表領域に存在します。
  • #新しいバージョン構造の進化

    mysql アーキテクチャ原則の詳細な図による説明

      MySQL 5.7 バージョン
      • Undo ログ テーブルスペースは共有テーブルスペースの ibdata ファイルから分離されており、ファイルのサイズと数量は MySQL のインストール時にユーザーが指定できます。
      • 一時テーブルまたは一時クエリ結果セットのデータを保存する一時テーブル スペースが追加されました。
      • バッファ プールのサイズは、データベース インスタンスを再起動せずに動的に変更できます。
    • MySQL 8.0 バージョン
      • InnoDB テーブルのデータ ディクショナリと Undo は、共有テーブル スペース ibdata から完全に分離されました。以前は、データ ディクショナリと独立テーブルはスペース ibd ファイル内のデータ ディクショナリは一貫している必要がありますが、バージョン 8.0 では必要ありません。
      • temporary 一時テーブルスペースは複数の物理ファイルで構成することもできます。それらはすべて InnoDB ストレージ エンジンであり、インデックスを作成できるため、処理が高速化されます。
      • ユーザーは、Oracle データベースなどのいくつかの表スペースをセットアップできます。各表スペースは複数の物理ファイルに対応します。各表スペースは複数の表で使用できますが、1 つの表は 1 つの表スペースにのみ保管できます。
      • Doublewrite バッファは、共有テーブルスペース ibdata からも分離されています。
    InnoDB スレッド モデル

    mysql アーキテクチャ原則の詳細な図による説明

      IO Thread
      • は InnoDB AIO で広く使用されています(非同期 IO) は読み取りと書き込みに使用され、データベースのパフォーマンスを大幅に向上させることができます。
      • InnoDB には、4 つの書き込み、4 つの読み取り、1 つの挿入バッファー、および 1 つのログ スレッドを含む 10 個の IO スレッドがあります。
          読み取りスレッド: 読み取り操作とディスクからキャッシュ ページへのデータのロードを担当します。 4
        • 書き込みスレッド: 書き込み操作と、キャッシュされたダーティ ページのディスクへのフラッシュを担当します。 4
        • ログ スレッド: ログ バッファの内容をディスクにフラッシュする役割を果たします。 1
        • 挿入バッファ スレッド: 書き込みバッファの内容をディスクにフラッシュします。
    • Purge Thread
      • トランザクションがコミットされると、そのトランザクションで使用される Undo ログは不要になるため、Purge Thread をリサイクルする必要があります。割り当てられた元に戻すページ。
      • show variables like '%innodb_purge_threads%';
    • Page Cleaner Thread
      • この機能は、ダーティ データをディスクにフラッシュすることです。データはフラッシュされます。対応する REDO ログを上書きすることもできます。これにより、データが同期され、
      • REDO ログのリサイクルの目的が達成されます。ライトスレッドのスレッド処理が呼び出されます。
      • '%innodb_page_cleaners%' のような変数を表示;
    • マスター スレッド
      • マスター スレッドは InnoDB のメイン スレッドであり、他のスレッドのスケジュールを担当します。優先度 最高レベル。その機能は、バッファ プール内のデータをディスクに非同期的に更新して、データの一貫性を確保することです。含まれるもの: ダーティ ページのリフレッシュ (ページ クリーナー スレッド)、アンドゥ ページのリサイクル (パージ スレッド)、REDO ログのリフレッシュ (ログ スレッド)、マージされた書き込みバッファなど。内部には 2 つの主要なプロセスがあり、1 つは 1 秒ごと、もう 1 つは 10 秒ごとです。
      • 1 秒ごとの操作:
        • ログ バッファを更新してディスクにフラッシュします
        • 書き込みバッファ データをマージし、IO 読み取りおよび書き込みプレッシャーに基づいて操作するかどうかを決定します
        • ダーティ ページ データをディスクに更新し、ダーティ ページ率が 75% に達した場合にのみ動作します (innodb_max_dirty_pages_pct、
        • innodb_io_capacity)
      • 10 秒ごとの動作:
        • ダーティ ページ データをディスクにリフレッシュします。
        • 書き込みバッファ データをマージします。
        • ログ バッファをリフレッシュします。
        • 無駄なアンドゥ ページを削除します。
    InnoDB データ ファイル

    InnoDB ファイルのストレージ構造

    mysql アーキテクチャ原則の詳細な図による説明

    • InnoDB データファイルのストレージ構造

      • 分为 ibd数据文件 --> Segment(段)–>Extent(区)–> Page(页)–>Row(行)    
        • Tablesapce表空间,用于存储多个ibd数据文件,用于存储表的记录和索引。一个文件包含多个段。
        • Segment段,用于管理多个Extent,分为数据段(Leaf node segment)、索引段(Non-leaf node
          segment)、回滚段(Rollback segment)。一个表至少会有两个segment,一个管理数据,一个管理索引。每多创建一个索引,会多两个segment。
        • Extent区,一个区固定包含64个连续的页,大小为1M。当表空间不足,需要分配新的页资源,不会
          一页一页分,直接分配一个区。
        • Page页,用于存储多个Row行记录,大小为16K。包含很多种页类型,比如数据页,undo页,系统页,事务数据页,大的BLOB对象页。
        • Row行,包含了记录的字段值,事务ID(Trx id)、滚动指针(Roll pointer)、字段指针(Field
          pointers)等信息。
      • Page是文件最基本的单位,无论何种类型的page,都是由page header,page trailer和page body组成。如下图所示

    mysql アーキテクチャ原則の詳細な図による説明

    • InnoDB文件存储格式

      • 通过 SHOW TABLE STATUS 命令 查看

        mysql アーキテクチャ原則の詳細な図による説明

        • 一般情况下,如果row_format为REDUNDANT、COMPACT,文件格式为Antelope;如果row_format为DYNAMIC和COMPRESSED,文件格式为Barracuda。

        • 通过 information_schema 查看指定表的文件格式

          • select * from information_schema.innodb_sys_tables;
            ログイン後にコピー
    • File文件格式(File-Format)

      • 在早期的InnoDB版本中,文件格式只有一种,随着InnoDB引擎的发展,出现了新文件格式,用于支持新的功能。目前InnoDB只支持两种文件格式:Antelope 和 Barracuda。
        • Antelope: 先前未命名的,最原始的InnoDB文件格式,它支持两种行格式:COMPACT和REDUNDANT,MySQL 5.6及其以前版本默认格式为Antelope。
        • Barracuda: 新的文件格式。它支持InnoDB的所有行格式,包括新的行格式:COMPRESSED和 DYNAMIC。
      • 通过innodb_file_format 配置参数可以设置InnoDB文件格式,之前默认值为Antelope,5.7版本开始改为Barracuda。
    • Row行格式(Row_format)

    mysql アーキテクチャ原則の詳細な図による説明

    • 表的行格式决定了它的行是如何物理存储的,这反过来又会影响查询和DML操作的性能。如果在单个page页中容纳更多行,查询和索引查找可以更快地工作,缓冲池中所需的内存更少,写入更新时所需的I/O更少。

    • InnoDB存储引擎支持四种行格式:REDUNDANT、COMPACT、DYNAMIC和COMPRESSED。

    • DYNAMIC和COMPRESSED新格式引入的功能有:数据压缩、增强型长列数据的页外存储和大索引前缀。

    • 每个表的数据分成若干页来存储,每个页中采用B树结构存储;

    • 如果某些字段信息过长,无法存储在B树节点中,这时候会被单独分配空间,此时被称为溢出页,该字段被称为页外列。

      • REDUNDANT 行格式
        • 使用REDUNDANT行格式,表会将变长列值的前768字节存储在B树节点的索引记录中,其余
          的存储在溢出页上。对于大于等于786字节的固定长度字段InnoDB会转换为变长字段,以便
          能够在页外存储。
      • COMPACT 行格式
        • 与REDUNDANT行格式相比,COMPACT行格式减少了约20%的行存储空间,但代价是增加了
          某些操作的CPU使用量。如果系统负载是受缓存命中率和磁盘速度限制,那么COMPACT格式
          可能更快。如果系统负载受到CPU速度的限制,那么COMPACT格式可能会慢一些。
      • DYNAMIC 行格式
        • 使用DYNAMIC行格式,InnoDB会将表中长可变长度的列值完全存储在页外,而索引记录只包含指向溢出页的20字节指针。大于或等于768字节的固定长度字段编码为可变长度字段。DYNAMIC行格式支持大索引前缀,最多可以为3072字节,可通过innodb_large_prefix参数控制。
      • COMPRESSED 行格式
        • COMPRESSED行格式提供与DYNAMIC行格式相同的存储特性和功能,但增加了对表和索引
          数据压缩的支持。
    • 在创建表和索引时,文件格式都被用于每个InnoDB表数据文件(其名称与*.ibd匹配)。修改文件格式的方法是重新创建表及其索引,最简单方法是对要修改的每个表使用以下命令:

      • ALTER TABLE 表名 ROW_FORMAT=格式类型;
        ログイン後にコピー

    Undo Log

    Undo Log介绍

    • Undo:意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作。

    • Undo Log:数据库事务开始之前,会将要修改的记录存放到 Undo 日志里,当事务回滚时或者数据库崩溃时,可以利用 Undo 日志,撤销未提交事务对数据库产生的影响。

    • Undo Log产生和销毁:Undo Log在事务开始前产生;事务在提交时,并不会立刻删除undo log,innodb会将该事务对应的undo log放入到删除列表中,后面会通过后台线程purge thread进行回收处理。Undo Log属于逻辑日志,记录一个变化过程。例如执行一个delete,undolog会记录一个insert;执行一个update,undolog会记录一个相反的update。

    • Undo Log存储:undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollback segment回滚段,内部包含1024个undo log segment。可以通过下面一组参数来控制Undo log存储。

    • #相关参数命令
      
      show variables like '%innodb_undo%';
      ログイン後にコピー

    Undo Log作用

    • 实现事务的原子性
      • Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中,如果出现了错误或者用户执行了 ROLLBACK 语句,MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。
    • 实现多版本并发控制(MVCC)

      • Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前,Undo Log保存了未提交之前的版本数据,Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快照读。

    mysql アーキテクチャ原則の詳細な図による説明

    • 事务A手动开启事务,执行更新操作,首先会把更新命中的数据备份到 Undo Buffer 中;
    • 事务B手动开启事务,执行查询操作,会读取 Undo 日志数据返回,进行快照读;

    • Redo Log 和 Binlog

    Redo Log 日志

    • Redo Log 介绍

      • Redo:顾名思义就是重做。以恢复操作为目的,在数据库发生意外时重现操作。
      • Redo Log:指事务中修改的任何数据,将最新的数据备份存储的位置(Redo Log),被称为重做日志。
      • Redo Log 的生成和释放:随着事务操作的执行,就会生成Redo Log,在事务提交时会将产生Redo Log写入Log Buffer,并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后,Redo Log 的使命也就完成了,Redo Log占用的空间就可以重用(被覆盖写入)。
    • Redo Log工作原理

    mysql アーキテクチャ原則の詳細な図による説明

    • Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点,尚有脏页未写入表
      的 IBD 文件中,在重启 MySQL 服务的时候,根据 Redo Log 进行重做,从而达到事务的未入磁盘
      数据进行持久化这一特性。
    • Redo Log写入机制

      Redo Log 文件内容是以顺序循环的方式写入文件,写满时则回溯到第一个文件,进行覆盖写。

    mysql アーキテクチャ原則の詳細な図による説明

      • write pos 是当前记录的位置,一边写一边后移,写到最后一个文件末尾后就回到 0 号文件开头;
      • checkpoint 是当前要擦除的位置,也是往后推移并且循环的,擦除记录前要把记录更新到数据文件;
      • write pos 和 checkpoint 之间还空着的部分,可以用来记录新的操作。如果 write pos 追上checkpoint,表示写满,这时候不能再执行新的更新,得停下来先擦掉一些记录,把 checkpoint推进一下。
    • Redo Log相关配置参数

      • 每个InnoDB存储引擎至少有1个重做日志文件组(group),每个文件组至少有2个重做日志文件,默认为ib_logfile0和ib_logfile1。可以通过下面一组参数控制Redo Log存储:

        • show variables like '%innodb_log%';
          ログイン後にコピー
      • Redo Buffer 持久化到 Redo Log 的策略,可通过 Innodb_flush_log_at_trx_commit 设置:

    mysql アーキテクチャ原則の詳細な図による説明

    • 0:每秒提交 Redo buffer ->OS cache -> flush cache to disk,可能丢失一秒内的事务数据。由后台Master线程每隔 1秒执行一次操作。
    • 1(默认值):每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk,最安全,性能最差的方式。
    • 2:每次事务提交执行 Redo Buffer -> OS cache,然后由后台Master线程再每隔1秒执行OS cache -> flush cache to disk 的操作。
    • 一般建议选择取值2,因为 MySQL 挂了数据没有损失,整个服务器挂了才会损失1秒的事务提交数
      据。

    Binlog日志

    • Binlog 记录模式

      • Redo Log 是属于InnoDB引擎所特有的日志,而MySQL Server也有自己的日志,即 Binary log(二进制日志),简称Binlog。Binlog是记录所有数据库表结构变更以及表数据修改的二进制日志,不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录,还包含语句所执行的消耗时间。开启Binlog日志有以下两个最重要的使用场景。
        • 主从复制:在主库中开启Binlog功能,这样主库就可以把Binlog传递给从库,从库拿到Binlog后实现数据恢复达到主从数据一致性。
        • 数据恢复:通过mysqlbinlog工具来恢复数据。
      • Binlog文件名默认为“主机名_binlog-序列号”格式,例如oak_binlog-000001,也可以在配置文件中指定名称。文件记录模式有STATEMENT、ROW和MIXED三种,具体含义如下。
        • ROW(row-based replication, RBR):日志中会记录每一行数据被修改的情况,然后在slave端对相同的数据进行修改。
          • 优点:能清楚记录每一个行数据的修改细节,能完全实现主从数据同步和数据的恢复。
          • 缺点:批量操作,会产生大量的日志,尤其是alter table会让日志暴涨。
        • STATMENT(statement-based replication, SBR):每一条被修改数据的SQL都会记录到master的Binlog中,slave在复制的时候SQL进程会解析成和原来master端执行过的相同的SQL再次执行。简称SQL语句复制。
          • 优点:日志量小,减少磁盘IO,提升存储和恢复速度
          • 缺点:在某些情况下会导致主从数据不一致,比如last_insert_id()、now()等函数。
        • MIXED(mixed-based replication, MBR):以上两种模式的混合使用,一般会使用STATEMENT模式保存binlog,对于STATEMENT模式无法复制的操作使用ROW模式保存binlog,MySQL会根据执行的SQL语句选择写入模式。
    • Binlog 文件结构

      • MySQL的binlog文件中记录的是对数据库的各种修改操作,用来表示修改操作的数据结构是Log event。不同的修改操作对应的不同的log event。比较常用的log event有:Query event、Row event、Xid event等。binlog文件的内容就是各种Log event的集合。
      • Binlog文件中Log event结构如下图所示:

    mysql アーキテクチャ原則の詳細な図による説明

    • Binlog写入机制

      • 根据记录模式和操作触发event事件生成log event(事件触发执行机制)
      • 将事务执行过程中产生log event写入缓冲区,每个事务线程都有一个缓冲区Log Event保存在一个binlog_cache_mngr数据结构中,在该结构中有两个缓冲区,一个是stmt_cache,用于存放不支持事务的信息;另一个是trx_cache,用于存放支持事务的信息。
      • 事务在提交阶段会将产生的log event写入到外部binlog文件中。
      • 不同事务以串行方式将log event写入binlog文件中,所以一个事务包含的log event信息在binlog文件中是连续的,中间不会插入其他事务的log event。
    • Binlog文件操作

      • 根据记录模式和操作触发event事件生成log event(事件触发执行机制)
      • 将事务执行过程中产生log event写入缓冲区,每个事务线程都有一个缓冲区
      • Log Event保存在一个binlog_cache_mngr数据结构中,在该结构中有两个缓冲区,一个是stmt_cache,用于存放不支持事务的信息;另一个是trx_cache,用于存放支持事务的信息。
      • 事务在提交阶段会将产生的log event写入到外部binlog文件中。
      • 不同事务以串行方式将log event写入binlog文件中,所以一个事务包含的log event信息在
        binlog文件中是连续的,中间不会插入其他事务的log event。
    • Binlog文件操作

      • Binlog状态查看

        • show variables like 'log_bin';
          ログイン後にコピー
      • 开启Binlog功能

        • set global log_bin = mysqllogbin; 
          ERROR 1238 (HY000): Variable 'log_bin' is a read only variable
          ログイン後にコピー
        • 需要修改my.cnf或my.ini配置文件,在[mysqld]下面增加log_bin=mysql_bin_log,重启MySQL服务。

        • #log-bin=ON 
          #log-bin-basename=mysqlbinlog 
          binlog-format=ROW 
          log-bin=mysqlbinlog
          ログイン後にコピー
      • 使用show binlog events命令

        • show binary logs; //等价于show master logs; 
          
          show master status; 
          
          show binlog events; 
          
          show binlog events in 'mysqlbinlog.000001';
          ログイン後にコピー
      • 使用 mysqlbinlog 命令

        • mysqlbinlog "文件名" 
          
          mysqlbinlog "文件名" > "test.sql"
          ログイン後にコピー
      • 使用 binlog 恢复数据

        • //按指定时间恢复 
          mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop- datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql -uroot -p1234 
          
          //按事件位置号恢复 
          mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234
          ログイン後にコピー
        • mysqldump:定期全部备份数据库数据。mysqlbinlog可以做增量备份和恢复操作。

      • 删除Binlog文件

        • purge binary logs to 'mysqlbinlog.000001'; //删除指定文件 
          
          purge binary logs before '2020-04-28 00:00:00'; //删除指定时间之前的文件 
          
          reset master; //清除所有文件
          ログイン後にコピー
        • 可以通过设置expire_logs_days参数来启动自动清理功能。默认值为0表示没启用。设置为1表示超出1天binlog文件会自动删除掉。

    • Redo Log和 Binlog区别

      • Redo Log是属于InnoDB引擎功能,Binlog是属于MySQL Server自带功能,并且是以二进制文件记录。
      • Redo Log属于物理日志,记录该数据页更新状态内容,Binlog是逻辑日志,记录更新过程。
      • Redo Log日志是循环写,日志空间大小是固定,Binlog是追加写入,写完一个写下一个,不会覆盖使用。
      • Redo Log作为服务器异常宕机后事务数据自动恢复使用,Binlog可以作为主从复制和数据恢复使用。Binlog没有自动crash-safe能力。

    推荐学习:mysql视频教程

    以上がmysql アーキテクチャ原則の詳細な図による説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

    関連ラベル:
    ソース:csdn.net
    このウェブサイトの声明
    この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
    最新の問題
    人気のチュートリアル
    詳細>
    最新のダウンロード
    詳細>
    ウェブエフェクト
    公式サイト
    サイト素材
    フロントエンドテンプレート