MySQLのマスタースレーブレプリケーションの入門から使いこなしまで徹底解説【上級編】


ここに画像の説明を挿入

0. 序文

MySQL のマスター/スレーブ レプリケーションと読み書き分離はデータベース分野の基本概念であり、システムの高可用性と高パフォーマンスを確保するための重要なテクノロジです。

  1. 主从复制(Master-Slave Replication)MySQL の重要な機能です。この技術を使用すると、1 つの MySQL データベース サーバー (マスター サーバー) 上のデータを 1 つ以上の MySQL データベース サーバー (スレーブ サーバー) に複製できます。マスター/スレーブ レプリケーションの使用シナリオには、主に読み取り/書き込み分離、フェイルオーバー、バックアップ、データ分析が含まれます。マスター/スレーブ レプリケーションの中心原理は、マスター サーバーがデータの変更をバイナリ ログ (バイナリ ログ) に記録し、スレーブ サーバーがこれらの変更リクエストを独自のリレー ログ (リレー ログ) にコピーし、リプレイ (リプレイ) することです。サーバーからのログのイベントに従って、スレーブのデータはマスターのデータと一致しています。

  2. 読み取りと書き込みの分離とは、異なるデータベース サーバーで実行されるデータ読み取り操作とデータ更新操作を分離することを指します。この手法は通常、マスター/スレーブ レプリケーションと組み合わせて使用​​されます。読み取り操作はスレーブ サーバーで実行され、書き込み操作はマスター サーバーで実行されます。読み取りと書き込みを分離する主な利点は、アプリケーションのパフォーマンスとスケーラビリティを大幅に向上できることです。通常、読み取り操作の方が書き込み操作よりも頻繁に行われ、読み取り操作の負荷をスレーブ サーバーに分散することでマスター サーバーの負荷を大幅に軽減できるためです。 。

MySQL のマスター/スレーブ レプリケーションと読み書き分離を実装するには、MySQL のアーキテクチャと動作原理を深く理解する必要があり、実装プロセス中にデータの整合性の問題、遅延の問題、障害回復の問題など、多くの問題が発生する可能性があります。したがって、実際の運用では慎重な検討と慎重な実装が必要です。

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

マスター/スレーブ レプリケーションは、1 つの MySQL データベース サーバー上のデータを他の MySQL サーバーにリアルタイムでレプリケートするために使用されるデータ バックアップ テクノロジです。その主な機能は、リアルタイムのデータ バックアップを実行することであり、すべてのスレーブ サーバーで負荷分散を実行できます。マスター/スレーブ レプリケーションのプロセスは大まかに次のとおりです。マスター サーバー上のすべてのデータ変更 (挿入、削除、更新など)は、バイナリ ログと呼ばれるバイナリ
ログに記録されますスレーブは を開始し、 に接続し、からイベントを読み取り、それらのイベントをスレーブの に書き込みますスレーブ サーバーは SQL スレッドも開始し、リレー ログ内のイベントを読み取り、これらのイベントを実行してマスター サーバーとのデータ同期を実現します。(Binary Log)二进制事件I/O线程主服务器主服务器二进制日志中继日志(Relay Log)

2. マスタ・スレーブレプリケーションのワークフロー

ここに画像の説明を挿入

  1. マスター サーバー上のデータ変更: マスター サーバー上でデータ変更が行われた後、これらの変更はバイナリ ログに記録され、このプロセスは Binlog スレッドによって完了します。

  2. サーバーの I/O スレッドから: スレーブ サーバーの I/O スレッドはマスター サーバーに接続し、バイナリ ログからすべての非同期データを読み取り、そのデータを独自のリレー ログに保存します。

  3. サーバーの SQL スレッドから: 次に、サーバー上の SQL スレッドからリレー ログを読み取り、その中の SQL ステートメントを再生して、リレー ログ内のデータをスレーブ サーバーのデータベースに更新します。
    ここに画像の説明を挿入

