MySQL 高可用性ソリューション MMM (MySQL マルチマスター レプリケーション マネージャー)

1. MMMの紹介:

MMM は、Multi-Master Replication Manager for MySQL の略です。Perl ベースの MySQL マルチマスター レプリケーション マネージャーは、MySQL マスター マスター レプリケーション構成の監視、フェイルオーバー、管理を行うスケーラブルなスクリプト スイートです (一度に書き込めるのは 1 つのノードのみです)。MMM はスレーブ サーバーで読み取り負荷分散も実行できるため、レプリケーションに使用するサーバー グループで仮想 IP を起動するのに使用できます。さらに、ノード間のデータ バックアップと再同期を実装するためのスクリプトもあります。 MySQL 自体はレプリケーション フェイルオーバー ソリューションを提供していません。MMM ソリューションはサーバー フェイルオーバーを実現し、MySQL の高可用性を実現します。 MMM はフローティング IP の機能を提供するだけでなく、現在のマスター サーバーに障害が発生した場合に、同期構成を手動で変更することなく、バックエンド スレーブ サーバーを新しいマスター サーバーに自動的に切り替えて同期レプリケーションを実行します。このソリューションは、現時点では比較的成熟したソリューションです。詳細については、公式ウェブサイトをご覧ください：http://mysql-mmm.org

利点: 高可用性、優れたスケーラビリティ、障害発生時の自動切り替え、マスター間同期では、データの一貫性を確保するために、同時に書き込み操作に提供されるデータベースは 1 つだけです。マスター サーバーに障害が発生すると、別のマスター サーバーが直ちに引き継ぎ、他のスレーブ サーバーは手動による介入なしに自動的に切り替えることができます。

デメリット: モニターノードは単一ポイントですが、keepalived または haertbeat を組み合わせて高可用性を実現することもできます。少なくとも 3 つのノードが必要で、ホストの数に関する要件があり、読み取り/書き込み分離を実装する必要があり、フロントエンドに読み取り/書き込み分離プログラムを記述する必要があります。読み取りおよび書き込みトラフィックが非常に多い業務システムでは、パフォーマンスがあまり安定せず、レプリケーションの遅延や切り替えの失敗などの問題が発生する可能性があります。 MMM ソリューションは、データ セキュリティの要件が高く、読み取りと書き込みが頻繁に行われる環境にはあまり適していません。

適用可能なシナリオ:

MMM は、データベースへのアクセス量が多く、読み取りと書き込みの分離を実現できるシナリオに適用できます。
Mmm の主な機能は、次の 3 つのスクリプトによって提供されます。
mmm_mond は、すべての監視タスクを担当する監視デーモンであり、ノードの削除などを決定します (mmm_mond プロセスは定期的にハートビート検出を実行し、失敗した場合は書き込み IP が別のマスターにフロートされます)。
mmm_agentd は、MySQL サーバー上で実行されるエージェント デーモンであり、単純なリモート サービス セットを通じて監視ノードに提供されます。
mmm_control は、コマンドラインを通じて mmm_mond プロセスを管理します。監視プロセス全体を通して、MySQL に関連する承認済みユーザーを追加する必要があります。承認済みユーザーには、mmm_monitor ユーザーと mmm_agent ユーザーが含まれます。mm のバックアップ ツールを使用する場合は、mmm_tools ユーザーも追加する必要があります。

2. 展開と実装

1. 環境の紹介

OS: centos7.2 (64ビット) データベースシステム: mysql5.7.13

selinuxをオフにする

時刻を同期するためにntpを設定する

2. すべてのホストで /etc/hosts ファイルを設定し、次の内容を追加します。

192.168.31.83 マスター1
192.168.31.141 マスター2
192.168.31.250 スレーブ1
192.168.31.225 スレーブ2
192.168.31.106 モニター1

すべてのホストに perl、perl-devel、perl-CPAN、libart_lgpl.x86_64、rrdtool.x86_64、rrdtool-perl.x86_64 パッケージをインストールします。
#yum -y インストール perl-* libart_lgpl.x86_64 rrdtool.x86_64 rrdtool-perl.x86_64

注: Centos7オンラインyumソースインストールを使用してください

Perl関連のライブラリをインストールする

#cpan -i アルゴリズム::Diff クラス::シングルトン DBI DBD::mysql ログ::ディスパッチ ログ::Log4perl メール::Send ネット::Ping プロセス::デーモン 時間::HiRes パラメータ::Validate ネット::ARP

3. mysql5.7をインストールし、master1、master2、slave1、slave2ホストにレプリケーションを設定します。

Master1 と master2 は互いにマスタースレーブであり、slave1 と slave2 は master1 のスレーブです。各 MySQL 構成ファイル /etc/my.cnf に次の内容を追加します。server_id は繰り返すことができないことに注意してください。

マスター1ホスト:

