MySQL 半同期レプリケーションの原理構成と導入の詳細な説明

環境の紹介:

Ubuntu Server 16.04.2+MySQL 5.7.17 コミュニティサーバー (GPL)

MySQLのインストール

APT 経由でインストールします。公式ガイドドキュメントのアドレス:
参考:

1. mysql-apt-config_0.8.3-1_all.debをダウンロードする

2. debをインストールする

MySQL APT リポジトリの使用に関するクイックガイド:
https://dev.mysql.com/doc/mysql-apt-repo-クイックガイド/en/

>sudo dpkg -i mysql-apt-config_0.8.3-1_all.deb

3. ソースの更新

>sudo apt-getアップデート

4. MySQLをインストールする

>sudo apt-getでmysql-serverをインストール

5. インストールを選択し、プロンプトに従ってパスワードを設定します。

さらに、ファイアウォールの IP をバインドし、ポート 3306 を開く設定も必要です。ここでは主に MySQL の準同期レプリケーションについて学習し、MySQL のインストールについてはあまり説明しません。質問がある場合は、メッセージを残してください。

MySQL 準同期レプリケーションの紹介

（1）デフォルトでは、MySQLのレプリケーション機能は非同期であり、最高のパフォーマンスを提供できます。マスターデータベースがbinlogログをスレーブデータベースに送信すると、アクションが完了し、スレーブデータベースがログを受信したかどうかは確認されません。このプロセスは、マスターサーバーまたはスレーブサーバーに障害が発生した場合、スレーブサーバーがマスターサーバーから送信されたbinlogログを受信できない可能性があることを意味し、マスターサーバーとスレーブサーバーの間でデータの不整合が発生し、回復中にデータが失われることもあります。

知らせ：

マスターサーバーとスレーブサーバーの両方で半同期レプリケーションモードを有効にする必要があります。有効にしないと、マスターサーバーはデフォルトで非同期レプリケーションモードを使用します。

（２）非同期レプリケーションの場合：

MySQL5.6 データベースのマスター/スレーブ同期のインストールと構成の詳細

（3）上記の可能性のあるエラーに対処するために、MySQL 5.5では半同期レプリケーションモードが導入されました。このモードでは、スレーブサーバーがマスターサーバーから送信されたbinlogログファイルを受信し、それを自身のrelay logに書き込むことが保証されます。次に、マスターサーバーにフィードバックを送信して、受信したことを通知します。その後、メインサービススレッドは現在のsessionに戻り、操作が完了したことを通知します。

（4）タイムアウトが発生すると、マスターサーバーは、少なくとも1台のスレーブサーバーが時間内に情報を受信するまで、一時的に非同期レプリケーションモードに切り替わります。

（５）リレーログの自己修復：

MySQL 5.5.X バージョンから、 relay_log_recoveryパラメータが追加されました。このパラメータの機能は次のとおりです。スレーブデータベースがクラッシュし、 relay.logが破損して一部のリレーログが処理されなくなった場合、実行されていないすべてのrelay-logが自動的に破棄され、ログがmasterから再度取得されるため、 relay-logの整合性が確保されます。この機能はデフォルトでは無効になっています。relay_log_recovery relay_log_recovery値が 1 に設定されている場合、この機能はスレーブデータベースで有効にできます。有効にすることをお勧めします。

（6）半同期レプリケーションと非同期レプリケーションの切り替え：

半同期レプリケーションの動作原理は、スレーブ IO_Thread スレッドが binlog ログを受信すると、マスターに確認を与える必要があるというものです。rpl_semi_sync_master_timeout rpl_semi_sync_master_timeout=10000 (10 秒) で、スレーブから 10 秒以上受信確認信号が受信されない場合、自動的に従来の非同期レプリケーションモードに切り替わります。

MySQL 半同期レプリケーション構成

まず、次の 2 つの MySQL をインストールする必要があります。

マスター: 192.168.1.227
スレーブ: 192.168.1.224

元のデータベースは次のようになります。

1. マスター構成

（1）マスターデータベースに半同期レプリケーションプラグインをインストールします。

mysql>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

（2）マスター上で半同期レプリケーションを有効にする：

mysql> グローバル rpl_semi_sync_master_enabled = 1 を設定します。

