MySQL マスタースレーブレプリケーションの詳細な分析

序文：

MySQL では、マスター/スレーブ アーキテクチャが最も基本的かつ最も一般的に使用されるアーキテクチャになります。その後の読み取り/書き込み分離、マルチアクティブ高可用性アーキテクチャなどは、主にマスター/スレーブ レプリケーションに依存します。マスタースレーブ レプリケーションも、MySQL 学習プロセスに欠かせない要素です。マスタースレーブ レプリケーションに関する記事は数多くあります。私もこの面について楽しく書いて、自分の経験と方法を共有したいと思います。

1. マスタースレーブレプリケーションの概要と原理

マスタースレーブ レプリケーション (AB レプリケーションとも呼ばれます) とは、1 つのサーバーがマスター データベース サーバーとして機能し、別のサーバーまたは複数のサーバーがスレーブ データベース サーバーとして機能することを意味します。マスター サーバーのデータは、スレーブ サーバーに自動的にコピーされます。マルチレベルレプリケーションでは、データベース サーバーはマスターとスレーブの両方として機能できます。 MySQL はデフォルトで非同期レプリケーションを使用します。

マスタースレーブレプリケーションのプロセスと原理は、次のように要約できます。

1. マスター サーバーは、データの変更をバイナリ ログに記録します。マスター上のデータが変更されると、その変更がバイナリ ログに書き込まれます。
2. スレーブ サーバーは、一定の時間間隔でマスター バイナリ ログが変更されたかどうかを検出します。変更された場合は、I/O スレッドを開始してマスター バイナリ イベントを要求します。
3. 同時に、マスター ノードは各 I/O スレッドのダンプ スレッドを開始し、バイナリ イベントを送信してスレーブ ノードのローカル リレー ログに保存します。スレーブ ノードは SQL スレッドを開始し、リレー ログからバイナリ ログを読み取り、ローカルで再生して、マスター ノードのデータと一致するようにします。

2. バイナリファイルの場所に基づいてマスタースレーブレプリケーションを構成する

バイナリ ファイルの位置に基づくマスター スレーブ レプリケーションは、従来のレプリケーションとも呼ばれます。つまり、スレーブ サーバーはマスター サーバーの binlog ファイルの位置に依存します。マスター データベースのデータが変更されると、binlog の位置が増加し、スレーブ データベースは変更を感知して同期を完了します。

マスタースレーブレプリケーションを構成するには、まずマスターサーバーとして 1 つ、スレーブサーバーとして 1 つ、合計 2 つの MySQL インスタンスを準備する必要があります。マスター スレーブ レプリケーションは binlog に依存するため、マスター データベースで binlog が有効になっている必要があり、マスターとスレーブは異なる server_ids で構成されている必要があります。次に、構成プロセスの詳細な説明を示します。

2.1 マスタースレーブライブラリ構成パラメータを確認する

MySQL マスタースレーブサーバーには以下の構成が推奨されています。まずはこれを確認してください。設定されていない場合は、構成ファイルを変更して再起動する必要があります。

# メインライブラリパラメータ設定には次のパラメータが必要です vim /etc/my.cnf 
[mysqld] 
log-bin = binlog //バイナリログを有効にする server-id = 137 //サーバーの一意のID。デフォルト値は1で、通常はIPアドレスの最後の桁に設定されます binlog_format = row //レプリケーションエラーを防ぐために、バイナリログは行モードに設定されます # スレーブには次のパラメータが推奨されます vim /etc/my.cnf 
[mysqld] 
リレーログ = リレービン
サーバーID = 138

2.2 メインライブラリのバイナリの場所を決定し、同期アカウントを作成する

マスター データベースとスレーブ データベースが初期化されたばかりで、マスター データベースに操作がない場合、スレーブ データベースはマスター データベースのデータを同期する必要がなく、マスター データベースの binlog 位置を直接特定できます。

# メインライブラリの binlog ファイルの場所を表示します。show master status;

# メイン データベースに同期アカウントを作成します。create user 'repl'@'%' identified by '123456';
*.* のレプリケーションスレーブを 'repl'@'%' に付与します。

マスター データベースがしばらく実行されていてビジネス データがあり、スレーブ データベースが初期化されたばかりの場合は、マスター データベースのデータをバックアップしてからスレーブ データベースにインポートし、マスター データとスレーブ データの整合性を確保する必要があります。

# メイン データベースに同期アカウントを作成します。create user 'repl'@'%' identified by '123456';
*.* のレプリケーションスレーブを 'repl'@'%' に付与します。

# mysqldump -uroot -pxxxx -A -R -E --single-transaction --master-data=2 > all_db.sql

# データベースからmysqlを復元 -uroot -pxxxx < all_db.sql

# メインライブラリのbinlogの場所はバックアップファイルから確認できます

2.3 スレーブデータベースに入り、マスタースレーブレプリケーションを有効にする

マスター ライブラリ バイナリ ファイルの場所を見つけ、マスター スレーブ データの整合性を完了したら、マスター スレーブ レプリケーションを正式に開始できます。

# スレーブライブラリからMySQLコマンドラインを入力し、マスターライブラリに接続するためにマスター変更ステートメントを実行します # バイナリファイル名と位置は上記の手順から取得されます CHANGE MASTER TO MASTER_HOST='MySQLマスターサーバーのIPアドレス'、
 マスターポート=3306、
 MASTER_USER='repl',
 マスターパスワード = '123456'、
 MASTER_LOG_FILE='binlog.000002',
 マスターログPOS = 154;
 
