MySQL マスタースレーブの原理と構成の詳細

MySQLのマスタースレーブ構成と原理、参考までに具体的な内容は以下のとおりです。

1. 環境の選択:

1. Centos 6.5

2.MySQL 5.7

2. MySQLマスタースレーブレプリケーションとは

MySQL マスタースレーブレプリケーションは、最も重要な機能の 1 つです。マスタースレーブレプリケーションとは、1 台のサーバーがマスターデータベースサーバーとして機能し、別のサーバーまたは複数のサーバーがスレーブデータベースサーバーとして機能することを意味します。マスターサーバーのデータは、スレーブサーバーに自動的にコピーされます。マルチレベルレプリケーションでは、データベースサーバーはマスターまたはスレーブのいずれかとして機能できます。 MySQL マスタースレーブレプリケーションの基本は、マスターサーバーがデータベースの変更のバイナリログを記録し、スレーブサーバーがマスターサーバーのバイナリログを通じて自動的に更新を実行することです。

3. MySQL マスタースレーブレプリケーションの種類

1. ステートメントベースのレプリケーション

マスターサーバーで実行されたステートメントは、スレーブサーバーで再度実行されます。これは、MySQL バージョン 3.23 以降でサポートされています。

デメリット: 時間が完全に同期されない可能性があり、偏差が発生し、ステートメントを実行するユーザーが異なる場合があります。

2. 行ベースのレプリケーション

どのステートメントによって変更が行われたかに関係なく、メインサーバー上の変更されたコンテンツを直接コピーします。この方法は、MySQL 5.0 以降で導入されました。

デメリット: たとえば、給与テーブルに 10,000 人のユーザーがいて、各ユーザーの給与に 1000 を加算する場合、行ベースのレプリケーションでは 10,000 行をコピーする必要があり、大きなオーバーヘッドが発生しますが、ステートメントベースのレプリケーションでは 1 つのステートメントのみが必要です。

3. 混合型のレプリケーション

MySQL はデフォルトでステートメントベースのレプリケーションを使用します。ステートメントベースのレプリケーションで問題が発生する場合は、行ベースのレプリケーションが使用され、MySQL は自動的にそれを選択します。

MySQL マスタースレーブレプリケーションアーキテクチャでは、読み取り操作はすべてのサーバーで実行できますが、書き込み操作はマスターサーバーでのみ実行できます。マスタースレーブレプリケーションアーキテクチャは読み取り操作の拡張を提供しますが、書き込み操作が多い場合（複数のスレーブサーバーがマスターサーバーからデータを同期する必要がある）、マスターサーバーは必然的に単一マスターモデルのレプリケーションのパフォーマンスボトルネックになります。

4. 原則

1. マスタースレーブ

マスターサーバーでの変更はすべてバイナリログに保存されます。スレーブサーバーで I/O スレッド (実際にはマスターサーバーのクライアントプロセス) が開始され、マスターサーバーに接続してバイナリログの読み取りを要求し、読み取ったバイナリログをローカルのリアルログに書き込みます。サーバー上で SQL スレッドを開始し、定期的に realy ログを確認します。変更が見つかった場合は、ローカルコンピューターですぐに変更を実行します。

2. マスター-スレーブ-スレーブ

マスターが 1 つでスレーブが複数ある場合、マスターデータベースは複数のスレーブデータベースのバイナリログの書き込みと提供の両方を担当します。この時点で、いくつかの調整を行って、バイナリログを特定のスレーブにのみ渡すことができます。このスレーブはバイナリログを有効にし、独自のバイナリログを他のスレーブに送信します。または、このスレーブに何も記録させず、バイナリログを他のスレーブに転送するだけにします。このアーキテクチャではパフォーマンスが大幅に向上し、データ間の遅延もわずかに改善されるはずです。

【知らせ】

