MySQL レプリケーションの利点と原則を詳しく説明します

MySQL レプリケーションの利点と原則を詳しく説明します

レプリケーションとは、マスター データベースの DDL および DML 操作をバイナリ ログを介してスレーブ データベースに転送し、スレーブ データベースでそれらを再実行することで、スレーブ データベースとマスター データベースのデータの同期を維持することです。 MySQL は、1 つのマスター データベースから複数のスレーブ データベースに同時に複製することができ、スレーブ データベースは他のスレーブ データベースのマスター データベースとして機能して、チェーン複製を実現することもできます。

MySQL レプリケーションの利点:

  • マスター データベースに障害が発生した場合、サービスはスレーブ データベースにすぐに切り替えられます。
  • スレーブ データベースでクエリ操作を実行して、マスター データベースへのアクセス負荷を軽減します。
  • バックアップ中にマスター データベースに影響を与えないように、スレーブ データベースでバックアップを実行します。

MySQL レプリケーションの原理

1. トランザクションがコミットされると、MySQL マスター データベースはデータの変更を Binlog にイベントとして記録します。マスター データベースの sync_binlog パラメータは、Binlog ログのディスクへのフラッシュを制御します。

2. マスター データベースは、Binlog 内のイベントをスレーブ データベースのリレー ログにプッシュします。スレーブ データベースは、リレー ログに基づいてイベントをやり直し、論理レプリケーションを通じてマスター データベースとスレーブ データベース間のデータの一貫性を実現します。

MySQL は、マスター データベースとスレーブ データベース間のデータ レプリケーションを完了するために 3 つのスレッドを使用します。Binlog Dump スレッドはマスター データベースで実行され、I/O スレッドと SQL スレッドはスレーブ データベースで実行されます。スレーブでレプリケーションを開始すると、まずマスターに接続するための I/O スレッドが作成されます。次に、マスターは Binlog Dump スレッドを作成し、データベース イベントを読み取り、それを I/O スレッドに送信します。I/O スレッドはイベント データを取得した後、それをスレーブのリレー ログに更新します。次に、スレーブの SQL スレッドがリレー ログ内の更新されたデータベース イベントを読み取り、それを適用します。

次の図に示すように:


メインライブラリを表示:

mysql> プロセスリストを表示\G; 
************************** 1. 行 **************************** 
   識別子: 3 
  ユーザー: root 
  ホスト: 10.24.33.187:54194 
   デシベル: NULL 
コマンド: スリープ 
  時間: 176 
 州:  
  情報: NULL 
************************** 2. 行 **************************** 
   識別子: 4 
  ユーザー: root 
  ホスト: 10.24.33.187:54195 
   デシベル: NULL 
コマンド: スリープ 
  時間: 176 
 州:  
  情報: NULL 
************************** 3. 行 **************************** 
   識別子: 8 
  ユーザー: root 
  ホスト: ローカルホスト 
   db:テスト 
コマンド: クエリ 
  時間: 0 
 状態: 開始 
  情報: プロセスリストを表示 
************************** 4. 行 **************************** 
   識別子: 12 
  ユーザー: repl 
  ホスト: dsz884.hcg.homecredit.net:39731 
   デシベル: NULL 
コマンド: Binlog Dump --Binlog Dump スレッド 時間: 87 
 状態: マスターはすべてのバイナリログをスレーブに送信しました。さらに更新を待機しています。このことから、同期が「プッシュ」方式で行われていることがわかります。情報: NULL 
セット内の 4 行 (0.00 秒) 
 
エラー:  
クエリが指定されていません

バックアップ ライブラリを表示します。

mysql> プロセスリストを表示\G; 
************************** 1. 行 **************************** 
   識別子: 1 
  ユーザー: システムユーザー 
  ホスト:  
   デシベル: NULL 
コマンド: 接続 
  時間: 4427 
 状態: マスターがイベントを送信するのを待機中 
  情報: NULL 
************************** 2. 行 **************************** 
   識別子: 2 
  ユーザー: システムユーザー 
  ホスト:  
   デシベル: NULL 
コマンド: 接続 
  時間: 2044 
 状態: スレーブはすべてのリレーログを読み取りました。さらに更新を待機しています。 
  情報: NULL

このことから、MySQL レプリケーションは非同期であり、スレーブ データベースとマスター データベースの間に一定の遅延があることがわかります。

関連ログをコピーする

1. BinlogBinlog は、MySQL のすべてのデータ変更操作を記録します。Binlog の形式は、次の方法で表示できます。Statement、Row、Mixed の 3 つのタイプがあります。

mysql> '%binlog_format%' のような変数を表示します。 
+---------------+-------+ 
| 変数名 | 値 | 
+---------------+-------+ 
| binlog_format | 行 | 
+---------------+-------+ 
セット内の 1 行 (0.00 秒)

2. リレー ログ リレー ログのファイル形式と内容は Binlog と同じです。唯一の違いは、スレーブの SQL スレッドが現在のリレー ログ内のイベントを実行した後、SQL スレッドがスペースを解放するためにリレー ログを自動的に削除することです。スレーブがクラッシュして再起動した後も、スレーブの I/O スレッドと SQL スレッドがレプリケーションを開始する場所を確実に認識できるように、スレーブはデフォルトで 2 つのログ ファイル (master.info と relay-log.info) を作成し、レプリケーションの進行状況を保存します。これらの 2 つのファイルには、現在マスターの Binlog を読み取っているスレーブの I/O スレッドの進行状況と、リレー ログを適用している SQL スレッドの進行状況が記録されます。

mysql> スレーブステータスを表示します \G; 
************************** 1. 行 **************************** 
        Slave_IO_State: マスターがイベントを送信するのを待機中 
         Master_Host: 10.24.33.186 -- メインデータベース IP 
         Master_User: repl -- マスタースレーブレプリケーションに使用されるマスターデータベースのユーザーアカウント Master_Port: 3306 -- マスターデータベースポート Connect_Retry: 60  
       Master_Log_File: mysql-bin.000005 --スレーブ ライブラリ I/O スレッドによって現在読み取られているマスター ライブラリ Binlog のファイル名 Read_Master_Log_Pos: 4356 --スレーブ ライブラリ I/O スレッドによって読み取られたマスター ライブラリ Binlog の位置 Relay_Log_File: strong-relay-bin.000006 --SQL スレッドによって適用されているリレー ログ 
        Relay_Log_Pos: 320 --リレーログの場所 Relay_Master_Log_File: mysql-bin.000005 --リレーログに対応するBinlog 
       スレーブIO実行中: はい 
      スレーブSQL実行中: はい 
       レプリケート_Do_DB:  
     レプリケート_無視_DB:  
      テーブルの複製:  
    無視テーブルを複製:  
   Replicate_Wild_Do_Table:  
 Replicate_Wild_Ignore_Table:  
          最終エラー番号: 0 
          最終エラー:  
         スキップカウンタ: 0 
     Exec_Master_Log_Pos: 4356 --SQL スレッドは、Binlog の場所に対応するリレー ログの場所を適用しています。Relay_Log_Space: 1153 
       Until_Condition: なし 
        ログファイルまで:  
        ログ位置まで: 0 
      マスターSSL許可: いいえ 
      マスターSSLCAファイル:  
      マスターSSLCAパス:  
       マスターSSL証明書:  
      マスターSSL暗号:  
        マスターSSLキー:  
    マスターより遅れている秒数: 0 
Master_SSL_Verify_Server_Cert: いいえ 
        最終IOエラー番号: 0 
        最後のIOエラー:  
        最終SQLエラー番号: 0 
        最後のSQLエラー:  
 Replicate_Ignore_Server_Ids:  
       マスターサーバーID: 1 
         マスター_UUID: 2a3e3fd9-0587-11e8-bdb8-0800272325a8 
       マスター情報ファイル: /usr/local/mysql-5.7.21-el7-x86_64/data/master.info 
          SQL_遅延: 0 
     SQL_残り遅延: NULL 
   Slave_SQL_Running_State: スレーブはすべてのリレーログを読み取りました。さらに更新を待機しています。 
      マスター再試行回数: 86400 
         マスターバインド:  
   最終IOエラータイムスタンプ:  
   最終SQLエラータイムスタンプ:  
        マスターSSL証明書:  
      マスターSSLCrlパス:  
      取得済み_Gtid_Set:  
      実行されたGtidセット:  
        自動位置: 0 
     Replicate_Rewrite_DB:  
         チャンネル名:  
      マスター TLS バージョン:  
セット内の 1 行 (0.00 秒) 
 
エラー:  
クエリが指定されていません 
 
マイSQL>

MySQL レプリケーション方法

MySQL レプリケーションの 3 つのテクノロジーに対応する 3 つの Binlog 形式があります。

MySQL レプリケーション アーキテクチャ

MySQL レプリケーションの一般的なアーキテクチャには、1 つのマスターと複数のスレーブのレプリケーション アーキテクチャ、マルチレベル レプリケーション アーキテクチャ、およびデュアル マスター レプリケーション (デュアル マスター) アーキテクチャがあります。

1. 1 マスター - 複数スレーブ アーキテクチャ マスター データベースの読み取り要求の負荷が非常に高いシナリオでは、1 マスター - 複数スレーブ レプリケーション アーキテクチャを構成することで、読み取りと書き込みの分離が実現されます。高いリアルタイム パフォーマンスを必要としない読み取り要求は、負荷分散によって複数のスレーブ データベースに分散され、図に示すように、マスター データベースの読み取り負荷が軽減されます。


2. マルチレベル レプリケーション アーキテクチャ 1 つのマスターと複数のスレーブのアーキテクチャは、特に高い読み取り要求圧力があるほとんどのシナリオのニーズを解決できます。MySQL レプリケーションは、マスター データベースが Binlog をスレーブ データベースにプッシュするため、スレーブ データベースの増加に伴って、マスター データベースの I/O 圧力とネットワーク圧力が増加します (各スレーブ データベースには、マスター データベース上に Binlog イベントを送信するための独立した Binlog Dump スレッドがあります)。マルチレベル レプリケーション アーキテクチャは、図に示すように、1 つのマスターと複数のスレーブのシナリオで、マスター データベースの追加 I/O とネットワーク圧力のシナリオを解決します。

3. デュアル マスター レプリケーション/デュアル マスター アーキテクチャ デュアル マスター レプリケーション/デュアル マスター アーキテクチャは、DBA がメンテナンスのためにマスターとスレーブを切り替える必要があるシナリオに特に適しています。このアーキテクチャでは、図に示すように、スレーブ ライブラリを繰り返し構築する手間が省けます。

以下もご興味があるかもしれません:
  • MySQLのレプリケーションとチューニングの原則と方法を分析する
  • Linux での MySQL データベースのマスター スレーブ同期レプリケーション構成
  • MySql マスタースレーブレプリケーションを実装する Docker 方式の詳細説明 (実践編)
  • MySQLのレプリケーションの詳細な分析
  • MySQL 高可用性ソリューション MMM (MySQL マルチマスター レプリケーション マネージャー)
  • MySQL 5.7.18 マスタースレーブレプリケーション設定(マスター 1 台とスレーブ 1 台)チュートリアルの詳細な説明
  • Mysql5.7.18 のインストールとマスタースレーブレプリケーションの詳細なグラフィック説明
  • MySQL マスタースレーブレプリケーションプロセスの詳細な説明
  • pt-heartbeat を使用して MySQL レプリケーションの遅延を監視する方法の詳細な説明
  • MySQL マスタースレーブレプリケーションの読み書き分離構造の詳細な説明
  • docker を使用して MySQL マスタースレーブレプリケーション環境を迅速に構築する方法の詳細な説明
  • MySQL の準同期レプリケーションについての簡単な説明

<<:  Linux システムに Spring Boot アプリケーションをインストールするための詳細なチュートリアル

>>:  いくつかの面接の質問を使ってJavaScriptの実行メカニズムを調べる

推薦する

要素テーブルヘッダー行の高さの問題の解決

目次序文1. 問題の原因2. 解決策VueはelementUIテーブルtr thの高さと背景色を変更...

div の水平レイアウトを両側に揃える 3 つの方法

この記事では、主に、div の水平レイアウトの両側の配置を実装する 3 つの方法を紹介し、それらを共...

nginx を最適化する 6 つの方法

1. Nginxの同時実行性を最適化する [root@proxy ~]# ab -n 2000 -c...

MySQLはOracleシーケンスに似たソリューションを実装しています

MySQLはOracleのようなシーケンスを実装しているOracle は通常、主キー フィールドを処...

VUEプロジェクトでXSS攻撃に遭遇した実体験

目次序文原因を発見するカスタムフィルタリングルール要約する序文インターネットの急速な発展に伴い、情報...

MySQLの自動増分主キーIDはこのように処理されません

MySQLの自動増分主キーIDは段階的に増加しません1. はじめにMySQL データベースにデータを...

HTML 5.1 学習: 14 の新機能とアプリケーション例

序文ご存知のとおり、HTML5 はインターネット コミュニティ全体に標準を提供する組織である Wor...

JavaScript クロージャの説明

目次1. クロージャとは何ですか? 1.2 クロージャのメモ化: 関数は定義された環境を記憶する1....

JavaScript関数導入の詳しい説明

目次機能紹介関数関数の作成コンストラクタは関数を作成する関数宣言は関数を作成する関数式関数を作成する...

Tomcat は親の委任メカニズムを破壊して Web アプリケーションの分離を実現します。

目次Tomcat クラスローダー階層WebAppクラスローダー共有クラスローダーカタリナクラスローダ...

一般的な MySQL 関数の例の概要 [集計関数、文字列、数値、時刻と日付の処理など]

この記事では、よく使用される MySQL 関数について説明します。ご参考までに、詳細は以下の通りです...

CentOSにDockerをインストールする方法

ここでは比較的簡単なインストール方法のみを紹介します。 1. yumを使用してインストールするyum...

Dockerの核となる原則であるCgroupの詳細な説明

カーネル内の強力なツール cgroup は、NameSpace によって分離されたリソースを制限でき...

React Router で履歴リダイレクトを使用する方法

react-routerでは、コンポーネント内のジャンプは<Link>で使用できます。し...

全体的なユーザーエクスペリエンスを確保する方法

関連記事:ユーザーエクスペリエンスのためのウェブサイトデザイン今朝、GMail がまた不調になり、接...