Mysql マスター/スレーブ アーキテクチャの構築とメンテナンスの詳細

導入

  この記事は、MySQL のマスター/スレーブ レプリケーション構成に関する記事です。データベース操作の効率とセキュリティを向上させる強力なツールである MySQL マスター/スレーブ構成を構築する方法を深く理解できます。この記事では、基本的な環境の準備から、マスター/スレーブ サーバーの構成、マスター/スレーブ レプリケーションの最適化と拡張までを完全に説明します。

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

1.1 MySQL マスター/スレーブ レプリケーションとは

  MySQL マスター/スレーブ レプリケーションは、1 つの MySQL データベース (マスター データベース) から 1 つ以上の MySQL データベース (スレーブ データベース) にデータをレプリケートするための非同期レプリケーション テクノロジです。このメカニズムにより、スレーブ データベースはマスター データベースと同じデータ状態になります。主なワークフローは、プライマリ データベースがデータ変更イベントをバイナリ ログ (binlog) に書き込み、その後データベースからそれらのログ内のイベントを読み取って実行することで、プライマリ データベースとの同期を維持します。

1.2 マスタースレーブ構成のメリットと使い方

MySQL マスター/スレーブ レプリケーション構成の利点と用途は非常に多様です。

1. データ バックアップ: マスター/スレーブ レプリケーションを通じて、データが 1 つ以上のスレーブ データベースにコピーされ、データ損失を防ぐ災害復旧ソリューションが提供されます。
2. 読み取りパフォーマンスの向上: 読み取り負荷の高いアプリケーションの場合、データベースから読み取ることで読み取り負荷を分散できるため、システム パフォーマンスが向上します。
3. データ分散: データを地理的に分散した複数のデータベースに複製して、ユーザーに高速なローカル アクセス サービスを提供できます。
4. リアルタイムの分析とレポート作成: スレーブ データベースは、マスター データベースのパフォーマンスに影響を与えることなく、複雑なクエリやレポートの生成に使用できます。

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

  MySQL のマスター/スレーブ レプリケーションは、マスター データベースのバイナリ ログ(binlog) に基づいています。プライマリ データベースは、すべてのデータ変更イベントをバイナリ ログに記録します。データベースからのレプリケーションには、IO スレッドと SQL スレッドという 2 つのスレッドが使用されます。これらのスレッドはバイナリ ログ内のイベントを読み取って実行し、スレーブがマスターと同じデータ状態になるようにします。

2.1 ワークフロー

マスター/スレーブ レプリケーションのワークフローには、主に次の手順が含まれます。

1. プライマリ データベースは、INSERT、UPDATE、DELETE などのデータ変更操作を実行します。
2. プライマリ データベースは、これらの変更をバイナリ ログに記録します。
3. スレーブ データベースの IO スレッドはマスター データベースに接続し、バイナリ ログ内の新しいイベントを読み取ります。
4. スレーブ データベースの IO スレッドは、これらのイベントをスレーブ データベースのリレー ログに書き込みます。
5. スレーブ データベースの SQL スレッドはリレー ログを読み取り、その中のイベントを実行してデータをメイン データベースと同期します。

2.2 データの同期方法

  MySQL のマスター/スレーブ レプリケーションでは、データ同期に非同期メソッドが使用されます。つまり、マスター データベースはバイナリ ログにイベントを記録した後、スレーブ データベースがイベントを実行するのを待たずに、すぐに戻ります。データベースから新しいイベントを取得して実行するのは、独自の責任です。このアプローチにより、ほとんどの場合パフォーマンスが向上しますが、ネットワークの停止やスレーブ データベースの障害が発生した場合には、データの遅延やデータの損失が発生する可能性があります。
  半同期レプリケーション方法もあります。この方法では、マスター データベースは、変更を実行した後に戻る前に、少なくとも 1 つのスレーブが変更イベントを受信するのを待ちます。このアプローチによりデータの信頼性は向上しますが、プライマリ データベースのパフォーマンスに影響を与える可能性があります。

3. 環境の準備

  MySQL マスター/スレーブ レプリケーションを構成する前に、対応する環境を準備する必要があります。これには、ハードウェアとソフトウェアの要件を満たすこと、適切な MySQL バージョンを選択すること、MySQL サーバーを正しくインストールすることが含まれます。

3.1 ハードウェアおよびソフトウェアの要件