ログ bin = mysql bin
binlog_format = 混合
サーバーID = 1
リレーログ = リレービン
リレーログインデックス = スレーブリレービンインデックス
ログスレーブ更新 = 1
自動増分増加 = 2
自動増分オフセット = 1
マスター2ホスト:
ログ bin = mysql bin
binlog_format = 混合
サーバーID = 2
リレーログ = リレービン
リレーログインデックス = スレーブリレービンインデックス
ログスレーブ更新 = 1
自動増分増加 = 2
自動増分オフセット = 2
スレーブ1ホスト:
サーバーID = 3
リレーログ = リレービン
リレーログインデックス = スレーブリレービンインデックス
読み取り専用 = 1
スレーブ2ホスト:
サーバーID = 4
リレーログ = リレービン
リレーログインデックス = スレーブリレービンインデックス
読み取り専用 = 1

my.cnfの変更が完了したら、systemctl restart mysqldでMySQLサービスを再起動します。

4 つのデータベース ホストでファイアウォールを有効にするには、ファイアウォールを無効にするか、アクセス ルールを作成します。

ファイアウォールコマンド --permanent --add-port=3306/tcp
ファイアウォール-cmd --reload
マスタースレーブ構成 (master1 と master2 はマスターとして構成され、slave1 と slave2 は master1 のスレーブとして構成されます):
master1 で承認:
mysql> '123456' で識別される rep@'192.168.31.%' に *.* のレプリケーション スレーブを許可します。
マスター2で承認:
mysql> '123456' で識別される rep@'192.168.31.%' に *.* のレプリケーション スレーブを許可します。
master2、slave1、slave2 を master1 のスレーブとして設定します。
master1でshow master statusを実行し、binlogファイルと位置ポイントを取得します。
mysql> マスターステータスを表示します。
+------------------+----------+--------------+------------------+--------------------------------------------------+
| ファイル | 位置 | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+--------------------------------------------------+
| mysql-bin.000001 | 452 | | | |
+------------------+----------+--------------+------------------+-----------------------------------------------------+
マスター2、スレーブ1、スレーブ2で実行

mysql> マスターを、master_host='192.168.31.83'、master_port=3306、master_user='rep'、master_password='123456'、master_log_file='mysql-bin.000001'、master_log_pos=452 に変更します。
mysql>スレーブを起動します。
マスタースレーブレプリケーションを確認します。
マスター2ホスト:
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.83
マスターユーザー: 担当者
マスターポート: 3306
接続再試行: 60
マスターログファイル:mysql-bin.000001
読み取りマスターログ位置: 452
リレーログファイル: リレーbin.000002
リレーログ位置: 320
リレーマスターログファイル: mysql-bin.000001
スレーブIO実行中: はい
スレーブSQL実行中: はい
スレーブ1ホスト:
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.83
マスターユーザー: 担当者
マスターポート: 3306
接続再試行: 60
マスターログファイル:mysql-bin.000001
読み取りマスターログ位置: 452
リレーログファイル: リレーbin.000002
リレーログ位置: 320
リレーマスターログファイル: mysql-bin.000001
スレーブIO実行中: はい
スレーブSQL実行中: はい
スレーブ2ホスト:
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.83
マスターユーザー: 担当者
マスターポート: 3306
接続再試行: 60
マスターログファイル:mysql-bin.000001
読み取りマスターログ位置: 452
リレーログファイル: リレーbin.000002
リレーログ位置: 320
リレーマスターログファイル: mysql-bin.000001
スレーブIO実行中: はい
スレーブSQL実行中: はい
Slave_IO_Running と Slave_SQL_Running の両方が yes の場合、マスター スレーブ構成は正常です。master1 を master2 のスレーブとして構成します。
master2でshow master statusを実行して、binlogファイルと位置ポイントを取得します。
mysql> マスターステータスを表示します。
+------------------+----------+--------------+------------------+--------------------------------------------------+
| ファイル | 位置 | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+--------------------------------------------------+
| mysql-bin.000001 | 452 | | | |
+------------------+----------+--------------+------------------+----------------------------------------------------+
master1 で実行:
mysql> マスターを master_host='192.168.31.141'、master_port=3306、master_user='rep'、master_password='123456'、master_log_file='mysql-bin.000001'、master_log_pos=452 に変更します。
mysql> スレーブを起動します。
マスタースレーブレプリケーションを確認します。
マスター1ホスト:
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.141
マスターユーザー: 担当者
マスターポート: 3306
接続再試行: 60
マスターログファイル:mysql-bin.000001
読み取りマスターログ位置: 452
リレーログファイル: リレーbin.000002
リレーログ位置: 320
リレーマスターログファイル: mysql-bin.000001
スレーブIO実行中: はい
スレーブSQL実行中: はい
Slave_IO_Running と Slave_SQL_Running の両方が yes の場合、マスター/スレーブ構成は正常です。
4.mysql-mmmの設定:
4 つの MySQL ノードにユーザーとプロキシ アカウントを作成します。
mysql> '123456' で識別される 'mmm_agent'@'192.168.31.%' に *.* の super、replicationclient、process を付与します。
監視アカウントを作成します。
mysql> *.* 上のレプリケーション クライアントを、'123456' で識別される 'mmm_monitor'@'192.168.31.%' に許可します。
注 1: 以前のマスター スレーブ レプリケーションとマスター スレーブはすでに正常だったため、master1 サーバーで実行したところ正常でした。
マスター2、スレーブ1、スレーブ2の3つのデータベースに監視アカウントとプロキシアカウントが存在するかどうかを確認します。
mysql> mysql.user から user、host を選択します。ここで、user は ('mmm_monitor','mmm_agent') です。
+-------------+----------------------------+
| ユーザー | ホスト |
+-------------+----------------------------+
| mmm_agent | 192.168.31.% |
| mmm_monitor | 192.168.31.% |
+-------------+------------------------------+
または
mysql> 'mmm_agent'@'192.168.31.%' の権限を表示します。
+---------------------------------------------------------------------------------------------------------------------------------+
| [email protected].% への許可 |
+---------------------------------------------------------------------------------------------------------------------------------+
| *.* のプロセス、スーパー、レプリケーション クライアントを 'mmm_agent'@'192.168.31.%' に許可します |
+---------------------------------------------------------------------------------------------------------------------------------+
mysql> 'mmm_monitor'@'192.168.31.%' の権限を表示します。
+---------------------------------------------------------------------------------------------------------------------------------+
| [email protected].% への許可 |
+---------------------------------------------------------------------------------------------------------------------------------+
| *.* のレプリケーション クライアントを 'mmm_monitor'@'192.168.31.%' に許可 |
注2:
mmm_monitor ユーザー: mmm モニタリングは、MySQL サーバー プロセスの健全性をチェックするために使用されます。
mmm_agent ユーザー: mmm エージェントは、読み取り専用モード、レプリケーション マスター サーバーなどを変更するために使用されます。
5. 監視ホスト（192.168.31.106）にmysql-mmmをインストールして監視プログラムをインストールします。
cd /tmp
http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz を実行します。
tar -zxf mysql-mmm-2.2.1.tar.gz
mysql-mmm-2.2.1 をインストールします
インストールする
データベースサーバー（master1、master2、slave1、slave2）にエージェントをインストールします。
cd /tmp
http://pkgs.fedoraproject.org/repo/pkgs/mysql-mmm/mysql-mmm-2.2.1.tar.gz/f5f8b48bdf89251d3183328f0249461e/mysql-mmm-2.2.1.tar.gz を実行します。
tar -zxf mysql-mmm-2.2.1.tar.gz
mysql-mmm-2.2.1 をインストールします
インストールする