（3） mysqld.cnf設定ファイルを変更します。

上記の画像は、MySQL 構成のファイルパスを示しています。

[mysqld]

ログ bin = mysql bin
サーバーID = 10086
サーバーIDビット = 33
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000

（4）MySQLサーバのUUID設定ファイルを変更します。

root@xuliugen:/var/lib/mysql# pwd
var/lib/mysql の

auto.cnfファイルを変更します。server server-uuidの値の形式は、スレーブと区別するために固定されています。

[自動]
サーバーUUID=8d90feb7-1a88-11e7-9d11-000c298a546f

（5）設定が成功したかどうかを確認します。

mysql>PLUGIN_NAME、PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';

（6）パラメータの説明：

1. rpl_semi_sync_master_enabled = 1 、マスター上で半同期レプリケーションモードが有効になっていることを示します。

2. rpl_semi_sync_master_timeout = 10000 、トランザクション内のマスターデータベースの待機時間が 10000 ミリ秒を超えると、非同期レプリケーションモードにダウングレードされ、スレーブデータベースを待機しないことを意味します。マスターデータベースは、スレーブが再び回復したことを検出すると、自動的に半同期レプリケーションモードに戻ります。

3. rpl_semi_sync_master_wait_no_slave 、各トランザクションがコミットされた後にマスターがスレーブの受信確認信号を待機できるかどうかを示します。デフォルトは ON で、すべてのトランザクションが待機することを意味します。 OFF の場合、スレーブが追いついた後に半同期レプリケーションモードは有効にならないため、手動で有効にする必要があります。

4. rpl_semi_sync_master_trace_level = 32は、準同期レプリケーションモードが有効な場合に使用されるデバッグレベルを示します。デフォルト値は 32 です。

マスターを構成するときに、1 つだけ設定され、その他はデフォルト設定に設定されていることがわかります。

2. スレーブ構成

（1）スレーブデータベースに半同期レプリケーションプラグインをインストールします。

mysql>INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

（2）スレーブ上で半同期レプリケーションを有効にする：

mysql> グローバル rpl_semi_sync_slave_enabled = 1 を設定します。

（3） mysqld.cnf設定ファイルを変更します。

[mysqld]

ログ bin = mysql bin
サーバーID=10089
サーバーIDビット = 32
rpl_semi_sync_slave_enabled = 1

（4）MySQLサーバのUUID設定ファイルを変更します。

root@xuliugen:/var/lib/mysql# pwd
var/lib/mysql の

auto.cnfファイルを変更します。server server-uuidの値の形式は、スレーブと区別するために固定されています。

[自動]
サーバーUUID=8d90feb7-1a88-11e7-9d11-000c298a123f

マスターのserver-uuidとは異なることを確認してください。

（5）設定が成功したかどうかを確認します。

mysql>PLUGIN_NAME、PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';

（6）パラメータの説明：

1. rpl_semi_sync_slave_enabled = 1 、スレーブで半同期レプリケーションモードが有効になっていることを示します。

2. rpl_semi_sync_slave_trace_level = 32は、準同期レプリケーションモードが有効な場合に使用されるデバッグレベルを示します。デフォルト値は 32 です。

3. スレーブのマスターを指定する

（1）コマンドラインモードでマスターを再起動する

root@xuliugen:~# サービスmysqlを再起動します

（２）コマンドラインモードでスレーブを再起動する

root@xuliugen:~# サービスmysqlを再起動します

（3）マスターステータスを確認する：

mysql> マスターステータスを表示します\G;
************************** 1. 行 ****************************
       ファイル:mysql-bin.000004
     ポジション: 154
   バイナリログ_Do_DB:
 バイナリログを無視:
実行されたGtidセット:
セット内の1行（0.02秒）

マイSQL>

知らせ：

ファイル:mysql-bin.000004
ポジション: 154

非常に重要なので、後で必要になります。

（4）スレーブのマスターを指定します。

1. まず、スレーブの準同期レプリケーションをオフにします

mysql> スレーブを停止します。
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

2. スレーブのマスターを指定する

mysql>マスターをmaster_host='192.168.1.227'、master_user='root'、master_password='123456'、master_log_file='mysql-bin.000004'、master_log_pos=154に変更します。