• ハードウェア要件: まず、少なくとも 2 台のコンピューターが必要です (テスト中にデモンストレーション用に 2 台の仮想マシンを作成できます)。1 台はマスター サーバーとして、もう 1 台以上はスレーブ サーバーとして使用されます。これらのコンピュータには、MySQL サーバーとデータ ストレージの動作をサポートするために、十分なプロセッサ速度、メモリ サイズ、およびハードディスク容量が必要です。

• ソフトウェア要件: Linux、Windows、macOS などのオペレーティング システムが各コンピューターにインストールされている必要があります。オペレーティング システムをインストールし、最新の安定したバージョンに更新する必要があります。さらに、mysql に付属するクライアントや Navicat を使用するなど、いくつかの基本的なソフトウェア ツールが必要です。

3.2 MySQL バージョンの選択

  適切な MySQL バージョンを選択することも重要です。MySQL のバージョンが異なれば、サポートされる機能も異なり、パフォーマンス特性や問題も異なります。一般に、最新の安定リリースには最新の機能と最新のセキュリティ修正が含まれているため、最新の安定リリースを使用することをお勧めします。ただし、場合によっては、特定のニーズや互換性のために、特定のバージョンの MySQL を使用する必要がある場合があります。この記事では最新バージョン ( mysql8.0.33 ) を使用してビルドします。

3.3 MySQL サービスのインストール

mysql サービスを使用して 2 つのサーバーをインストールします。mysql サービスのインストールについては、このチュートリアルを参照してください: https://blog.csdn.net/dougsu/article/details/130816827

4. MySQL マスターサーバーを構成する

ハードウェアとソフトウェアの環境を準備した後、MySQL マスター サーバーを構成する必要があります。これには、構成ファイルの変更、レプリケーション アカウントの作成、マスター サーバーの起動とテストが含まれます。(以下では、Navicat ツールを使用して、クエリと操作のクライアントとして機能します)

4.1 設定ファイルの変更

まず、MySQL 構成ファイル my.cnf (Windows では my.ini) を変更する必要があります。**[mysqld]** セクションで、次の構成項目を追加または変更する必要があります。

server-id=1
#开启binlog
log_bin=master-bin
log_bin-index=master-bin.index
binlog-format=MIXED

• server-id : 各 MySQL サーバーに一意の整数 ID を設定します。
• log-bin : バイナリログを有効にし、ログファイルの名前を指定します。
• log_bin-index : バイナリログファイルのインデックスファイルの名前
• binlog-format : バイナリ ログの形式を指定します。STATEMENT、ROW、または MIXED のいずれかになります。

バイナリログのフォーマットを補足しました

1. ステートメント: MySQL は、実行された各 SQL ステートメントをバイナリ ログに記録します。バイナリ ログには、実行された SQL ステートメントのみが含まれ、特定の行レベルの変更は記録されません。ほとんどの場合に適していますが、場合によっては、一貫性の問題が発生する可能性があります。マスター/スレーブ同期
2. ROW: MySQL は、変更された各行の変更情報をバイナリ ログに記録します。バイナリ ログには、SQL ステートメントだけでなく、実際の行レベルの変更情報が含まれます。これにより、マスターとスレーブの同期の正確な一貫性が保証されますが、より大きなバイナリ ログ ファイルが生成されます
3. 混合: MySQL は、特定の状況に応じて SQL ステートメントまたは行レベルの変更情報を記録することを自動的に選択できます。ほとんどの場合、MySQL は SQL ステートメントを記録するために STATEMENT 形式を使用しますが、SQL ステートメントを正確に再生できない状況では、MySQL はuse ROW 行レベルの変更情報を記録する形式なので、STATEMENT と ROW の長所を併せ持ち、状況に応じて最適な記録方法を選択できます。

4.2 コピーアカウントの作成

実際の運用環境では、root ユーザーを直接使用することはお勧めできませんが、マスターとスレーブの同期を担当する完全な権限を持つユーザーを作成します。次の SQL コマンドを使用してレプリケーション アカウントreUserを作成します。パスワードはabc123です。

CREATE USER 'reUser'@'%' IDENTIFIED BY 'abc123';
GRANT REPLICATION SLAVE ON *.* TO 'reUser'@'%';
flush privileges;

ユーザーを作成した後、次のコマンドを使用して構成された権限をクエリできます。クエリには権限が含まれている必要があります: REPLICATION SLAVE

SHOW GRANTS FOR 'reUser'@'%';

注: ユーザーを作成せずに、構築テストで root アカウントを直接使用することもできます。