6. mmmを設定する

設定ファイルを作成します。5 つのホストは一貫している必要があります。
インストールが完了すると、すべての設定ファイルは /etc/mysql-mmm/ の下に配置されます。管理サーバーとデータベース サーバーの両方に共通ファイル mmm_common.conf が含まれている必要があります。その内容は次のとおりです。
active_master_rolewriter#アクティブなマスター ロールを示します。すべての DB サーバーで read_only パラメータを有効にする必要があります。ライター サーバーの監視エージェントは、read_only 属性を自動的にオフにします。
<ホストのデフォルト>
cluster_interfaceeno16777736#クラスターネットワークインターフェース
pid_path /var/run/mmm_agentd.pid#pid パス
bin_path /usr/lib/mysql-mmm/#実行ファイルパス
replication_user rep#レプリケーションユーザー
replication_password 123456#レプリケーションユーザーパスワード
agent_usermmm_agent#エージェントユーザー
agent_password 123456#エージェントユーザーパスワード
</ホスト>
<host master1>#master1のホスト名
ip 192.168.31.83#マスター1のip
モードマスター#ロール属性、マスターはマスターを表します
ピアマスター2#マスター1に相当するサーバーのホスト名、つまりマスター2のサーバーホスト名
</ホスト>
<host master2>#マスターと同じ概念
ip 192.168.31.141
モードマスター
ピアマスター1
</ホスト>
<host slave1>#スレーブライブラリのホスト名。スレーブライブラリが複数ある場合は、同じ構成を繰り返すことができます。
ip 192.168.31.250#スレーブip
モードスレーブ#スレーブロール属性は、現在のホストが
</ホスト>
<host slave2>#スレーブと同じ概念
192.168.31.225 のIPアドレス
モードスレーブ
</ホスト>
<ロール ライター>#ライター ロールの設定
hosts master1、master2#書き込み操作を実行できるサーバーのホスト名。書き込み操作を切り替えたくない場合は、ここでマスターのみを設定できます。これにより、ネットワーク遅延による書き込みの切り替えも回避できます。ただし、マスターに障害が発生すると、現在の MMM にはライターがなくなり、外部読み取り操作のみが可能になります。
ips 192.168.31.2#外部書き込み操作用の仮想IP
モード排他#排他は、マスターが1つだけ存在できることを意味します。つまり、書き込みIPは1つだけ提供できます。
</役割>
<ロール リーダー>#ロール設定の読み取り
hosts master2,slave1,slave2#外部に読み取り操作を提供するサーバーのホスト名。もちろん、ここにmasterを追加することもできます
ips 192.168.31.3、192.168.31.4、192.168.31.5#外部読み取り操作用の仮想 ip。これらの 3 つの ip とホストは 1 対 1 で対応しておらず、ip とホストの数も異なる場合があります。このように構成すると、ホストの 1 つに 2 つの ip が割り当てられます。
モード balanced#balanced は負荷分散を表します
</役割>
同時に、設定を変更せずにこのファイルを他のサーバーにコピーします
#master1、master2、slave1、slave2のホストに対して、scp /etc/mysql-mmm/mmm_common.confを実行します。$host:/etc/mysql-mmm/ を実行します。完了です。
エージェントファイルの設定 4台のMySQLノードマシンで/etc/mysql-mmm/mmm_agent.confを編集します。
データベース サーバーには、変更する必要がある mmm_agent.conf もあり、その内容は次のとおりです。
含めるmmm_common.conf
このマスター1
注: この構成では、DB サーバーのみが構成されます。監視サーバーを構成する必要はありません。これ以降のホスト名は、現在のサーバーのホスト名に変更されます。
エージェントプロセスを開始します。スクリプトファイル /etc/init.d/mysql-mmm-agent の #!/bin/sh の下に次の内容を追加します。
ソース /root/.bash_profile
システムサービスとして追加し、自動的に開始するように設定します
#chkconfig --add mysql-mmm-agent を実行します。
#chkconfigmysql-mmm-agent をオンにする
#/etc/init.d/mysql-mmm-agent を起動します
注: source /root/.bash_profile を追加する目的は、起動時に mysql-mmm-agent サービスが自動的に開始されるようにすることです。
自動起動と手動起動の唯一の違いは、コンソールのアクティブ化です。つまり、サービスを開始すると、環境変数が不足しているために開始に失敗する可能性があり、エラー メッセージは次のようになります。
デーモン bin: '/usr/sbin/mmm_agentd'
デーモン pid: '/var/run/mmm_agentd.pid'
MMM エージェント デーモンを起動しています... /usr/sbin/mmm_agentd の 7 行目で、@INC (@INC には /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 が含まれています。) に Proc/Daemon.pm が見つかりません。
BEGIN に失敗しました - /usr/sbin/mmm_agentd の 7 行目でコンパイルが中止されました。
失敗した