マスター/スレーブ レプリケーション プロセスにおけるログ ファイルの役割(Binary Log)中继日志(Relay Log)

  1. バイナリログ(Binary Log)は、マスターサーバー上のログファイルです记录了所有改变了数据库数据的SQL语句(如INSERT、UPDATE、DELETE等)トランザクションがプライマリ サーバーで実行されるたびに、レコードがバイナリ ログに追加されます。バイナリ ログは、マスター/スレーブ レプリケーションとデータ リカバリの両方に使用できます。

  2. リレーログ(Relay Log)は、スレーブサーバー上のログファイルです其内容来自主服务器的二进制日志。从服务器上的I/O线程负责从主服务器读取二进制日志中的事件,并将这些事件写入到中继日志中次に、スレーブ サーバー上の SQL スレッドは、リレー ログ内のイベントを読み取り、実行して、マスター サーバーとのデータ同期を実現します。

エラー ログ、スロー クエリ ログなど、マスター/スレーブ レプリケーションでは比較的小さな役割と重要性しか持たないログの種類もいくつかあります。

3. MySQL マスター/スレーブ レプリケーション構成

  1. マスターサーバーで MySQL を構成し、マスターサーバーの MySQL 構成ファイル my.cnf を開きます (システムに応じて、/etc/mysql/my.cnf、/etc/my.cnf、または /usr/local/mysql/etc/my.cnf にある場合があります。) 次の構成を追加または変更します。
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log

server-id は一意の番号に設定する必要があり、log_bin はバイナリ ログ ファイルの場所を定義します。

  1. MySQL サービスを再起動して新しい構成を適用します。
service mysql restart
  1. マスターサーバー上でレプリケーション用のユーザーを作成し、必要な権限を付与します。
mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
  1. マスターサーバーのステータスを確認します。
mysql> SHOW MASTER STATUS;

SHOW MASTER STATUS;コマンドを実行すると、次のような出力が表示されます。

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

ここでFile(mysql-bin.000001) とPosition(107) はスレーブ サーバーをセットアップするときに使用する必要がある重要な情報であり、これら 2 つの値を記録する必要があります。
スレーブサーバーを構成するときに使用されるファイルと位置の値を書き留めます。

  1. 次に、スレーブ サーバー上で構成し、my.cnf ファイルを編集し、次の構成を追加または変更する必要もあります。
