MySQL マスター/スレーブレプリケーション: 高いデータ可用性とロードバランシングの実現

1. 引用

MySQL のマスター/スレーブレプリケーションは、高いデータ可用性と負荷分散を実現できる一般的に使用されるデータベースレプリケーションテクノロジです。マスター/スレーブレプリケーションを通じて、MySQL マスターサーバーから 1 つ以上のスレーブサーバーにデータをコピーできるため、データの冗長バックアップと読み取りと書き込みの分離が実現します。この記事では、MySQL マスター/スレーブレプリケーションの原則、構成手順、および一般的な問題の解決策を紹介します。

2. マスタースレーブレプリケーションの原理

マスターサーバー (マスター) は、すべての書き込み操作を受信して処理し、書き込み操作をバイナリログ (バイナリログ) に記録する責任があります。
スレーブサーバー (Slave) はマスターサーバーに接続し、マスターサーバーのバイナリログを読み取ることでマスターサーバー上のデータ変更操作をコピーします。
スレーブサーバーは、受信したデータ変更操作を自身のデータベースに適用して、マスターサーバーとのデータの一貫性を維持します。

3. マスタースレーブレプリケーションの基本手順

従来のマスター/スレーブレプリケーションの基本プロセスは次のとおりです。
1) Mysql スレーブ側の IO プロセスはマスターに接続し、マスターに指定された場所を要求します。指定されたログファイル (または最初のログ);
2) マスターがスレーブの IO プロセスからリクエストを受信した後、レプリケーションを担当する IO プロセスは、スレーブのログファイルに基づいて、対応するログの内容を読み取ります。情報を要求し、それをスレーブの IO プロセスに返します。そして、このリクエストで読み取ったbin-logファイル名と場所をスレーブ側に返します。
3) スレーブの IO プロセスは情報を受信すると、受信したログの内容をスレーブ側のリレーログファイルの末尾に追加し、スレーブ側の bin ログファイルを読み取ります。マスター側: ログのファイル名と場所はマスター情報ファイルに記録されるため、次回ログを読み取るときにマスターに「次のログの内容を特定の bin-log から開始する必要がある」と明確に伝えることができます。場所、送信してください。" ;
4) スレーブの SQL プロセスがリレーログに新しく追加されたコンテンツを検出すると、リレーログのコンテンツがすぐに解析され、実行可能なコンテンツになります。実際にマスター側で実行されるときは、自分自身で実行されます。

簡単に言うと:
メイン: I/O プロセス

スレーブ: I/O プロセススレーブサーバーは、I/O プロセスを通じてマスターサーバーの I/O プロセスと通信し、マスターサーバーの BINLOG ログを同期し、SQL プロセスを通じてデータをスレーブデータベースに書き込みます。 BINLOG ログの内容。

4. 実験プロセス

1. 環境を準備する

2 つのクリーンな仮想マシン (CentOS 7) を準備します。クローン作成は推奨されず、同じネットワークセグメント上にある必要があります。各仮想マシンには、MySQL 5.7 バージョンのデータベースをインストールする必要があります。

実験する前にファイアウォールと SELinnx をオフにしてください

systemctl stop firewalld       #关闭防火墙
setenforce  0                  #关闭selinux

2 台のマシンの名前をそれぞれマスターとスレーブに変更します。

hostnamectl set-hostname master
hostnamectl set-hostname slave

2 台のマシンでマッピング処理を実行し、IP 解決を実行して 2 台のマシン間の接続を容易にしますが、この手順は必須ではなく、必須ではありません。

vim到/etc/hostd文件下，再尾行添加上
master的ip地址       master
slave的ip地址        slave
#两台机器都要分别添加上

これが完了すると、環境の準備が整い、それを構成できるようになります。

2. マスター構成

設定ファイルを変更する

在/etc/my.conf目录下添加
log-bin=/var/lib/mysql/master
server-id=1
gtid_mode=ON
enforce_gtid_consistency=1

追加が完了したら、mysql サービスを再起動する必要があります

systemctl restart mysqld

mysql データベースが再起動されたら、ログインして mysql にユーザーを作成し、それを承認する必要があります。

grant replication slave,super,reload on *.* to slave@'%' identified by '创建用户的密码';

上記の操作を完了すると、マスターの構成が完了し、次にスレーブを構成できます。

3. スレーブの設定

設定ファイルを変更する

在/etc/my.conf目录下添加
log-bin=/var/lib/mysql/master
server-id=2
gtid_mode=ON
enforce_gtid_consistency=1

構成が完了したら、mysql データベースを再起動する必要もあります。

systemctl restart mysqld

マスターの設定と同様に、mysql にログインする必要がありますが、ユーザーを作成する代わりに、マスターの mysql ユーザーに接続します。

change master to master_host='slave',master_user='slave',master_password='密码',master_auto_position=1;

スレーブをオンにする

start slave

オンにした後、show コマンドを使用して、成功したかどうかを確認できます。

show slave status \G

以下に「はい」と表示されたら、成功を意味します。

マスターホストに書き込み、スレーブホストと同期できるようになり、読み取りと書き込みの分離とバックアップが実現します。

5. マスタースレーブ複製実験の問題点

マスタースレーブレプリケーションの実験中にはさまざまな問題が発生する可能性がありますが、よくある問題について以下に説明します。

1. 新しいバージョンの mysql では gtid の実行方法に誤りがあります。

まずマスター上の現在の gtid 番号を確認します。

mysql> show master status\G
....
Executed_Gtid_Set: 130fc529-a688-11ec-9793-000c2922001e:1-2,f5d2ff8f-a688-11ec-981d-000c29a7f0ed:1-2
....

スレーブで動作する

# mysql -u root -p'密码'
mysql> set @@global.GTID_PURGED='130fc529-a688-11ec-9793-000c2922001e:1-2,f5d2ff8f-a688-11ec-981d-000c29a7f0ed:1-2';

如果master上拿到的是一个gtid，那么按照上面的语法，重复两次就可以，比如：
mysql> set @@global.GTID_PURGED='f24c3ee0-7a88-11ed-a20e-000c29988ddf:1-3,f24c3ee0-7a88-11ed-a20e-000c29988ddf:1-3';

2. MySQL サーバーの UUID 重複の問題。クローン作成では UUID を記録するファイルの内容が変更されないため

解决：
1.全新机器 
或者
2.直接修改文件/var/lib/mysql/auto.cnf 内的uuid 
使用命令 # uuidgen  生成全新uuid直接替换文件内的旧uuid即可

6. 結論

MySQL のマスター/スレーブレプリケーションは、データの高可用性、冗長バックアップ、負荷分散を提供できる強力なデータベースレプリケーションテクノロジです。マスター/スレーブレプリケーションを正しく構成および管理することで、データの一貫性と信頼性を確保し、システムのパフォーマンスと可用性を向上させることができます。この記事が MySQL マスター/スレーブレプリケーションの理解と実装に役立ち、プロジェクトで役割を果たすことができれば幸いです。

MySQL のマスター/スレーブレプリケーションについて他に質問がある場合、またはより詳細な調査が必要な場合は、引き続き MySQL の公式ドキュメントと関連リソースを調べて、より詳しいガイダンスと実践的な経験を得ることが推奨されます。 MySQL マスター/スレーブレプリケーションの使用が成功することを祈っています。