# マスタースレーブレプリケーションを開始し、ステータスを維持します start slave;
スレーブステータスを表示 \G //スレーブステータスをチェックして、Slave_IO_Running: Yes、Slave_SQL_Running: Yes であることを確認します。

3. GTIDに基づくマスタースレーブレプリケーション

GTID は MySQL 5.6 の新機能です。正式名称は Global Transaction Identifier で、MySQL のマスターとスレーブの切り替えとフェイルオーバーを簡素化できます。 GTID は、binlog 内のトランザクションを一意に識別するために使用されます。トランザクションがコミットされると、MySQL サーバーはまず、次のトランザクションの GTID を指定する GTID_Event タイプの特別な Binlog イベントを書き込み、次にトランザクションの Binlog を書き込みます。

GTID ベースのレプリケーションでは、スレーブ サーバーは最初にマスター サーバーにスレーブ サーバーで実行されたトランザクションの GTID 値を伝えます。次に、マスター データベースはスレーブ データベースで実行されていないすべてのトランザクションをスレーブ データベースに送信して実行します。GTID を使用したレプリケーションでは、指定されたスレーブ データベースで同じトランザクションが 1 回だけ実行されるようにできるため、オフセットの問題によるデータの不整合を回避できます。つまり、カスケード状況でも、1 つのマスターと複数のスレーブの状況でも、以前のように File_name と File_position を通じてメイン ライブラリの binlog の位置を見つける必要がなく、GTID を通じて位置を自動的に見つけることができます。

GTID に基づくマスター スレーブ レプリケーションは、上記のバイナリ ファイルの場所に基づくマスター スレーブ レプリケーションに似ています。以下は、セットアップ プロセスの簡単なデモンストレーションです。

3.1 マスタースレーブライブラリ構成を確認し、GTIDを有効にする

# メインライブラリパラメータ設定には次のパラメータが必要です vim /etc/my.cnf 
[mysqld] 
サーバーID = 137
ログビン = binlog 
binlog_format = 行 
gtid-mode = ON //gtid モードをオンにするenforce-gtid-consistency = ON //gitd 起動後のトランザクションのセキュリティを確保するために gtid の一貫性を強制する # ライブラリ vim /etc/my.cnf から次のパラメータを設定することをお勧めします 
[mysqld] 
サーバーID = 138
ログビン = binlog 
binlog_format = 行 
gtidモード = オン 
強制GTID一貫性 = ON 
リレーログ = リレービン

3.2 マスターとスレーブのデータベースデータの一貫性を保つために同期アカウントを作成する

マスター データベースが初期化されたばかりの場合、またはすべてのバイナリ ファイルがマスター データベースに保持されている場合は、データをスレーブ データベースと手動で同期する必要はありません。それ以外の場合は、マスターとスレーブの一貫性を保つためにデータを手動で同期する必要があります。

# メイン データベースに同期アカウントを作成します。create user 'repl'@'%' identified by '123456';
*.* のレプリケーションスレーブを 'repl'@'%' に付与します。

# マスターデータベースが初期化されたばかりの場合、または完全なバイナリファイルがある場合は、次の手順を実行する必要はありません。# マスターデータベースデータの完全バックアップ mysqldump -uroot -pxxxx -A -R -E --single-transaction > all_db.sql
# データベースからmysqlを復元 -uroot -pxxxx < all_db.sql

3.3 スレーブデータベースに入り、マスタースレーブレプリケーションを有効にする

# スレーブライブラリからMySQLコマンドラインを入力し、マスターライブラリに接続するためにマスター変更ステートメントを実行します。CHANGE MASTER TO MASTER_HOST='MySQLマスターサーバーのIPアドレス'、
 マスターポート=3306、
 MASTER_USER='repl',
 マスターパスワード = '123456'、
 マスター自動位置 = 1;
 
# マスタースレーブレプリケーションを開始し、ステータスを維持します start slave;
スレーブステータスを表示 \G

4. 経験と提案

日々の勉強と仕事の過程で、マスタースレーブレプリケーションの経験も蓄積してきました。ここでいくつかの簡単なポイントを共有します。落とし穴を避けられることを願っています。

• マスター側とスレーブ側の両方のデータベース バージョンは、可能な限り一貫性を保つ必要があります。
• 文字セットや sql_mode など、マスター データベースとスレーブ データベースのパラメータは同じにすることをお勧めします。
• サーバー パフォーマンスによるマスター スレーブ間の遅延を回避するために、スレーブ サーバーのパフォーマンスはマスター サーバーに比べて大幅に遅れることはできません。
• 主キーのないテーブルをスレーブ データベースに同期すると、マスター スレーブ間の遅延が発生する可能性が非常に高いため、すべてのテーブルに主キーが必要です。
• スレーブ データベース データの操作における人為的エラーを防ぐために、スレーブ データベースを読み取り専用に設定することをお勧めします。
• マスターとスレーブ間の遅延とステータスを監視し、同期の中断や遅延をタイムリーに解決します。
  

要約:

この記事では、マスタースレーブレプリケーションの原理と構築プロセスを紹介します。実際には、マスタースレーブレプリケーションについてはまだ多くのコンテンツがあり、継続的な学習が必要です。ここでは、GTID モードを使用してマスタースレーブ レプリケーションを構築することを推奨します。この後で共有する経験も、私の日々の蓄積です。皆さんの参考になれば幸いです。書くのは簡単ではありません。良いと思ったらシェアしてください。

上記はMySQLマスタースレーブレプリケーションの詳細な分析です。MySQLマスタースレーブレプリケーションの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。