1. MMM の概要
1. MMM とは
MMM (Master-Master Replication Manager for MySQL、MySQL Master-Master Replication Manager) は、デュアルマスターフェイルオーバーおよびデュアルマスター日常管理をサポートするスクリプトプログラムのセットです。MMMはPerl言語で開発されており、主にMySQLのマスター-マスター(デュアルマスター)レプリケーションを監視・管理しますデュアルマスターレプリケーションと呼ばれていますが、業務上同時に書き込みができるのは片方のマスターのみで、もう一方のマスターはバックアップとなります。マスターは、マスター/マスター切り替え時のスタンバイ マスターのウォームアップを高速化するための部分読み取りサービスを提供します MMM スクリプト プログラムは、一方ではフェイルオーバー機能を実現し、他方ではその内部追加機能を実現していると言えます。ツールは、複数の Slaves の読み取り負荷分散を実現することもできます。
2. 適用シナリオ
MMM は、サーバー グループ内でレプリケーション遅延が大きいサーバーの仮想 IP を自動および手動で削除する方法を提供し、同時にデータをバックアップし、2 つのノード間のデータ同期を実現します。MMM はデータの整合性を完全には保証できないため、高度なデータ整合性は必要ないが、ビジネスの可用性を最大限に確保したいシナリオに適しています。データの一貫性に対して高い要件がある企業の場合、MMM などの高可用性アーキテクチャを採用することはお勧めできません。
3. MMM の機能MMM は、Perl 言語に基づいて実装された
柔軟なスクリプトのセットであり、 mysql レプリケーションの監視とフェイルオーバー、MySQL マスター/マスター レプリケーションの構成の管理に使用されます。 4. MMM 高可用性アーキテクチャの説明
mmm_mon: 監視プロセス。すべての監視作業を担当し、すべてのノードの役割アクティビティを決定して処理します。このスクリプトはスーパーバイザ マシンで実行する必要があります。
mmm_agent: 各 MySQL サーバー上で実行されているエージェント プロセスは、監視プローブ作業を完了し、簡単なリモート サービス設定を実行します。このスクリプトは監視対象マシン上で実行する必要があります。
mmm_control: mmm_mond プロセスを管理するコマンドを提供する単純なスクリプト。
mysql-mmm の監視側は、1 つの書き込み可能な VIP と複数の読み取り可能な VIP を含む複数の仮想 IP (VIP) を提供します。監視管理を通じて、これらの IP は利用可能な MySQL にバインドされます。マシンがクラッシュすると、スーパーバイザーは VIP を移行します。別の MySQL に。
5. ユーザーと権限
監視プロセス全体で、MySQL が監視マシンのメンテナンスをサポートできるように、関連する認証ヨーグルトを MySQL に追加する必要があります。許可されたユーザーには mmm_monitor ユーザーと mmm_agent ユーザーが含まれます。MMM バックアップ ツールを使用する場合は、mmm_tools ユーザーも追加する必要があります。
2. 事例環境
1. サーバー構成
2. サーバー環境
systemctl stop firewalld && systemctl disable firewalld
setenforce 0
3 ホスト名を変更します。
hostnamectl set-hostname master1
su
マスター1 マスター2 スレーブ1 スレーブ2 モニター
3. 事例実装
1. MySQL マルチマスター、マルチスレーブアーキテクチャの構築
(1) mysql を master1、master2、slave1、slave2 ノードにインストール
(2) master1 の設定ファイルを変更
[client]
port = 3306default
-character- set=utf8
ソケット=/usr /local/mysql/mysql.sock
[mysql]
ポート = 3306
デフォルト文字セット=utf8
ソケット=/usr/local/mysql/mysql.sock
自動再ハッシュ
[mysqld]
ユーザー = mysql
basedir =/usr/local/mysql
datadir=/usr/local/mysql/data
port=3306
文字セットサーバー=utf8
pid-file=/usr/local/mysql/mysqld.pid
ソケット=/usr/local/mysql/ mysql.sock
サーバー ID= 1
ログエラー=/usr/local/mysql/data/mysql_error.log
一般_log=ON
general_log_file=/usr/local/mysql/data/mysql_general.log
throw_query_log=ON
throw_query_log_file=mysql_slow_query.log
long_query_time=5
binlog-ignore-db=mysql,information_schema
log_bin=mysql_bin
log_slave_updates=true
sync_binlog=1
innodb_flush_log_at _trx_commit=1
auto_increment_increment=2
auto_increment_offset =1
sql_mode=NO_ENGINE_SUBSTITUTION、STRICT_TRANS_TABLES、NO_AUTO_CREATE_USER、NO_AUTO_VALUE_ON_ZERO、NO_ZERO_IN_DATE、NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO、PIPES_AS_CONCAT、ANSI_QUOTES
mysqldを再起動します
systemctl で mysqld を再起動します
パラメータの説明
......
server-id = 1
#各 Mysql ホストのサーバー ID を同じにすることはできません。
log-error=/usr/local/mysql/data/mysql_error.log #エラー
ログ
general_log=ON
#一般的なクエリ ログ
general_log_file= /usr/local/mysql/data/mysql_general.log
throw_query_log=ON
#スロークエリログ
throw_query_log_file=mysql_slow_query.log
long_query_time=5
binlog-ignore-db=mysql,information_schema
#ライブラリ名を同期する必要はありません
log_bin=mysql_bin
#バイナリ ログを開く マスターとスレーブのデータ レプリケーション用
log_slave_updates=true
#マスターからデータをコピーするときにスレーブが独自のバイナリ ログに書き込むことを許可する
sync_binlog=1
#「Double 1 設定」、MySQL はバイナリ ログが書き込まれるたびにディスクに同期します
innodb_flush_log_at_trx_commit =1 #「Double 1 設定」にすると
、MySQL はトランザクションがコミットされるたびにキャッシュされたデータをログ ファイルに書き込み、ディスクにフラッシュします。
auto_increment_increment=2
#一度にインクリメントされる自動インクリメントフィールドの数
auto_increment_offset=1
#自動インクリメントフィールドの初期値
(3) 他の 3 つの mysql を変更し、サービスを再起動します。
他の 3 つのデータベース サーバーに設定ファイルをコピーし、mysql サーバーを再起動します。
注: 構成ファイル内のサーバー ID は同じにすることはできないため、変更する必要があります。
(4) マスター-マスターレプリケーションを設定し、2 つのマスターサーバーが相互に複製する
① スレーブに付与された権限を両方のマスターサーバーで実行し、スレーブサーバーで実行する必要はありません
マスター1サーバー (192.168.10.20)
mysql> *.* のレプリケーション スレーブを '123456' で識別される 'replication'@'192.168.10.%' に許可します。
mysql> フラッシュ権限;
mysql> マスターステータスを表示;
+---------------------+----------+--------------+---- ------------------+-----------------
| ファイル | ポジション | ビンログ_Do_DB | ビンログ_無視_DB | Executed_Gtid_Se
+---------------------+----------+--------------+--- -----------------------+-----------------
| mysql_bin.000001 | 1023 | | mysql,情報スキーマ |
+---------------------+----------+--------------+---- ------------------------+----------------------------
セット内の 1 行 (0.00 秒)
master2 服务器（192.168.10.30）
mysql> *.* のレプリケーション スレーブを '123456' で識別される 'replication'@'192.168.10.%' に許可します。
mysql> フラッシュ権限;
mysql> マスターステータスを表示;
+---------------------+----------+--------------+---- ------------------+-----------------
| ファイル | ポジション | ビンログ_Do_DB | ビンログ_無視_DB | Executed_Gtid_Se
+---------------------+----------+--------------+--- -----------------------+-----------------
| mysql_bin.000001 | 1023 | | mysql,情報スキーマ |
+---------------------+----------+--------------+---- ------------------------+----------------------------
1 行 (0.00 秒)
② 在master1 上構成同步
192.168.10.20
マスターを master_host='192.168.10.30'、master_user='replication'、master_password='123456'、master_log_file='mysql_bin.000001'、master_log_pos=1023; スレーブの開始;スレーブの
ステータス\Gの表示; #IO および SQL スレッドの
表示YES で、位置オフセットは正しいですか?
③ マスター 2 で同期を設定します。
192.168.10.30
マスターを master_host='192.168.10.20'、master_user='replication'、master_password='123456'、master_log_file='mysql_bin.000001'、master_log_pos=1023; スレーブの開始;スレーブの
ステータス\Gの表示; #IO および SQL スレッドの
表示はい、位置オフセットは正しいですか
(5) マスター/スレーブ レプリケーションを構成し、 2 台のスレーブ サーバーで
①のスレーブ 1 サーバーを実行します。
192.168.10.40
マスターを master_host='192.168.10.20',master_user='replication',master_password='123456',master_log_file='mysql_bin.000001',master_log_pos=1023 に変更します。
スレーブを開始します。
スレーブステータスを表示\G;
②スレーブ2サーバー
192.168.10.50
マスターを master_host='192.168.10.20',master_user='replication',master_password='123456',master_log_file='mysql_bin.000001',master_log_pos=1023 に変更します。
スレーブを開始します。
スレーブステータスを表示\G;
(6) マスターとマスターおよびマスターとスレーブの同期をテストします
。 2. MySQL-MMM をインストールして設定します。
(1) すべてのサーバーに MySQL-MMM をインストールします
。 注: ローカル ウェアハウスに上記のソフトウェアがない場合は、オンライン ソースを設定する必要がありますまず各サーバーのウェアハウスを作成します。
yum -y インストール epel-release && yum -y インストール mysql-mmm*
(2) master1 192.168.10.20で MySQL-MMM を設定する
[root@master1 ~]# cd /etc/mysql-mmm/
[root@master1 mysql-mmm]# cp mmm_common.conf mmm_common.conf.bak #
設定ファイルを変更する前に、まずバックアップを行ってください
[root@master1 mysql-mmm] # vim mmm_common.conf
active_master_role Writer
<host default>
cluster_interface ens33
pid_path /run/mysql-mmm-agent.pid
bin_path /usr/libexec/mysql-mmm/
replication_user replication
##マスター/マスターおよびマスター/スレーブ レプリケーション ユーザーを指定します。以前の
replication_password と一致するようにしてください。 replication_password 123456
Agent_user mmm_agent
##モニター エージェント プロセスのユーザー名を指定します。
Agent_password 123456
</host>
<host db1>
ip 192.168.10.20
mode master
ピア db2
##ピア セット ピア データベース
</host>
<host db2>
ip 192.168.10.30
モード マスター
ピア db1
</host>
<host db3>
ip 192.168.10.40
モード スレーブ
</host>
<host db4>
ip 192.168. 10.50
モード スレーブ
</host>
<ロール ライター>
hosts db1, db2
ips 192.168.10.200
##VIP
モード排他に書き込むように設定
#1 つのホストのみが操作モードを書き込むことができます モード
</role>
<ロール リーダー>
hosts db3, db4
ips 192.168 .10.201 、192.168.10.202
##読み取り VIP
モードのバランスを設定します
##複数のスレーブ ホストが読み取り操作モードを実行可能
</role>
(3) 設定ファイルを他の4台のホストにコピーします
設定ファイルの内容はどのホストでも同じです
scp mmm_common.conf [email protected]:/etc/mysql-mmm/
scp mmm_common.conf [email protected]:/etc/mysql-mmm/
scp mmm_common.conf [email protected]:/etc/mysql-mmm /
scp mmm_common.conf [email protected]:/etc/mysql-mmm/
(4) すべてのデータベースサーバーのエージェント設定ファイル mmm_agent.conf
master1を変更します
[root@master1 ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db1
##異なるホストに従って db1/db2/db3/db4 に変更します。デフォルト設定は db1 であるため、master1 は変更する必要がある
マスター2
[root@master2 ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
この db2
スレーブ 1
[root@slave ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
この db3
スレーブ 2
[root@slave2 ~]# vim /etc/mysql-mmm/mmm_agent.conf
include mmm_common.conf
this db4
(5) 監視監視サーバ
monitorサーバ(192.168.10.90)の監視設定ファイルmmm_mon.confを変更します。
[root@monitor ~]# vim /etc/mysql-mmm/mmm_mon.conf
include mmm_common.conf
<monitor>
ip 127.0.0.1
pid_path /run/mysql-mmm-monitor.pid
bin_path /usr/libexec/mysql-mmm
status_path /var/lib/mysql-mmm/mmmm_mond.status
ping_ips 192.168.10.20,192.168.10.30, 192.168.10.40, 192.168.10.50.50 ## すべてのデータベースサーバーの IP auto_set_online 10 ## を指定します
。自動オンライン時間 # kill_host_bin はデフォルトでは存在しませんが、 # モニターはそれが存在しないという警告をスローします。PDF ドキュメントの セクション 5.10「Kill Host # 機能」を参照してください 。
# kill_host_bin /usr/libexec/mysql-mmm/monitor/kill_host
#
</monitor>
<host default>
monitor_user mmm_monitor
##mmm_monitor のユーザー名を指定します
monitor_password 123456
##mmm_monitor のパスワードを指定します
</host>
debug 0
(6) すべてのデータベースで mmm_agent (エージェントプロセス) を認可する
すべてのデータベースで以下のステートメントを実行します
*.* のスーパー、レプリケーション クライアント、プロセスを '123456' で識別される 'mmm_agent'@'192.168.10.%' に付与します。
フラッシュ権限。
(7) *.* 上の レプリケーションクライアントに、'123456' で識別される 'mmm_monitor'@'192.168.10.%'、
フラッシュ権限を付与します。
(8)すべてのデータベースサーバーでmysql-mmm-agent
systemctl start mysql-mmm-agent.service && systemctl Enable mysql-mmm-agent.service を開始します。
(9) mysql-mmm-monitor を開始しますsystemctl start mysql-mmm-monitor.service && systemctl enable mysql-mmm-monitor.service をモニターサーバー上で実行します
(10) 監視サーバでクラスタのテストを行う
① 各ノードの状態を確認する
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割: ライター(192.168.10.200)
db2(192.168.10.30) マスター/オンライン。役割:
db3(192.168.10.40) スレーブ/オンライン。役割: リーダー(192.168.10.202)
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)
②監視機能が充実しているか確認する
[root@monitor ~]#mmm_control はすべての
db4 ping をチェックします [最終変更: 2021/11/04 16:13:20] OK
db4 mysql [最終変更: 2021/11/04 16:13:20] OK
db4 rep_threads [last変更: 2021/11/04 16:13:20] OK
db4 rep_backlog [最終変更: 2021/11/04 16:13:20] OK: バックログが null
db2 ping [最終変更: 2021/11/04 16:13 :20] OK
db2 mysql [最終変更: 2021/11/04 16:13:20] OK
db2 rep_threads [最終変更: 2021/11/04 16:13:20] OK
db2 rep_backlog [最終変更: 2021/11/ 04 16:13:20] OK: バックログは null
db3 ping [最終変更: 2021/11/04 16:13:20] OK
db3 mysql [最終変更: 2021/11/04 16:13:20] OK
db3 rep_threads [最終変更: 2021/11/04 16:13:20] OK
db3 rep_backlog [最終変更: 2021/11/04 16:13:20] OK: バックログが null
db1 ping [最終変更: 2021/11/04 16:13:20] OK
db1 mysql [最終変更: 2021/11/ 04 16:13:20] OK
db1 rep_threads [最終変更: 2021/11/04 16:13:20] OK
db1 rep_backlog [最終変更: 2021/11/04 16:13:20] OK: バックログが null
③ VIPにバインドされているホストを指定する
[root@monitor ~]#mmm_control move_role Writer db2
OK: ロール「writer」は「db1」から「db2」に移動されました。しばらく待ってから、新しい役割の情報を確認してください。
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割:
db2(192.168.10.30) マスター/オンライン。役割: ライター(192.168.10.200)
db3(192.168.10.40) スレーブ/オンライン。役割: リーダー(192.168.10.202)
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)
[root@monitor ~]#mmm_control move_role Writer db1
OK: ロール「writer」は「db2」から「db1」に移動されました。しばらく待ってから、新しい役割の情報を確認してください。
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割: ライター(192.168.10.200)
db2(192.168.10.30) マスター/オンライン。役割:
db3(192.168.10.40) スレーブ/オンライン。役割: リーダー(192.168.10.202)
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)
3. 障害テスト
(1) マスターのダウンタイムと復旧のシミュレーション
① master1 の mysql サービスを停止します。
② VIPドリフト状況を確認する
モニター
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/HARD_OFFLINE。役割:
db2(192.168.10.30) マスター/オンライン。役割: ライター(192.168.10.200)
db3(192.168.10.40) スレーブ/オンライン。役割: リーダー(192.168.10.202)
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)
VIP はマスター 2 に正常にドリフトし、マスター 1 には HARD_OFFLINE が表示されます
③master1のmysqlサービスを再起動します。
マスター1
systemctl は mysqld を起動します
master1 が回復した後、VIP はまだ master2 上にあり、master1 には転送されていません。
(2) スレーブサーバーのダウンタイムと復旧のシミュレーション
① スレーブ 1 の mysql サービスを停止します。
スレーブ1
systemctl は mysqld を停止します
② VIPドリフト状況を確認する
モニター
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割:
db2(192.168.10.30) マスター/オンライン。役割: ライター(192.168.10.200)
db3(192.168.10.40) スレーブ/HARD_OFFLINE。役割:
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)、リーダー(192.168.10.202)
スレーブ1に対応するVIPはスレーブ2に引き継がれます
③slave1のmysqlサービスを再起動します。
スレーブ1
systemctl は mysqld を起動します
④slave1が復旧したか確認する
モニター
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割:
db2(192.168.10.30) マスター/オンライン。役割: ライター(192.168.10.200)
db3(192.168.10.40) スレーブ/AWAITING_RECOVERY。役割:
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)、リーダー(192.168.10.202)
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割:
db2(192.168.10.30) マスター/オンライン。役割: ライター(192.168.10.200)
db3(192.168.10.40) スレーブ/オンライン。役割:
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)、リーダー(192.168.10.202)
[root@monitor ~]#mmm_control show
db1(192.168.10.20) マスター/オンライン。役割:
db2(192.168.10.30) マスター/オンライン。役割: ライター(192.168.10.200)
db3(192.168.10.40) スレーブ/オンライン。役割: リーダー(192.168.10.202)
db4(192.168.10.50) スレーブ/オンライン。役割: リーダー(192.168.10.201)
一定期間のハンドオーバーの後、スレーブ 1 は再び VIP を取得し、動作を継続します。
(3) クライアントテスト
① master1 サーバの監視サーバアドレスへのログインを許可する
*.* のすべてを「123456」で識別される「test」@「192.168.10.90」に許可します。
フラッシュ権限。
②監視サーバーにVIPでログインします。
yum -y install mariadb-server mariadb
systemctl start mariadb.service && systemctl enable mariadb.service
mysql -utest -p123456 -h 192.168.10.200 #ログインできれば成功です
③ クライアントはデータを作成し、同期をテストします。
モニター