クエリは正常、影響を受けた行は 0 行、警告は 2 件 (0.02 秒)

で：

master_host='192.168.1.227'、マスター データベースの IP アドレスmaster_user='root'、マスター データベースのアカウントmaster_password='123456'、マスター データベースの root ユーザー パスワードmaster_log_file='mysql-bin.000004'、マスター データベースの binlog ファイルmaster_log_pos=154、マスター データベースの binlog ファイルの位置

知らせ：

MySQL バージョン 5.6 以降では、マスタースレーブレプリケーションを実行するときに GTID 方式を使用できます。binglog と pos ポイントを探す必要はありません。マスターサーバーの IP、ポート、アカウント、パスワードを知っているだけで、同期のポイントが自動的に見つかります。GTID 機能が有効になっている場合は、binlog と pos を使用する必要はありません。詳細については、関連資料を参照してください。

3. スレーブの準同期レプリケーションを有効にする

mysql> スレーブを起動します。
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

4. 半同期レプリケーションが成功するかどうかをテストする

5. スレーブ同期情報を適切に閉じる方法

ある時点で、サーバーはスレーブとして使用されなくなるため、通常は次のコマンドを使用して同期情報をクリアする必要があります。

mysql> stop slave #シャットダウン firstmysql> reset slave #スレーブ同期情報をクリア

ただし、show master status\G で表示される場合は次のようになります。

mysql> マスターステータスを表示します\G;

同期情報は引き続き表示されます。これは、 reset slaveを実行するとmaster.infoファイルとrelay-log.infoファイルのみが削除され、同期情報はそのまま残るためです。誰かがstart slaveコマンドを実行して同期機能をオンにすると、同期が最初からやり直され、データが失われる可能性があります。

どうすればもっとわかりやすくなりますか?次のコマンドを使用してください:

mysql> stop slave #最初にシャットダウンmysql> reset slave all#スレーブ同期情報をクリア

show master status\G再度実行しても、情報は表示されません。

VI. 異常シナリオのシミュレーション

（１）半同期レプリケーションと非同期レプリケーションの切り替え：

上記では、半同期レプリケーションから非同期レプリケーションへの切り替えが発生する理由について説明しました。次に、デモ用のシナリオをシミュレートしてみましょう。

シナリオは次のとおりです。

1. スレーブ同期を閉じ、バイナリログログのIO受信を停止します。

mysql> スレーブを停止します。

この操作は IO スレッドをシャットダウンし、10 秒間待機します。マスターがスレーブから確認を受信しない場合は、非同期レプリケーションモードに切り替わります。

上の図では、スレーブが半同期レプリケーションモードをオフにしてから再度オンにしたことがわかります。

mysql> スレーブを起動します。

この時点で、半同期レプリケーションモードが復元されました。

（２）同期エラーケースのデモンストレーション：

まず、スレーブライブラリからデータベーステーブルufindを削除し、次にマスターでライブラリufind再度削除します。同期によってエラーが報告されます。

Last_Error: クエリでエラー「データベース 'ufind' を削除できません。データベースが存在しません」が発生しました。デフォルトのデータベース: 'ufind'。クエリ: 'DROP DATABASE `ufind`'

この時点で、半同期ステータスを確認します。

有効になっているため、半同期レプリケーションモードは非同期レプリケーションモードに変換されません。半同期レプリケーションモードはIO_Threadに直接関連していますが、 SQL_THREADとは関係がないことがわかります。

つまり、スレーブライブラリからバイナリログを受け取った後、マスターライブラリに確認を与えますが、 relay-logリレーログが実行されるかどうかは気にしません。

6. 半同期レプリケーションモードのパフォーマンス分析、利点と欠点

通常の状況では、非同期レプリケーションモードはサーバーからの応答を待つ必要がないため、半同期レプリケーションモードよりも速度が速く、スループットが高くなります。データの更新、挿入、削除を行う場合、その速度は半同期レプリケーションモードよりも速くなります。ただし、半同期レプリケーションモードはデータの一貫性を保つために役立ちます。一貫性の要件が高く、ネットワークの変動が小さい一部のデータでは、半同期レプリケーションモードを使用できます。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: