MySQLのレプリケーションの詳細な分析

1.MySQLレプリケーションの概念

これは、プライマリ データベースの DDL および DML 操作をバイナリ ログを介してレプリケーション サーバーに転送し、レプリケーション サーバーでこれらのログ ファイルを再実行して、レプリケーション サーバーとプライマリ サーバーのデータを同期させることを意味します。レプリケーション プロセスでは、1 つのサーバーがマスターとして機能し、1 つ以上の他のサーバーがスレーブとして機能します。マスターはバイナリ ログ ファイルへの更新を書き換え、ログのローテーションを追跡するためにファイルのインデックスを維持します。これらのログには、スレーブ サーバーに送信された更新が記録されます。スレーブがマスターに接続すると、スレーブがログで読み取った最後の成功した更新の場所がマスターに通知されます。スレーブは、その時点から発生するすべての更新を受け入れ、その後ブロックして、マスターからの新しい更新の通知を待機します。

2. 複製の目的

データはマスタースレーブレプリケーションを通じて同期され、読み取り/書き込み分離 (mysql-proxy) を使用してデータベースの同時負荷容量が向上します。また、マスタースレーブ設計として使用することで、ホストが応答を停止した後でも、アプリケーションをバックアップマシンに切り替えて非常に短時間で実行を継続できるようにします。

利点:

（１）データベースクラスタシステムには複数のデータベースノードがあり、１つのノードに障害が発生しても、他の正常なノードがサービスを継続することができます。
（２）マスターサーバーに問題が発生した場合、スレーブサーバーに切り替えることができます。 （３）レプリケーションにより、スレーブサーバー上でクエリ操作を実行できるため、マスターサーバーのアクセス負荷が軽減され、データ分散と負荷分散が実現します。 （４）スレーブサーバー上でバックアップを実行することで、バックアップ期間中にマスターサーバーのサービスに影響を与えないようにすることができます。

3. レプリケーションの実装（3つの方法）

（1）DRBDは、ブロックデバイスの内容をサーバー間でミラーリングする、ソフトウェア実装の非共有ストレージレプリケーションソリューションです。
（2）MySQLクラスタ（MySQLクラスタとも呼ばれる）。 MySQL レプリケーション自体は比較的単純な構造で、スレーブ サーバー (スレーブ) がマスター サーバー (マスター) からバイナリ ログを読み取り、解析して自分自身に適用します。
（3）シンプルなレプリケーション環境では、MySQL を実行するホストが 2 つだけ必要です。1 つの物理サーバー ホストで 2 つの mysqld インスタンスを起動することもできます。 1 つはマスターとして使用され、もう 1 つはスレーブとして使用され、レプリケーション環境が完成します。ただし、実際のアプリケーション環境では、MySQL レプリケーション機能を使用して、最も一般的に使用されるマスター スレーブ アーキテクチャなど、実際のビジネス ニーズに基づいて、よりスケーラブルなさまざまなレプリケーション アーキテクチャを構築できます。
マスタースレーブアーキテクチャとは、1 つの MySQL サーバーをマスターとして使用し、1 つ以上の MySQL サーバーをスレーブとして使用して、マスターのデータをスレーブにコピーすることを指します。実際のアプリケーション シナリオでは、マスター スレーブ アーキテクチャ モードが MySQL レプリケーションに最も一般的に使用されます。一般的に、このアーキテクチャでは、システムの書き込み操作はマスターで実行され、読み取り操作は各スレーブに分散されます。そのため、このアーキテクチャは、インターネットの現在の高い読み取りおよび書き込みの問題に特に適しています。

Mysql データベースのレプリケーション操作は、おおまかに次の手順に分かれます。

（１）マスターはバイナリログを有効にする。バイナリ ログを有効にする操作については、「ログ管理」で詳しく説明します。
（２）スレーブ上のI/Oプロセスはマスターに接続し、指定されたログファイルの指定された位置以降（またはログの先頭から）のログ内容を要求します。
（３）マスターがスレーブからのI/O処理要求を受信すると、レプリケーションを担当するI/Oプロセスは要求情報に従って指定されたログの指定された位置以降のログ情報を読み取り、スレーブのI/Oに返す。返される情報には、ログに含まれる情報に加えて、マスター側に送信された bin-log ファイルの名前と bin-log の場所も含まれます。
（４）スレーブのI/Oプロセスは、情報を受信すると、受信したログ内容をスレーブのリレーログファイルの末尾に順次追加し、読み込んだマスターのbin-logのファイル名と場所をマスター情報ファイルに記録する。
（５）スレーブのSQLプロセスはリレーログ内の新しい内容を検出すると、すぐにリレーログの内容を解析し、それ自身で実行します。

4. MySQLレプリケーションの集中モード

MySQL 5.1 以降のバージョンでは、レプリケーションの改善として、新しいレプリケーション テクノロジである行ベースのレプリケーションが導入されました。このテクノロジーは、以前の binlog モードではなく、テーブル内で変更されたレコードに重点を置いています。 MySQL 5.1.12 以降では、次の 3 つのモードを使用してこれを実現できます。