解決：

# cpanProc::デーモン
# cpan ログ::Log4perl
# /etc/init.d/mysql-mmm-agent を起動します
デーモン bin: '/usr/sbin/mmm_agentd'
デーモン pid: '/var/run/mmm_agentd.pid'
MMM エージェント デーモンを起動しています... OK
# netstat -antp | grep mmm_agentd
tcp 0 0 192.168.31.83:9989 0.0.0.0:* LISTEN 9693/mmm_agentd
ファイアウォールの設定
ファイアウォールコマンド --permanent --add-port=9989/tcp
ファイアウォール-cmd --reload
モニターホストの/etc/mysql-mmm/mmm_mon.confを編集します。
含めるmmm_common.conf

<モニター>
ip 127.0.0.1##セキュリティ上の理由から、ローカルマシンでのみリッスンするように設定します。 mmm_mond はデフォルトで 9988 をリッスンします
pid_path /var/run/mmm_mond.pid
bin_path /usr/lib/mysql-mmm/
ステータスパス/var/lib/misc/mmm_mond.status
ping_ips192.168.31.83,192.168.31.141,192.168.31.250,192.168.31.225#ネットワークの可用性をテストするための IP アドレス リスト。アドレスの 1 つに ping が通れば、ネットワークは正常であることを意味します。ここにローカル アドレスを入力しないでください。
auto_set_online 0#自動オンラインの時間を設定します。デフォルトでは、60 秒後にオンラインに設定されます。デフォルトは 60 秒です。ここで 0 に設定すると、すぐにオンラインになります。
</モニター>

<デフォルトを確認>
チェック期間5
トラップ期間 10
タイムアウト2
#10000後に再起動
最大バックログ 86400
</チェック>
チェック期間
説明: デフォルトのチェック期間は 5 秒です。
デフォルト値: 5秒
トラップ期間
説明: ノードが trap_period 秒間検出されなかった場合、障害が発生したとみなされます。
デフォルト値: 10秒
タイムアウト
説明: タイムアウト時間をチェックします。デフォルト値: 2 秒
再起動後
説明: restart_after チェックを完了した後、チェッカー プロセスを再起動します。デフォルト値: 10000
最大バックログ
説明: rep_backlog ログをチェックする最大回数を記録します。デフォルト値: 60

<ホストのデフォルト>
monitor_usermmm_monitor#DBサーバーのユーザーを監視する
monitor_password 123456#DBサーバーのパスワードを監視する
</ホスト>
debug 0#debug 0 は通常モード、1 は監視プロセスを開始するためのデバッグ モードです。
スクリプトファイル /etc/init.d/mysql-mmm-agent の #!/bin/sh の下に次の内容を追加します。
ソース /root/.bash_profile
システムサービスとして追加し、自動的に開始するように設定します
#chkconfig --mysql-mmm-monitorを追加します
#chkconfigmysql-mmm-monitor オン
#/etc/init.d/mysql-mmm-monitor を起動します

起動エラー:

MMM モニター デーモンを起動しています: /usr/sbin/mmm_mond の 11 行目で、@INC (@INC には /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 が含まれています。) に Proc/Daemon.pm が見つかりません。
BEGIN が失敗しました - コンパイルは /usr/sbin/mmm_mond の 11 行目で中止されました。
失敗した
解決策: 次のPerlライブラリをインストールします
#cpanProc::デーモン
#cpan ログ::Log4perl
[root@monitor1 ~]# /etc/init.d/mysql-mmm-monitor を起動します
デーモン bin: '/usr/sbin/mmm_mond'
デーモン pid: '/var/run/mmm_mond.pid'
MMM モニターデーモンを起動しています: OK
[root@monitor1 ~]# netstat -anpt | grep 9988
tcp 0 0 127.0.0.1:9988 0.0.0.0:* LISTEN 8546/mmm_mond
注 1: データベース側または監視側のいずれかで構成ファイルが変更された場合は、エージェント プロセスと監視プロセスを再起動する必要があります。
注2: MMMの起動シーケンス: 最初にモニターを起動し、次にエージェントを起動します

クラスターのステータスを確認します。

[root@monitor1 ~]# mmm_control 表示
マスター1(192.168.31.83) マスター/オンライン。役割: ライター(192.168.31.2)
マスター2(192.168.31.141) マスター/オンライン。役割: リーダー(192.168.31.5)
スレーブ1(192.168.31.250) スレーブ/オンライン。役割: リーダー(192.168.31.4)
スレーブ2(192.168.31.225) スレーブ/オンライン。役割: リーダー(192.168.31.3)

サーバーのステータスが ONLINE でない場合は、次のコマンドを使用してサーバーをオンラインにすることができます。例:

#mmm_controlset_online ホスト名