4.3 マスターサーバーの起動とテスト

1. 構成を変更した後、mysql サービスを再起動します。
2. クライアントが実行するとSHOW VARIABLES LIKE 'server_id';、設定が正常であれば表示されます。
   
3. クライアントが実行するとshow master status;、設定が正常であれば表示されます。
   

フィールドの説明:

• File : 現在書き込まれているバイナリ ログ ファイルの名前を示します。
• Position : 現在書き込まれているバイナリログファイル内の位置 (バイトオフセット) を示します。
• Binlog_Do_DB : マスターサーバーのバイナリログを有効にし、指定されたデータベース操作のみを記録するデータベースのリストを示します。
• Binlog_Ignore_DB : マスターサーバーでバイナリログが有効になっており、指定されたデータベース操作がログに記録されない場合に無視するデータベースのリストを示します。
• Executed_Gtid_Set : マスターサーバー上で実行されたGTID(グローバルトランザクション識別子)セットを示します。GTID は、分散トランザクションを追跡するために使用される識別子です。

注: 構成と使用状況によっては、Binlog_Do_DB、Binlog_Ignore_DB、および Executed_Gtid_Set フィールドが空になる場合があります。

5. MySQL スレーブサーバーを構成する

MySQL スレーブ サーバーを構成するプロセスは、構成ファイルの変更やテスト サーバーの起動など、マスター サーバーの構成と似ています。

5.1 設定ファイルの変更

MySQL 構成ファイル my.cnf (Windows では my.ini) を変更する必要があります。**[mysqld]** セクションで、次の構成項目を追加または変更する必要があります。

server-id=2
#打开MySQL中继日志
relay-log=slave-relay-bin
relay-log-index=slave-relay-bin.index
#打开从服务二进制日志
log-bin=mysql-bin
#使得更新的数据写进二进制日志中
log-slave-updates=1

• server-id : 各 MySQL サーバーに一意の整数 ID を設定します。
• リレーログ: サーバー (スレーブ) からのリレーログを保存するために使用されるファイル名のプレフィックスを指定します。
• リレーログインデックス: サーバー (スレーブ) からのリレーログインデックスを保存するために使用されるファイル名を指定します。
• log-bin : バイナリログを有効にし、ログファイルの名前を指定します。
• binlog-format : スレーブ サーバーがレプリケーション イベントを自身のバイナリ ログに書き込むかどうかを指定します。1 に設定すると、スレーブ サーバーはマスター サーバーから受信したバイナリ ログ イベントを自身のバイナリ ログに書き込みます。セカンダリ ログとバイナリ ログの両方に記録されます。このオプションは通常、マスター サーバーとスレーブ サーバー間のチェーン レプリケーションに基づく構成でカスケード レプリケーションとマルチレベル レプリケーションを実装するために使用されます。

5.2 スレーブサーバーの起動とテスト

1. 構成を変更した後、mysql サービスを再起動します。
2. クライアントが を実行しますSHOW VARIABLES LIKE 'server_id';。設定が正常であれば、2 が表示されます。

6. マスター/スレーブ接続を確立する

6.1 サーバーからマスターサーバーへの接続

  マスターとスレーブを構成した後、マスターを指すスレーブ上で接続を作成し、レプリケーション プロセスを開始する必要があります。これには、MySQLCHANGE MASTER TOコマンドを使用し、マスターサーバーのアドレス、レプリケーションアカウントのユーザー名とパスワード、バイナリログファイルと場所を指定する必要があるため、私の構成は次のようになります

CHANGE MASTER TO
MASTER_HOST='192.168.3.51',
MASTER_PORT=3306,
MASTER_USER='root',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='master-bin.000001',
MASTER_LOG_POS=157,
GET_MASTER_PUBLIC_KEY=1;

• master_host: マスターサーバーのアドレスです。
• replication_user と replication_password: は、プライマリ サーバーで作成されたレプリケーション アカウントのユーザー名とパスワードです。
• master_log_file および master_log_pos: マスター サーバーのバイナリ ログの名前と場所であり、マスター サーバー上でコマンドを実行することで取得できますSHOW MASTER STATUS(上記のセクション 4.3 を参照)。

実行結果は以下の通りです。

6.2 レプリケーションプロセスの開始

  上記の手順を完了しても、レプリケーション プロセスはまだ開始されていません。レプリケーション プロセスを開始するには、スレーブ サーバーで次のコマンドを実行する必要があります。

START SLAVE;

レプリケーションが開始されると、スレーブ サーバーはマスター サーバーのバイナリ ログの読み取りを開始し、これらのログ内のイベントをローカルで実行し、それによってデータをマスター サーバーと同期させます。
SHOW SLAVE STATUS コマンドを使用してレプリケーションのステータスを表示できます。

1. レプリケーション プロセスが実行中の場合、Slave_IO_Running ステータスとSlave_SQL_Runningステータスの両方が「YES」と表示されるはずです。
2. 同期が完了している場合、または同期が必要ない場合、Master_Log_FileおよびRead_Master_Log_Posの結果は、第 4.3 章でクエリされた結果と同じになります。

クエリ レプリケーション情報には、組み込みクライアントを介してアクセスすることもできshow slave status \G;、その結果は次のようになります。

注: mysql がインストールされている仮想マシンのクローンを作成している場合は、 mysql のルート ディレクトリにある data/auto.cnf ファイル内のserver-uuidの値を変更する必要があります。2 つのサービスの値は異なっていなければなりませんそうでない場合は、次のエラーが報告されます。

致命的エラー: ソースとレプリカの MySQL サーバー UUID が等しいため、レプリカ I/O スレッドが停止します。レプリケーションが機能するには、これらの UUID が異なっている必要があります。

7. マスター/スレーブ レプリケーションが機能することを確認する

  MySQL のマスター/スレーブ レプリケーションを構成し、レプリケーション プロセスを開始した後、レプリケーションが適切に機能していることを確認する必要があります。マスター/スレーブ レプリケーションを検証する一般的な方法は、マスターにデータを挿入し、それが受信されたことをスレーブで確認することです。

7.1 検証のためにメインサーバーにデータを挿入する

マスターサーバー上で新しいデータベースを作成し、データを挿入できます。例えば：

CREATE DATABASE mydb;
USE mydb;
CREATE TABLE user (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50));
INSERT INTO user(name) VALUES ('tom'), ('jerry'), ('dave');

1. マスタースレーブクエリ

SELECT * FROM `user`

2. ライブラリからのクエリ

SELECT * FROM `user`

データが同期されていることがわかり、スレーブ ライブラリで最新のステータス情報が照会されます。同期オフセットRead_Master_Log_Pos: 1097が変更されている
ことがわかります。

7.2 エラーチェックと問題解決

  MySQL のマスター/スレーブ レプリケーションの構成と検証のプロセス中に、いくつかの問題が発生する可能性があります。最も一般的な問題は、スレーブがマスターに接続できないこと、またはスレーブがマスターのバイナリ ログを読み取ったり実行できないことです。

  問題が発生した場合、まず MySQL エラー ログをチェックして、関連するエラー メッセージがあるかどうかを確認します。さらに、SHOW SLAVE STATUSコマンドを使用してスレーブのレプリケーション ステータスを表示できます。このコマンドの結果には、マスター サーバーのアドレス、レプリカ アカウントのユーザー名、レプリカのエラー番号とエラー メッセージなど、多くの有用な情報が含まれています。

  エラー メッセージに基づいて問題の原因を特定し、適切な修正措置を講じることができます。一般的な解決策には、ネットワーク接続の確認、アカウントのユーザー名とパスワードが正しいことの確認、マスター サーバーのバイナリ ログが利用可能であることの確認などが含まれます。

  マスター/スレーブ レプリケーションの動作を確認することは、MySQL マスター/スレーブ レプリケーションを構成する際の重要な手順であり、マスター/スレーブ レプリケーションを正常に実行し続けるための鍵でもあります。データの一貫性と可用性は、レプリケーションが適切に機能している場合にのみ確保できます。

8. マスター/スレーブ レプリケーションの保守と最適化

  マスター/スレーブ レプリケーションの動作中に、特定の処理と最適化ソリューションを必要とするいくつかの問題が発生する場合があります。

8.1 ネットワークの問題の処理

  ネットワークの問題は、おそらくマスター/スレーブ レプリケーションで最も一般的な障害です。ネットワーク接続が不安定になると、データの同期に直接影響します。ネットワークの問題に対処するには、ネットワーク接続、ネットワーク デバイスのステータス、ネットワーク ファイアウォール ルール、MySQL サーバーのリスニング ポートの確認など、複数の視点が必要です。複雑なネットワーク環境では、ネットワーク リンクをデバッグして最適化するためにネットワーク管理者の支援が必要になる場合があります。