1. MySQL の古いバージョンでは、マスタースレーブレプリケーションのスレーブセグメントは 2 つのプロセスではなく 1 つのプロセスで完了していたため、多くのリスクとパフォーマンス関連の問題が発生していました。具体的な問題点は以下のとおりです。

1. プロセスは、bin-log ログのコピーとログの解析、およびそれら自体の実行をシリアルプロセスにします。これにより、パフォーマンスがある程度制限され、非同期レプリケーションの遅延が長くなります。

2. スレーブ側はマスター側からバイナリログを取得した後、ログの内容を解析して独自に実行する必要があります。このプロセス中に、マスター側で多数の変更が発生し、多数の新しいログが追加された可能性があります。この段階でマスター側のストレージに回復不可能なエラーが発生した場合、この段階で行われたすべての変更は元に戻せません。スレーブ側の圧力が比較的高い場合、このプロセスにはより長い時間がかかることがあります。

5. MySQLマスタースレーブレプリケーションのプロセス

1. 2 つの状況: 同期レプリケーションと非同期レプリケーション。非同期レプリケーションは主に実稼働環境で使用されます。

2. 複製の基本的なプロセス:

1. スレーブ上の I/O プロセスはマスターに接続し、指定されたファイルの指定された位置以降 (またはログの先頭から) のログの内容を要求します。

2. マスターがスレーブのIOプロセスからの要求を受信すると、レプリケーションを担当するIOプロセスは、要求情報に従ってログの指定された位置以降のログ情報を読み取り、スレーブのIOプロセスに返します。返される情報には、ログに含まれる情報に加えて、今回返された情報が到着したマスター側の bin-log ファイル名と bin-log の場所も含まれます。

3. スレーブの IO プロセスは、情報を受信した後、受信したログ内容をスレーブのリレーログファイルの末尾に順番に追加し、マスターから読み取ったバイナリログのファイル名と位置をマスター情報ファイルに記録します。これにより、次回の読み取り時に、マスターに「バイナリログの特定の位置のログ内容が必要です。送信してください」と明確に伝えることができます。

4. スレーブの SQL プロセスは、リレーログに追加された新しいコンテンツを検出すると、マスター側で実際に実行されるときに、リレーログのコンテンツをすぐに実行可能なコンテンツに解析し、スレーブ自身で実行します。

6. 構成:

1. まず、次の 2 つの状況を明確にします。

1. 2 台の独立したサーバーまたは仮想マシン。

2. テンプレートを使用して作成された 2 つの仮想マシン。

2. 2 つのサーバーに、MySQL マスターサーバーと MySQL スレーブサーバーの名前を付けます。

3. マスターサーバーとスレーブサーバーはそれぞれ次の操作を実行します。

1. MySQLのバージョンは一貫している

2. テーブルを初期化する

4. MySQL マスターサーバーと MySQL スレーブサーバーを変更します。

vim /etc/my.cnf 
[mysqld] 
log-bin=任意の名前 //バイナリログを有効にする server-id=任意の番号 //サーバーの一意のID。デフォルト値は1で、通常はIPアドレスの最後の桁に設定されます。

5. 最初のケースでは、2 つのサーバーを直接再起動します。2 番目のケースでは、2 つのサーバーの auto.cnf ファイルの名前を auto.cnf.bak に変更してから、MySQL サービスを再起動します。

6. MySQLマスターサーバーにアカウントを作成し、スレーブを承認する

'任意のパスワード' で識別される 'ユーザー名'@'%' に *.* のレプリケーション スレーブを付与します。

7. MySQLマスターサーバーのステータスを照会する

マスターステータスを表示します。

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

マスターを変更する 
master_host = 'MySQLマスターサーバーのIPアドレス'、 
master_user = 'MySQLマスターサーバーで以前に作成されたユーザー名'、 
master_password = '以前に作成したパスワード'、 
master_log_file = 'MySQL マスター サーバー ステータス バイナリ ファイル名', 
master_log_pos='MySQL マスター サーバーのステータスの位置値';

9. スレーブを有効にする