[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log

ここのサーバー ID はメインサーバーのサーバー ID とは異なる必要があります。

  1. スレーブ サーバーで MySQL サービスを再起動します。

  2. スレーブサーバーでレプリケーションを設定し、以前にマスターサーバーで作成したユーザーを使用し、合計を書き留めてFile記入PositionしますMASTER_LOG_FILEMASTER_LOG_POS

mysql> CHANGE MASTER TO MASTER_HOST='master_host_name',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='password',
    -> MASTER_LOG_FILE='recorded_log_file_name',
    -> MASTER_LOG_POS=recorded_log_position;
  1. コピーを開始します:
mysql> START SLAVE;

失敗すると出力されることがある
スレーブが正しく構成されていない場合、次のようなエラー メッセージが表示される場合があります。

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

スレーブサーバーの状態を確認し、正常に起動したかどうかを確認したい場合は、SHOW SLAVE STATUS;コマンドを実行します。これにより、サーバーからのさまざまなステータス情報が表示されます。
9. 次のコマンドを使用してスレーブ サーバーのステータスをチェックし、レプリケーションが適切に実行されていることを確認します。

mysql> SHOW SLAVE STATUS\G;

構成が正しく、マスター/スレーブ レプリケーションが正常に実行されている場合は、「Slave_IO_Running: Yes」および「Slave_SQL_Running: Yes」が表示されます。

成功した結果の例:

mysql> SHOW SLAVE STATUS;
+------------------+-------------+-------------+-------------+---------------+------------------+-------------------+-------------------+...
| Slave_IO_State   | Master_Host | Master_User | Master_Port | Connect_Retry | Master_Log_File  | Read_Master_Log_Pos | Relay_Log_File    |...
+------------------+-------------+-------------+-------------+---------------+------------------+-------------------+-------------------+...
| Waiting for master to send event | localhost | root        | 3306          | 60              | mysql-bin.000002  | 323              | mysq...
+------------------+-------------+-------------+-------------+---------------+------------------+-------------------+-------------------+...
1 row in set (0.00 sec)

実行結果で。IO スレッドはメイン サーバーがイベントを送信するのを待っています。メイン サーバーはローカルで実行されている MySQL サーバーです。メイン サーバーに接続するユーザー名は root で、ポートは 3306 です。接続が失敗した場合は、60 秒ごとに再試行されます。メインサーバーのバイナリログファイル名はmysql-bin.000002、マスターサーバーのバイナリログファイルから読み取った位置は323、スレーブサーバーのリレーログファイル名はmysql-relay-bin.000001です。

SHOW SLAVE STATUS;このコマンドは、レプリケーション スレーブのステータス変数で構成される行を返します。

  • Slave_IO_State:
    Slave_IO_Stateスレーブ IO スレッドの現在の状態列は、レプリケーション I/O スレッドの状態を示します。一般的な状態をいくつか示します。
  1. Connecting to master:マスターサーバーに接続中であることを示します。
  2. Waiting for master to send event: 接続が確立され、マスターサーバーがバイナリログイベントを送信するのを待っていることを示します。
  3. Reading event from the master: マスターサーバーからバイナリログイベントが読み取られていることを示します。
  4. Waiting to reconnect after a failed master event read: プライマリ サーバーのバイナリ ログ イベントの読み取りに失敗し、接続の再試行を待機していることを示します。
  5. Waiting for the slave SQL thread to free enough relay log space: レプリケーション SQL スレッドが十分なリレー ログ領域を解放するのを待っていることを示します。
  6. Queueing master event to the relay log: マスターから読み取られたイベントがリレーログに書き込まれることを示します。
  7. Waiting for master to send event: 新しいイベントが待機中であることを示します。
  8. Checking master version:マスタサーバのバージョンを確認してください。
  9. Registering slave on master: マスターサーバーにスレーブサーバーを登録します。
  10. Requesting binlog dump: プライマリ サーバーにバイナリ ログの送信を要求します。
  11. Waiting to reconnect after a failed binlog dump request: バイナリ ログへのリクエストが失敗した後、再接続を待ちます。
  12. Finished reading one binlog; switching to next binlog: バイナリ ログの読み取りを終了し、次のバイナリ ログに切り替えます。
  • Master_Host: マスターサーバーのホスト名またはIP
  • Master_User: マスターサーバーに接続するためのユーザー名
  • Master_Port: マスターサーバーのポート
  • Connect_Retry: 接続に失敗した場合のリトライ間隔(秒)
  • Master_Log_File: マスターサーバーのバイナリログファイル名
  • Read_Master_Log_Pos: マスターのバイナリ ログ ファイルから読み取る位置
  • Relay_Log_File: スレーブサーバーのリレーログファイル名
  • Relay_Log_Pos: サーバーのリレーログファイルから読み取る位置
  • Relay_Master_Log_File: リレー ログ内のマスター サーバーのバイナリ ログ ファイル名
  • Slave_IO_Running: IO スレッドが実行中かどうか
  • Slave_SQL_Running: SQL スレッドが実行中かどうか
  • Replicate_Do_DB: レプリケートされるデータベース。データベースが指定されていない場合、この項目は空です。
  • Replicate_Ignore_DB: 無視するデータベース。データベースが指定されていない場合、この項目は空です
  • Last_Errno: 最後のエラーのエラー番号
  • Last_Error: 最後のエラーのエラー メッセージ

4. 参考文献

  1. 公式サイト MySQL 8.0 リファレンスマニュアル -17 レプリケーション:https://dev.mysql.com/doc/refman/8.0/en/replication.html

  2. 「SHOW SLAVE STATUS 構文」セクションでは、Slave_IO_State について詳しく説明しています: https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html

おすすめ

転載: blog.csdn.net/wangshuai6707/article/details/132586257