8.2 レプリケーション遅延の問題

  レプリケーションの遅延、つまりスレーブ データベースがマスター データベースのデータを同期する時間の遅れも、マスター/スレーブ レプリケーションの効果に影響を及ぼすもう 1 つの重要な要素です。処理能力が不十分であるか、ネットワーク帯域幅が不十分であると、レプリケーションの遅延が発生する可能性があります。レプリケーションの遅延への対処は、データベース操作の最適化、スレーブ ライブラリのハードウェア パフォーマンスの強化、およびネットワーク帯域幅の最適化によって実行できます。場合によっては、データ分散機能を使用してスレーブ ライブラリへの負担を軽減するミドルウェアの導入を検討できます。

8.3 マスター/スレーブ切り替え

  マスター/スレーブ切り替えは高可用性ソリューションの重要な部分です。つまり、マスター ライブラリに障害が発生した場合、スレーブ ライブラリはすぐに新しいマスター ライブラリに昇格され、サービスの継続性が確保されます。マスター/スレーブ切り替えのプロセスは、切り替えのトリガー条件、切り替えの具体的な手順、切り替えプロセス中のサービスの処理の決定など、事前に完全に計画し、テストする必要があります。マスター/スレーブ切り替えを実行するときは、切り替えプロセス中のデータ損失を避けるためにデータの一貫性にも注意を払う必要があります。

マスター/スレーブ レプリケーションのメンテナンスと最適化は、データの一貫性と高いサービス可用性を確保するための重要な手段であり、データベース管理者には確かな専門知識と豊富な実践経験が必要です。

9. 高度なテーマと拡張機能

  ビジネスが発展するにつれて、マルチソース レプリケーション、マスター間レプリケーション、自動スイッチング、ロード バランシングなど、より複雑な要件に遭遇する可能性があります。

9.1 マルチソースレプリケーション

  MySQL では、スレーブ サーバーは複数のマスター サーバーからデータを複製できます。これをマルチソース レプリケーションと呼びます。マルチソース レプリケーションにより、データの可用性と読み取りパフォーマンスが向上します。マルチソース レプリケーションを構成するには、各マスターのスレーブ上にレプリケーション チャネルを作成し、各チャネルのマ​​スターの詳細を指定する必要があります。

9.2 マスター間レプリケーション

  マスター間レプリケーションは双方向レプリケーションとも呼ばれ、2 台のサーバーが互いのマスターとスレーブになることを意味します。マスター間レプリケーションにより、データの冗長性と可用性が向上しますが、レプリケーションの競合のリスクも高まります。競合を回避するには、各サーバーが特定のデータのみを書き込むなど、データベースの書き込みモードを慎重に設計する必要があります。

9.3 自動切り替えと負荷分散

  自動切り替えとは、マスター サーバーに障害が発生した場合に、スレーブ サーバーが新しいマスター サーバーに自動的に昇格することを指します。自動切り替えによりサービスの可用性が向上しますが、MHA、MySQL Router などの追加のツールやサービスに依存する必要があります。
  負荷分散とは、読み取りリクエストを複数のスレーブ サーバーに分散して読み取りパフォーマンスを向上させることを指します。負荷分散は、ハードウェア デバイス (ロード バランサーなど)、ソフトウェア ツール (プロキシ サーバーなど)、またはアプリケーションを通じて実装できます。
  高度なトピックと拡張機能を使用するには、オペレーターはより深いデータベース知識と、より実践的な経験を必要とします。これらの高度な機能を使用する場合、最善の決定を下すために、その利点と潜在的なリスクを考慮する必要があります。

10. 結論

  この記事では、MySQL のマスター/スレーブ レプリケーション構成とその構造について詳しく説明し、この重要なデータベース管理戦略の理解と実装に役立つことを願っています。この記事では、MySQL のマスター/スレーブ レプリケーションの基本概念と原則から始まり、環境の準備方法、マスター サーバーとスレーブ サーバーの構成方法、マスター/スレーブ接続の確立方法について詳しく紹介します。マスター/スレーブ レプリケーションをスムーズに進めるために、マスター/スレーブ レプリケーションを検証し、考えられる問題を解決する方法についても説明しました。同時に、この記事では、マスター/スレーブ レプリケーションのメンテナンスと最適化、およびいくつかの高度なトピックについても説明します。この記事を通じて、MySQL のマスター/スレーブ レプリケーションについて深く理解し、データベース管理能力を向上していただければ幸いです。