（１）SQL文ベースのレプリケーション（SBR）
（２）行ベースのレプリケーション（rbr）
（３）混合モードレプリケーション（mbr）

それに応じて、binlog にはステートメント、行、混合の 3 つの形式があります。 Mbr モードでは、sbr モードがデフォルトです。 binlog 形式は実行時に動的に変更できます。マスタースレーブレプリケーションモードを設定する方法は非常に簡単です。次のように、以前のレプリケーション構成に基づいてもう 1 つのパラメータを追加するだけです。

binlog_format = "ステートメント"
#binlog_format="行"
#binlog_format=”混合”

もちろん、実行時にbinlog形式を動的に変更することもできます。

Mysql> セッション binlog_format="statement" を設定します

5. メインサーバーの動作を制御する

マスター: 192.168.11.139
スレーブ: 192.168.11.130

（１）プライマリサーバー：

mysql> '%datadir%' のような変数を表示します。
+---------------+--------------------------+
| 変数名 | 値 |
+---------------+--------------------------+
| データディレクトリ | /application/mysql/data/ |
+---------------+--------------------------+

プライマリ サーバーでバイナリ ログを有効にします。

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

OFFはバイナリログが閉じていることを意味します

ログ 3 を有効にする手順:

①mysqlインストールディレクトリ/my.cnfを開く
② [mysqld] タグを見つけて、その下の行に次の文を追加します。

log_bin[ファイル名]

このステートメントでは、log-bin はバイナリ ファイルを開くことを示します。filename はバイナリ ログの名前です。指定されていない場合は、デフォルトではホスト名に続いてファイル名として -bin が使用され、デフォルトでは datadir ディレクトリに保存されます。ここでbinary_logを指定して、指定されたデータベースに対してのみバイナリファイルを生成する場合は、次のステートメントを追加する必要があります。

Binlog-do-db=db_name (データベース名)

指定されたデータベースのバイナリファイルログを生成しない場合は、次のステートメントを追加する必要があります。

Binlog-ignore-db-db_name (データベース名)

③mysqlサービスを再起動します。 MySQL インストール ディレクトリ/データ フォルダに、「binary_log.デジタル番号」ファイル (binary_log.00001 など) が表示されます。MySQL サービスが再起動されるたびに、バイナリ ファイルが再生成され、ファイル名の数字が増加します。

起動が成功したら、MySQL設定ファイルmy.cnfを変更し、server-idを設定します。コードは次のとおりです。

サーバーID=1
バイナリログ-do-db=xscj
バイナリログを無視するdb = mysql
Server-id=1: 各データベース サーバーには一意の server-id を割り当てる必要があります。通常、マスター サーバーの場合は 1 です。マスター サーバーとスレーブ サーバーの server-id を同じにすることはできません。
Binlog-do-db: は、コピーする必要があるデータベースを示します。ここでは、xscj が例として使用されています。Binlog-ignore-db: は、コピーする必要のないデータベースを示します。

マスター上のレプリケーションに必要なユーザーを作成します

mysql> *.* のレプリケーションスレーブを rep_user@'%' に付与します。
クエリは正常、影響を受けた行は 0 行 (0.00 秒)
mysql> 権限をフラッシュします。
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

mysql> マスターステータスを表示\G
************************** 1. 行 ****************************
      ファイル: binary_log.000001
    位置: 303
  バイナリログ_Do_DB: 
バイナリログを無視: 
セット内の行数 (0.00 秒)

マスターホストのデータをバックアップし、/data/binary_dump.txt ファイルに保存してから、スレーブマシンにインポートします。具体的な実行文は次のとおりです。

[root@localhost bin]# mysqldump -h localhost>/data/binary_dump.txt

（２）スレーブサーバの動作を制御する

スレーブ サーバーのデータベース構成ファイルを変更し、次のように構成します。

Server-id=2 ##スレーブサーバIDを設定する
マスターホスト=192.168.11.129
マスターユーザー=担当者ユーザー
Master-password= ## マスター サーバーに接続するためのパスワードを設定します。 Replicate-do-db ## 同期するデータベースを設定します。複数設定できます。 Master-port=<port> ## ポート番号を設定します。 スレーブを再起動し、スレーブ ホストの mysql で次のコマンドを再実行して、スレーブ サービスをシャットダウンします。 Mysql>stop slave;
スレーブにレプリケーション関連情報を実装するよう設定し、以下のコマンドを実行します。Mysql>change master to
>マスターホスト=''
>マスターユーザー=''、
>マスターパスワード=''
>master_log_file='binary_log.000007',
>マスターログ位置=120;

入力: show slave status\G は、スレーブ サーバー スレッドに関する主要なパラメーター情報を提供するために使用されます。

よく使われるコマンドは以下のとおりです

以上がMysqlのレプリケーションの詳細な分析に関するこの記事の内容です。皆様のお役に立てれば幸いです。 MySQL の instr を使用したファジー クエリ メソッドの紹介、MySQL クエリ ステートメントのユーザー変数のコード分析、MySQL 操作における JSON データ型操作の詳細な説明など、ぜひご参照ください。不足している点がありましたら、メッセージを残してご指摘ください。問題があれば解決できます。物事は静止しているわけではありません。