例: [root@monitor1 ~]#mmm_controlset_onlinemaster1
上記の表示から、書き込み要求の VIP が master1 上にあり、すべてのスレーブ ノードも master1 をマスター ノードと見なしていることがわかります。
VIPが有効になっているか確認する
[root@master1 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST、MULTICAST、UP、LOWER_UP> mtu 1500 qdiscpfifo_fast 状態 UP qlen 1000
リンク/イーサ 00:0c:29:6d:2f:82 brdff:ff:ff:ff:ff:ff
inet 192.168.31.83/24 brd 192.168.31.255 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet 192.168.31.2/32 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet6 fe80::20c:29ff:fe6d:2f82/64 スコープ リンク
valid_lft 永久 preferred_lft 永久
[root@master2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST、MULTICAST、UP、LOWER_UP>mtu 1500 qdiscpfifo_fast 状態 UP qlen 1000
リンク/イーサ 00:0c:29:75:1a:9c brdff:ff:ff:ff:ff:ff
inet 192.168.31.141/24 brd 192.168.31.255 スコープ グローバル ダイナミック eno16777736
有効_lft 35850秒 推奨_lft 35850秒
inet 192.168.31.5/32 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet6 fe80::20c:29ff:fe75:1a9c/64 スコープ リンク
valid_lft 永久 preferred_lft 永久
[root@slave1 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST、MULTICAST、UP、LOWER_UP>mtu 1500 qdiscpfifo_fast 状態 UP qlen 1000
リンク/イーサ 00:0c:29:02:21:19 brdff:ff:ff:ff:ff:ff
inet 192.168.31.250/24 brd 192.168.31.255 スコープ グローバル ダイナミック eno16777736
有効_lft 35719秒 推奨_lft 35719秒
inet 192.168.31.4/32 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet6 fe80::20c:29ff:fe02:2119/64 スコープ リンク
valid_lft 永久 preferred_lft 永久
[root@slave2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST、MULTICAST、UP、LOWER_UP>mtu 1500 qdiscpfifo_fast 状態 UP qlen 1000
リンク/イーサ 00:0c:29:e2:c7:fa brdff:ff:ff:ff:ff:ff
inet 192.168.31.225/24 brd 192.168.31.255 スコープ グローバル ダイナミック eno16777736
有効_lft 35930秒 推奨_lft 35930秒
inet 192.168.31.3/32 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet6 fe80::20c:29ff:fee2:c7fa/64 スコープ リンク
valid_lft 永久 preferred_lft 永久
マスター2、スレーブ1、スレーブ2ホスト上のメインmysqlの方向を確認します。
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.83
マスターユーザー: 担当者
マスターポート: 3306
接続再試行: 60

MMM 高可用性テスト:

サーバーは読み取りと書き込みに VIP アドレスを使用します。障害が発生すると、VIP は他のノードに移動し、他のノードからサービスを提供します。
まずクラスタ全体の状態を確認すると、クラスタ全体が正常であることがわかります
[root@monitor1 ~]# mmm_control 表示
マスター1(192.168.31.83) マスター/オンライン。役割: ライター(192.168.31.2)
マスター2(192.168.31.141) マスター/オンライン。役割: リーダー(192.168.31.5)
スレーブ1(192.168.31.250) スレーブ/オンライン。役割: リーダー(192.168.31.4)
スレーブ2(192.168.31.225) スレーブ/オンライン。役割: リーダー(192.168.31.3)
master1 のダウンタイムをシミュレートし、MySQL サービスを手動で停止して、モニター ログを観察します。master1 のログは次のとおりです。
[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2017/01/09 22:02:55 警告 'master1' の 'rep_threads' が不明な状態です。メッセージ: 不明: 接続エラー (ホスト = 192.168.31.83:3306、ユーザー = mmm_monitor)。'192.168.31.83' の MySQL サーバーに接続できません (111)
2017/01/09 22:02:55 警告 'master1' の 'rep_backlog' が不明な状態です。メッセージ: 不明: 接続エラー (ホスト = 192.168.31.83:3306、ユーザー = mmm_monitor)。'192.168.31.83' の MySQL サーバーに接続できません (111)
2017/01/09 22:03:05 エラー 'master1' の 'my​​sql' チェックが 10 秒間失敗しました。メッセージ: エラー: 接続エラー (ホスト = 192.168.31.83:3306、ユーザー = mmm_monitor)。'192.168.31.83' の MySQL サーバーに接続できません (111)
2017/01/09 22:03:07 ホスト 'master1' の状態が ONLINE から HARD_OFFLINE に変更されました (ping: OK、mysql: 正常ではありません)
2017/01/09 22:03:07 INFO ホスト 'master1' からすべてのロールを削除しています:
2017/01/09 22:03:07 INFO ホスト「master1」からロール「writer(192.168.31.2)」を削除しました
2017/01/09 22:03:07 INFO 孤立したロール「writer(192.168.31.2)」が「master2」に割り当てられました
クラスターの最新のステータスを表示する
[root@monitor1 ~]# mmm_control 表示
master1(192.168.31.83) マスター/HARD_OFFLINE。役割:
master2(192.168.31.141) マスター/オンライン。役割: リーダー(192.168.31.5)、ライター(192.168.31.2)
スレーブ1(192.168.31.250) スレーブ/オンライン。役割: リーダー(192.168.31.4)
スレーブ2(192.168.31.225) スレーブ/オンライン。役割: リーダー(192.168.31.3)
表示された結果から、master1 のステータスが ONLINE から HARD_OFFLINE に変更され、書き込み VIP が master2 ホストに転送されたことがわかります。
すべてのDBサーバークラスタのステータスを確認する
[root@monitor1 ~]# mmm_controlはすべてをチェックします
master1 ping [最終更新: 2017/01/09 21:31:47] OK
master1 mysql [最終変更: 2017/01/09 22:03:07] エラー: 接続エラー (ホスト = 192.168.31.83:3306、ユーザー = mmm_monitor)! '192.168.31.83' の MySQL サーバーに接続できません (111)
master1 rep_threads [最終更新: 2017/01/09 21:31:47] OK
master1 rep_backlog [最終変更: 2017/01/09 21:31:47] OK: バックログは null です
slave1 ping [最終更新: 2017/01/09 21:31:47] OK
slave1mysql [最終更新: 2017/01/09 21:31:47] OK
slave1 rep_threads [最終更新: 2017/01/09 21:31:47] OK
slave1 rep_backlog [最終変更: 2017/01/09 21:31:47] OK: バックログは null です
master2 ping [最終更新: 2017/01/09 21:31:47] OK
master2 mysql [最終更新: 2017/01/09 21:57:32] OK
master2 rep_threads [最終更新: 2017/01/09 21:31:47] OK
master2 rep_backlog [最終変更: 2017/01/09 21:31:47] OK: バックログは null です
slave2 ping [最終更新: 2017/01/09 21:31:47] OK
slave2mysql [最終更新: 2017/01/09 21:31:47] OK
slave2 rep_threads [最終変更: 2017/01/09 21:31:47] OK
slave2 rep_backlog [最終変更: 2017/01/09 21:31:47] OK: バックログは null です
上記から、master1 に ping できることがわかります。これは、サービスのみが停止していることを意味します。

master2 ホストの IP アドレスを表示します。

[root@master2 ~]# ipaddr show dev eno16777736
eno16777736: <BROADCAST、MULTICAST、UP、LOWER_UP>mtu 1500 qdiscpfifo_fast 状態 UP qlen 1000
リンク/イーサ 00:0c:29:75:1a:9c brdff:ff:ff:ff:ff:ff
inet 192.168.31.141/24 brd 192.168.31.255 スコープ グローバル ダイナミック eno16777736
有効_lft 35519秒 推奨_lft 35519秒
inet 192.168.31.5/32 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet 192.168.31.2/32 スコープ グローバル eno16777736
valid_lft 永久 preferred_lft 永久
inet6 fe80::20c:29ff:fe75:1a9c/64 スコープ リンク
valid_lft 永久 preferred_lft 永久
スレーブ1ホスト:
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.141
マスターユーザー: 担当者
マスターポート: 3306
スレーブ2ホスト:
mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.141
マスターユーザー: 担当者
マスターポート: 3306
master1 ホストの mysql サービスを起動し、モニター ログを確認します。master1 のログは次のとおりです。
[root@monitor1 ~]# tail -f /var/log/mysql-mmm/mmm_mond.log
2017/01/09 22:16:56 INFO 'master1' の 'my​​sql' が正常であることを確認してください。
2017/01/09 22:16:56 INFO 'master1' の 'rep_backlog' が正常であることを確認してください。
2017/01/09 22:16:56 INFO 'master1' の 'rep_threads' が正常であることを確認してください。
2017/01/09 22:16:59 ホスト「master1」のFATAL状態がHARD_OFFLINEからAWAITING_RECOVERYに変更されました
上記から、master1 のステータスが hard_offline から awaiting_recovery に変わったことがわかります。次のコマンドを使用して、サーバーをオンラインにします。
[root@monitor1 ~]#mmm_controlset_onlinemaster1
クラスターの最新のステータスを表示する
[root@monitor1 ~]# mmm_control 表示
master1(192.168.31.83) マスター/ONLINE。役割:
master2(192.168.31.141) マスター/オンライン。役割: リーダー(192.168.31.5)、ライター(192.168.31.2)
スレーブ1(192.168.31.250) スレーブ/オンライン。役割: リーダー(192.168.31.4)
スレーブ2(192.168.31.225) スレーブ/オンライン。役割: リーダー(192.168.31.3)
既存のマスターが再びダウンするまで、マスター データベースは起動時にマスターを引き継がないことがわかります。
要約する
（１）マスター２候補マスターノードの障害はクラスターの状態に影響を与えず、マスター２候補ノードの読み取り状態のみを削除します。
（2）master1マスターノードに障害が発生した場合、master2候補マスターノードが書き込みの役割を引き継ぎます。slave1とslave2は、レプリケーションのために新しいmaster2マスターライブラリを指します。slave1とslave2は、自動的にマスターをmaster2に変更します。
（３）マスター１のマスターデータベースがクラッシュし、マスター２のレプリケーションアプリケーションがマスター１より遅れると、データはマスターによって書き込み可能になり、この時点でデータマスターは一貫性を保証できなくなります。
マスター 2、スレーブ 1、スレーブ 2 がマスター 1 より遅れ、マスター 1 がクラッシュした場合、スレーブ 1 とスレーブ 2 は、データが db1 に追いつくまで待機してから、レプリケーションのために新しいマスター ノード 2 を再ポイントします。この時点では、データ同期の一貫性は保証されません。
（4）MMM高可用性アーキテクチャを使用する場合、マスターノードとマスタースレーブノードの構成は同じであり、セキュリティをさらに向上させるために半同期を有効にするか、マルチスレッドスレーブレプリケーションにMariaDB/MySQL5.7を使用してレプリケーションパフォーマンスを向上させます。

添付ファイル:

1. ログファイル:
ログ ファイルはエラーを分析するための鍵となることが多いため、ログ ファイルを使用して問題を分析する能力が必要です。
DB側: /var/log/mysql-mmm/mmm_agentd.log
監視終了: /var/log/mysql-mmm/mmm_mond.log
2. コマンドファイル:
mmm_agentd: DBエージェントプロセスの起動ファイル
mmm_mond: 監視プロセスの起動ファイル
mmm_backup: バックアップファイル
mmm_restore: ファイルを復元する
mmm_control: 監視操作コマンドファイル
db サーバー側には mmm_agentd プログラムのみがあり、その他はモニター サーバー側にあります。
3. mmm_controlの使用
mmm_control プログラムを使用すると、クラスターの状態を監視したり、ライターを切り替えたり、オンライン/オフライン操作を設定したりすることができます。
有効なコマンドは次のとおりです。
ヘルプ - このメッセージを表示 #ヘルプ情報
ping - ping モニター #現在のクラスターに ping を実行して正常かどうかを確認します
show - ステータスを表示 # クラスターのオンラインステータスチェック
checks [<host>|all [<check>|all]] - チェックステータスを表示#監視およびチェック操作を実行する
set_online<host> - ホスト <host> をオンラインに設定する #ホストをオンラインに設定する
set_offline<host> - ホスト <host> をオフラインに設定する #ホストをオフラインに設定する
mode - 現在のモードを出力します。#現在のモードを出力します
set_active - アクティブモードに切り替えます。

set_manual - 手動モードに切り替えます。
set_passive - パッシブモードに切り替えます。
move_role [--force] <role><host> - 排他ロール <role> をホスト <host> に移動します # 指定されたホスト サーバーにライター サーバーを削除します (何をしているのかわかっている場合にのみ --force を使用してください)
set_ip<ip><host> - ip<ip> を持つロールをホスト <host> に設定します。
すべての DB サーバー クラスターのステータスを確認します。
[root@monitor1 ~]# mmm_controlはすべてをチェックします
チェック項目には、ping、mysql が正常に実行されているかどうか、レプリケーション スレッドが正常かどうかなどがあります。クラスタ環境のオンライン ステータスを確認します。
[root@monitor1 ~]# mmm_control 表示
指定されたホストでオフライン操作を実行します。
[root@monitor1 ~]# mmm_controlset_offline スレーブ2
指定されたホスト上でオンライン操作を実行します。
[root@monitor1 ~]# mmm_controlset_online スレーブ2
書き込みスイッチの実行（手動スイッチ）:
現在のスレーブに対応するマスターを表示する
[root@slave2 ~]# mysql -uroot -p123456 -e 'スレーブステータスを表示\G;'
mysql: [警告] コマンドライン インターフェイスでパスワードを使用すると安全でない可能性があります。
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.141
ライターを切り替えるには、mmm_common.conf ファイルのライター属性に対応するホストが設定されていることを確認してください。そうでない場合、切り替えを行うことはできません。
[root@monitor1 ~]# mmm_controlmove_role ライター master1
OK: ロール「writer」が「master2」から「master1」に移動されました。しばらく待って、新しいロール情報を確認してください。
[root@monitor1 ~]# mmm_control 表示
マスター1(192.168.31.83) マスター/オンライン。役割: ライター(192.168.31.2)
マスター2(192.168.31.141) マスター/オンライン。役割: リーダー(192.168.31.5)
スレーブ1(192.168.31.250) スレーブ/オンライン。役割: リーダー(192.168.31.4)
スレーブ2(192.168.31.225) スレーブ/オンライン。役割: リーダー(192.168.31.3)
セーブスレーブは自動的に新しいマスターに切り替わりました
[root@slave2 ~]# mysql -uroot -p123456 -e 'スレーブステータスを表示\G;'
mysql: [警告] コマンドライン インターフェイスでパスワードを使用すると安全でない可能性があります。
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.31.83

4. その他の処理上の問題

ライターをマスターからバックアップに切り替えたくない場合は（ライター VIP の切り替えを引き起こすマスタースレーブ遅延を含む）、/etc/mysql-mmm/mmm_common.conf を構成するときに <role write> のバックアップを削除できます。
<ロール ライター>#ライター ロールの設定
hosts master1 #ここではホストが1つだけ設定されます
ips 192.168.31.2#外部書き込み操作用の仮想IP
モード排他 #排他は、マスターが1つだけ存在できることを意味します。つまり、書き込みIPは1つだけ提供できます。
</役割>
このように、master1 に障害が発生した場合、ライターの書き込み操作は master2 サーバーに切り替えられず、スレーブは新しいマスターをポイントしません。このとき、現在の MMM は外部に書き込みサービスを提供します。

5. まとめ

1. 外部からの読み取りと書き込みを提供する仮想 IP は、モニター プログラムによって制御されます。モニターが起動されていない場合、DB サーバーに仮想 IP は割り当てられません。ただし、仮想 IP が割り当てられている場合は、モニター プログラムが以前に割り当てられた仮想 IP を閉じても、すぐには閉じられず、外部プログラムは引き続き接続してアクセスできます (ネットワークが再起動されない限り)。これの利点は、モニターの信頼性要件が低くなることです。ただし、この時点で DB サーバーの 1 つに障害が発生すると、切り替えを処理できません。つまり、元の仮想 IP は変更されず、障害が発生した DB の仮想 IP にはアクセスできなくなります。

2. エージェント プログラムは、モニター プログラムによって制御され、書き込み切り替え、スレーブ切り替えなどの操作を処理します。モニター プロセスがシャットダウンされると、エージェント プロセスは単独で障害を処理できなくなります。

3. モニター プログラムは、Mysql データベース、サーバーが実行中かどうか、レプリケーション スレッドが正常かどうか、マスター スレーブの遅延など、db サーバーの状態を監視する役割を担います。また、障害を処理するエージェント プログラムを制御するためにも使用されます。

4. モニターは、数秒ごとに DB サーバーの状態を監視します。DB サーバーが障害状態から正常状態に変わった場合、モニターは 60 秒後に自動的にオンライン状態に設定します (デフォルトは 60 秒ですが、他の値に設定できます)。これは、監視側の構成ファイル パラメータ「auto_set_online」によって決定されます。クラスター サーバーには、HARD_OFFLINE→AWAITING_RECOVERY→online の 3 つの状態があります。
5. デフォルトでは、モニターは mmm_agent を制御して、ライター DB サーバーの read_only をオフにし、他の DB サーバーの read_only をオンにします。したがって、厳密にするために、すべてのサーバーの my.cnf ファイルに read_only=1 を追加して、ライターを制御し、モニターによって読み取ることができます。ルート ユーザーとレプリケーション ユーザーは、read_only パラメータの影響を受けません。