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 がメンテナンスのためにマスターとスレーブを切り替える必要があるシナリオに特に適しています。このアーキテクチャでは、図に示すように、スレーブライブラリを繰り返し構築する手間が省けます。