MySQL で MHA アーキテクチャのデプロイメントを構築する手順

MySQL で MHA アーキテクチャのデプロイメントを構築する手順

マハ

1. MAHアーキテクチャの概要

  • MHA (Master High Availability) は現在、MySQL の高可用性のための比較的成熟したソリューションです。これは日本の youshimaton によって開発され、MySQL の高可用性環境でのフェイルオーバーやマスタースレーブ昇格のための優れた高可用性ソフトウェアです。 MySQL フェイルオーバー プロセス中、MHA は 0 ～ 30 秒以内にデータベース フェイルオーバー操作を自動的に完了し、フェイルオーバー プロセス中にデータベースの一貫性を最大限に確保して、真の高可用性を実現します。
  • MHA は、MHA マネージャー (管理ノード) と MHANode (データ ノード) の 2 つの部分で構成されます。 MHA マネージャーは、複数のマスター スレーブ クラスターを管理するために別のマシンに独立して展開することも、スレーブに展開することもできます。マスターに障害が発生した場合、最新のデータを持つスレーブを自動的に新しいマスターに昇格させ、他のすべてのスレーブを新しいマスターにリダイレクトできます。フェイルオーバー プロセス全体はアプリケーションに対して完全に透過的です。

2. 適用可能なシナリオ

現在、MHA は主に 1 つのマスターと複数のスレーブのアーキテクチャをサポートしています。MHA を構築するには、レプリケーション クラスターに少なくとも 3 つのデータベース サーバー (1 つのマスターと 2 つのスレーブ) が必要です。つまり、1 つはマスターとして機能し、1 つはスタンバイ マスターとして機能し、もう 1 つはスレーブとして機能します。コストを考慮して、Taobao はこれに基づいて変更を加えました。現在、Taobao が開発した TMHA は、マスター 1 つとスレーブ 1 つをサポートしています。

3. MHAの動作原理

1. クラッシュしたマスターからのバイナリ ログ イベントを保存します。

2. 最新のアップデートでスレーブを識別します。

3. 差分リレーログを他のスレーブに適用します。

4. マスターから保存されたバイナリ ログ イベントを適用します。

5. スレーブを新しいマスターに昇格します。

6. レプリケーションのために他のスレーブを新しいマスターに接続します。

4. MHAの構成

  • マネージャーツールキット
  • ノードツールキット

1: マネージャーツールキット

  • masterha_check_ssh: MHAのSSH設定を確認する
  • masterha_check_repl: MySQL レプリケーションステータスを確認する
  • masterha_manager: MHAを起動する
  • masterha_check_status: 現在のMHA実行ステータスを確認する
  • masterha_master_monitor: マスターがダウンしているかどうかを検出します
  • masterha_master_switch: フェイルオーバー（自動または手動）を制御します
  • masterha_conf_host: 設定されたサーバー情報を追加または削除する

2: ノードツールキット

通常はMHAマネージャースクリプトによってトリガーされ、手動操作は必要ありません。

  • save_binary_logs: マスターのバイナリログを保存してコピーします
  • apply_diff_relay_logs: 差異の中間ログ時間を識別し、他のスレーブに適用します。
  • filter_mysqlbinlog: 不要な ROOLBACK イベントを削除します (非推奨)
  • purge_relay_logs: リレーログをクリアする（SQL スレッドをブロックせずに）

5. MHAの特徴

  • 自動フェイルオーバー プロセス中、MHA はダウンしたプライマリ サーバーからバイナリ ログを保存して、データが可能な限り失われないようにします。
  • 半同期レプリケーションを使用すると、データ損失のリスクを大幅に軽減できます。
  • 現在、MHA は、最低 3 台のサーバー (つまり、1 台のマスターと 2 台のスレーブ) を備えた 1 マスター複数スレーブ アーキテクチャをサポートしています。

MHAアーキテクチャの展開

1. トポロジー図

ここに画像の説明を挿入

2: データベースのインストール

MySQL バージョン 5.6.36、cmake バージョン 2.8.6

1: コンパイル依存環境をインストールする

[root@master ~]# yum -y install ncurses-devel gcc-c++ perl-Module-Install

2. gmakeコンパイルソフトウェアをインストールする

[root@master ~]# tar zxvf cmake-2.8.6.tar.gz
[root@master ~]# cd cmake-2.8.6
[root@master cmake-2.8.6]# ./configure
[root@master cmake-2.8.6]# gmake && gmake install

3: MySQLデータベースをインストールする

[root@master ~]# tar -zxvf mysql-5.6.36.tar.gz
[root@master ~]# cd mysql-5.6.36
[root@master mysql-5.6.36]# cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql -DDEFAULT_CHARSET=utf8 -DDEFAULT_COLLATION=utf8_general_ci -DWITH_EXTRA_CHARSETS=all -DSYSCONFDIR=/etc
[root@master mysql-5.6.36]# make && make install
[root@master mysql-5.6.36]# cp サポートファイル/my-default.cnf /etc/my.cnf
[root@master mysql-5.6.36]# cp サポートファイル/mysql.server /etc/rc.d/init.d/mysqld
[root@master ~]# chmod +x /etc/rc.d/init.d/mysqld
[root@master ~]# chkconfig --add mysqld
[root@master ~]# echo "PATH=$PATH:/usr/local/mysql/bin" >> /etc/profile
[root@master ~]# ソース /etc/profile
chown -R mysql.mysql /usr/local/mysql グループ追加 mysql
[root@master ~]# useradd -M -s /sbin/nologin mysql -g mysql
[root@master ~]# chown -R mysql.mysql /usr/local/mysql
[root@master ~]# mkdir -p /data/mysql
[root@master ~]# /usr/local/mysql/scripts/mysql_install_db --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql

4: マスターのメイン設定ファイル /etc/my.cnf ファイルを変更する

元の設定をすべて削除する

[root@master ~]# vi /etc/my.cnf
[クライアント]
ポート = 3306
ソケット = /usr/local/mysql/mysql.sock

[mysql]
ポート = 3306
ソケット = /usr/local/mysql/mysql.sock

[mysqld]
ユーザー = mysql
ベースディレクトリ = /usr/local/mysql
データディレクトリ = /usr/local/mysql/data
ポート = 3306
pid ファイル = /usr/local/mysql/mysqld.pid
ソケット = /usr/local/mysql/mysql.sock
サーバーID = 1
log_bin = マスタービン
ログスレーブ更新 = true

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

他の2つのスレーブデータベース

3つのサーバーのサーバーIDは同じにすることはできませんが、他のサーバーは同じであり、通常どおりに記述できます。

サーバーID = 2
log_bin = マスタービン
リレーログ = リレーログビン 
リレーログインデックス = スレーブリレービンインデックス
サーバーID = 3
log_bin = マスタービン
リレーログ = リレーログビン 
リレーログインデックス = スレーブリレービンインデックス

5: 3 つのデータベースごとに 2 つのソフト リンクを作成します。ソフト リンクは HMA サービス用です。

[root@master ~]# ln -s /usr/local/mysql/bin/mysql /usr/sbin/
[root@master ~]# ln -s /usr/local/mysql/bin/mysqlbinlog /usr/sbin/

6: 3つのデータベースでMySQLを起動する

[root@master ~]# /usr/local/mysql/bin/mysqld_safe --user=mysql &
[root@master ~]# サービスmysqldを再起動します 
MySQL をシャットダウンしています。成功しました。 
MySQL を起動しています。成功しました!

3: データベース構成のマスタースレーブ同期

データベースにログイン

[ルート@マスター ~]#mysql

1: すべてのデータベースノードで2人のユーザーを承認します。1人はスレーブ同期用、もう1人はマネージャー使用用です。

mysql> '123' で識別される 'myslave'@'20.0.0.%' に *.* 上のレプリケーション スレーブを許可します。
mysql> 'manager' によって識別される 'mha'@'20.0.0.%' に *.* のすべての権限を付与します。
mysql> 権限をフラッシュします。

2: 理論上、以下の 3 つの権限を追加する必要はありません。ただし、ケース実験環境を実行する際に、MHA 経由で MySQL マスタースレーブをチェックすると、2 つのスレーブデータベースがホスト名経由でマスターデータベースに接続できないというエラーが報告されたため、すべてのデータベースに以下の権限を追加しました。

mysql> 'manager' によって識別される 'mha'@'master' に *.* のすべての権限を付与します。
mysql> 'manager' によって識別される 'mha'@'slave1' に *.* のすべての権限を付与します。
mysql> 'manager' によって識別される 'mha'@'slave2' に *.* のすべての権限を付与します。

3: マスターホスト上のバイナリファイルと同期ポイントを表示する

mysql> マスターステータスを表示します。
+-------------------+----------+--------------+------------------+------------------+
| ファイル | 位置 | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+------------------+
| マスターbin.000001 | 608 | | | |
+-------------------+----------+--------------+------------------+------------------+
セット内の 1 行 (0.00 秒)

4: スレーブ1とスレーブ2でそれぞれ同期を実行する

mysql> マスターを master_host='20.0.0.10'、master_user='myslave'、master_password='123'、master_log_file='master-bin.000001'、master_log_pos=608 に変更します
mysql> スレーブを起動します。

5: IO スレッドと SQL スレッドの両方が「はい」であるかどうかを確認し、同期が正常かどうかを示します。

mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
    Slave_IO_State: マスターがイベントを送信するのを待機中
     マスターホスト: 20.0.0.10
     マスターユーザー: myslave
     マスターポート: 3306
    接続再試行: 60
    マスターログファイル: master-bin.000001
   読み取りマスターログ位置: 608
    リレーログファイル: リレーログbin.000002
    リレーログ位置: 284
  リレーマスターログファイル: master-bin.000001
    スレーブIO実行中: はい
   スレーブSQL実行中: はい
    レプリケート_Do_DB: 
   レプリケート_無視_DB:

両方のスレーブを読み取り専用モードに設定する必要があります

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

6: 2つのデータをマスターデータベースに挿入して、同期されているかどうかをテストします。

mysql> データベース test_db を作成します。
クエリは正常、1 行が影響を受けました (0.00 秒)
mysql> test_db を使用します。
データベースが変更されました
mysql> テーブル test(id int) を作成します。
クエリは正常、影響を受けた行は 0 行 (0.13 秒)
mysql> test(id) 値に挿入します (1);
クエリは正常、1 行が影響を受けました (0.03 秒)

7: 以下に示すように、2つのスレーブライブラリを個別にクエリし、マスタースレーブ同期が正常であることを示します。

mysql> test_db.test から * を選択します。
+------+
|id|
+------+
| 1 |
+------+
セット内の 1 行 (0.00 秒)

4: MHAソフトウェアをインストールする

1: すべてのサーバーにMHA依存環境をインストールします。まずepelソースをインストールします（3+1）

[root@master ~]# cd /etc/yum.repos.d/
[root@master yum.repos.d]# ll
総投与量20
drwxr-xr-x. 2 ルート ルート 187 10月10日 18:08 バックアップ
-rw-r--r--。1 ルート ルート 1458 12月28日 23:07 CentOS7-Base-163.repo
-rw-r--r--。1 ルート ルート 951 12月 29日 14:52 epel.repo
-rw-r--r--。1 ルート ルート 1050 11月1日 04:33 epel.repo.rpmnew
-rw-r--r--。1 ルート ルート 1149 11月 1日 04:33 epel-testing.repo
-rw-r--r--。1 ルート ルート 228 10月27日 18:43 local.repo

3 つのデータベースと 1 つの mha-manager

[root@mha-manager ~]# yum install epel-release --nogpgcheck
[root@mha-manager ~]# yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-ParalExtUtils-CBuilder perl-ExtUtils-MakeMaker perl-CPAN

2: ノードコンポーネント（3+1）をまずすべてのサーバーにインストールする必要があります

[root@mha-manager ~]# tar zxvf mha4mysql-node-0.57.tar.gz
[root@mha-manager ~]# cd mha4mysql-node-0.57
[root@mha-manager mha4mysql-node-0.57]# perl Makefile.PL
[root@mha-manager mha4mysql-node-0.57]# make && make install

3: mha-managerにマネージャーコンポーネントをインストールする

[root@mha-manager ~]# tar zxvf mha4mysql-manager-0.57.tar.gz 
[root@mha-manager ~]# cd mha4mysql-manager-0.57/
[root@mha-manager mha4mysql-manager-0.57]# perl Makefile.PL
[root@mha-manager mha4mysql-manager-0.57]# make && make install

マネージャーがインストールされると、/usr/local/binの下にいくつかのツールが生成されます。

ここに画像の説明を挿入

masterha_check_ssh MHAのSSH設定を確認する
masterha_check_repl MySQLレプリケーションステータスを確認する
masterha_mangerはマネージャースクリプトを起動します
masterha_check_statusは現在のMHAの実行ステータスをチェックします
masterha_master_monitorはマスターがダウンしているかどうかを検出します
masterha_master_switch はフェイルオーバー（自動または手動）を制御します
masterha_conf_hostは設定されたサーバー情報を追加または削除します
masterha_stopはマネージャーをシャットダウンします

ノードがインストールされると、/usr/local/binの下にいくつかのスクリプトが生成されます。

ここに画像の説明を挿入

save_binary_logsはマスターのバイナリログを保存してコピーします

apply_diff_relay_logs は差分リレーログイベントを識別し、差分イベントを他のスレーブに適用します。

filter_mysqlbinlog は不要な ROLLBACK イベントを削除します (MHA はこのツールを使用しなくなりました)

purge_relay_logs リレーログをクリアします（SQL スレッドをブロックしません）

5: パスワードレス認証を構成する

1: マネージャー上のすべてのノードにパスワードなしの認証を設定する

（１）キーを生成する

[root@mha-manager ~]# ssh-keygen -t rsa # Enterキーを押し続けます

（２）キーが生成されると、他の３つのデータベースに送信される。

[root@mha-manager ~]# ssh-copy-id 20.0.0.10 # 入力: yes パスワード: 123456
[root@mha-manager ~]# ssh-copy-id 20.0.0.11
[root@mha-manager ~]# ssh-copy-id 20.0.0.12

（３）ログインテスト

[root@mha-manager ~]# ssh [email protected]
最終ログイン: 2020年12月29日火曜日 14:52:09 20.0.0.1から
[root@master ~]# 終了
20.0.0.10 へのログアウト接続が閉じられました。
[root@mha-manager ~]# ssh [email protected]
最終ログイン: 2020年12月29日火曜日 13:20:07 20.0.0.1から
[root@slave1 ~]# 終了
20.0.0.11 へのログアウト接続が閉じられました。
[root@mha-manager ~]# ssh [email protected]
最終ログイン: 2020年10月27日火曜日 19:45:24 20.0.0.1から
[root@slave2 ~]# 終了
20.0.0.12 へのログアウト接続が閉じられました。

2: マスター上のデータベースノードへのパスワードフリー認証を構成する

（１）キーを生成する

[root@master ~]# ssh-keygen -t rsa

（２）キーが生成されると、他の２つのデータベースに送信される。

[root@master ~]# ssh-copy-id 20.0.0.11
[root@master ~]# ssh-copy-id 20.0.0.12

（３）ログインテスト

[root@master ~]# ssh [email protected]
最終ログイン: 2020年12月29日火曜日 16:40:06 20.0.0.13から
[root@slave1 ~]# 終了
20.0.0.11 へのログアウト接続が閉じられました。
[root@master ~]# ssh [email protected]
最終ログイン: 2020年10月27日火曜日 23:05:20 20.0.0.13から
[root@slave2 ~]# 終了
20.0.0.12 へのログアウト接続が閉じられました。

3: スレーブ1のデータベースノードへのパスワードフリー認証を構成する

（１）キーを生成する

[root@slave1 ~]# ssh-keygen -t rsa

（２）キーが生成されると、他の２つのデータベースに送信される。

[root@slave1 ~]# ssh-copy-id 20.0.0.10
[root@slave1 ~]# ssh-copy-id 20.0.0.12

（３）ログインテスト

[root@slave1 ~]# ssh [email protected]
最終ログイン: 2020年12月29日火曜日 16:39:55 20.0.0.13から
[root@master ~]# 終了
20.0.0.10 へのログアウト接続が閉じられました。
[root@slave1 ~]# ssh [email protected]
最終ログイン: 2020年10月27日火曜日 23:14:06 20.0.0.10から
[root@slave2 ~]# 終了
20.0.0.12 へのログアウト接続が閉じられました。

4: スレーブ2のデータベースノードへのパスワードフリー認証を構成する

（１）キーを生成する

[root@slave2 ~]# ssh-keygen -t rsa

（２）キーが生成されると、他の２つのデータベースに送信される。

[root@slave2 ~]# ssh-copy-id 20.0.0.10
[root@slave2 ~]# ssh-copy-id 20.0.0.11

（３）ログインテスト

[root@slave2 ~]# ssh [email protected]
最終ログイン: 2020年12月29日火曜日 16:59:43 20.0.0.11から
[root@master ~]# 終了
20.0.0.10 へのログアウト接続が閉じられました。
[root@slave2 ~]# ssh [email protected]
最終ログイン: 2020年12月29日火曜日 16:48:51 20.0.0.10から
[root@slave1 ~]# 終了
20.0.0.11 へのログアウト接続が閉じられました。

6. MHAを構成する

1: 関連するスクリプトをマネージャーノードの/usr/local/binディレクトリにコピーします。

（１）コピー

[root@mha-manager ~]# cp -ra /root/mha4mysql-manager-0.57/samples/scripts/ /usr/local/bin/

（２）コピー後、４つの実行ファイルができる。

ここに画像の説明を挿入

master_ip_failover #自動切り替え時の VIP 管理用スクリプト

master_ip_online_change #オンライン切り替え時の VIP 管理

power_manager #障害発生後にホストをシャットダウンするスクリプト

send_report #フェイルオーバー後にアラームを送信するスクリプト

（３）上記の自動切り替えVIP管理スクリプトを/usr/local/binディレクトリにコピーします。ここで、スクリプトはVIPを管理するために使用されます。

[root@mha-manager スクリプト]# cp master_ip_failover /usr/local/bin/
[root@mha-manager スクリプト]# cd ..
[root@mha-manager bin]# ll
総投与量 88

ここに画像の説明を挿入

2: 自動切り替えスクリプトを変更する

[root@mha-manager ~]# vi /usr/local/bin/master_ip_failover # すべての内容を削除 #!/usr/bin/env perl
厳密なものを使用します。
警告 FATAL => 'all' を使用します。

Getopt::Long を使用します。

私の
$コマンド、$ssh_user、$orig_master_host、$orig_master_ip、
$orig_master_port、$new_master_host、$new_master_ip、$new_master_port
);
##################################コンテンツ セクションを追加##########################################
私の$vip = '20.0.0.200';
私の$brdc = '20.0.0.255';
私の$ifdev = 'ens33';
私の$key = '1';
私の$ssh_start_vip = "/sbin/ifconfig ens33:$key $vip";
私の $ssh_stop_vip = "/sbin/ifconfig ens33:$key がダウンしています";
私の$exit_code = 0;
#my $ssh_start_vip = "/usr/sbin/ip addr $vip/24 brd $brdc dev $ifdev label $ifdev:$key;/usr/sbin/arping -q -A -c 1 -I $ifdev $vip;iptables -F;";
#my $ssh_stop_vip = "/usr/sbin/ip アドレス del $vip/24 dev $ifdev ラベル $ifdev:$key";
##################################################################################
オプションを取得(
'command=s' => \$command,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,
'orig_master_port=i' => \$orig_master_port,
'new_master_host=s' => \$new_master_host,
'new_master_ip=s' => \$new_master_ip,
'新しいマスターポート=i' => \$新しいマスターポート、
);

&main() を終了します。

サブメイン{

print "\n\nスクリプトテストで====$ssh_stop_vip==$ssh_start_vip===\n\n";

$command が "stop" の場合 || $command が "stopssh" の場合 {

私の$exit_code = 1;
評価 {
print "古いマスターの VIP を無効にしています: $orig_master_host \n";
&stop_vip();
$終了コード = 0;
};
もし（$@）{
warn "エラーが発生しました: $@\n";
終了 $exit_code;
}
終了 $exit_code;
}
elsif ( $command が "start" と等しい ) {

私の$exit_code = 10;
評価 {
print "新しいマスター $new_master_host で VIP $vip を有効にしています \n";
開始vip();
$終了コード = 0;
};
もし（$@）{
警告 $@;
終了 $exit_code;
}
終了 $exit_code;
}
elsif ( $command が "ステータス" と等しい ) {
print "スクリプトのステータスを確認しています。OK \n";
終了0;
}
それ以外 {
＆使用法（）;
出口1;
}
}
サブstart_vip() {
`ssh $ssh_user\@$new_master_host \" $ssh_start_vip \"`;
}
# old_master 上の VIP を無効にする単純なシステムコール
サブstop_vip() {
`ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \"`;
}

サブの使用法 {
印刷
"使用方法: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --orig_master_port=port --new_master_host=host --new_master_ip=ip --new_master_port=port\n";
}

3: MHAソフトウェアディレクトリを作成し、構成ファイルをコピーする

[root@mha-manager ~]# mkdir /etc/mha
[root@mha-manager ~]# cp mha4mysql-manager-0.57/samples/conf/app1.cnf /etc/mha
[root@mha-manager ~]# vi /etc/mha/app1.cnf
[サーバーのデフォルト]
マネージャーワークディレクトリ=/var/log/masterha/app1
マネージャログ=/var/log/masterha/app1/manager.log
マスター_binlog_dir=/usr/local/mysql/data
マスターIPフェイルオーバースクリプト=/usr/local/bin/マスターIPフェイルオーバー
マスターIPオンライン変更スクリプト=/usr/local/bin/マスターIPオンライン変更
パスワード=マネージャー
ユーザー=mha
ping_interval=1
リモートワークディレクトリ=/tmp
パスワードを123に変更
repl_user=myslave
セカンダリチェックスクリプト = /usr/local/bin/masterha_secondary_check -s 20.0.0.11 -s 20.0.0.12
シャットダウンスクリプト=""
ssh_user=ルート

[サーバー1]
ホスト名=20.0.0.10
ポート=3306
[サーバー2]
ホスト名=20.0.0.11
ポート=3306
候補マスター=1
チェック_repl_delay=0
[サーバー3]
ホスト名=20.0.0.12
ポート=3306

7. 健康チェック

1: ssh パスワードレス認証をテストします。正常であれば正常に出力されます。

[root@mha-manager ~]# masterha_check_ssh
--conf=<server_config_file> を設定する必要があります。
[root@mha-manager ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf
2020 年 12 月 29 日火曜日 20:19:16 - [警告] グローバル構成ファイル /etc/masterha_default.cnf が見つかりません。スキップします。
2020 年 12 月 29 日火曜日 20:19:16 - [info] /etc/mha/app1.cnf からアプリケーションのデフォルト設定を読み取っています。
2020 年 12 月 29 日火曜日 20:19:16 - [情報] /etc/mha/app1.cnf からサーバー構成を読み取っています。
2020 年 12 月 29 日火曜日 20:19:16 - [情報] SSH 接続テストを開始しています。
2020年12月29日火曜日 20:19:17 - [デバッグ] 
2020 年 12 月 29 日火曜日 20:19:16 - [デバッグ] [email protected](20.0.0.10:22) から [email protected](20.0.0.11:22) に SSH 経由で接続しています。
2020年12月29日火曜日 20:19:16 - [デバッグ] 正常です。
2020 年 12 月 29 日火曜日 20:19:16 - [デバッグ] [email protected](20.0.0.10:22) から [email protected](20.0.0.12:22) に SSH 経由で接続しています。
2020年12月29日火曜日 20:19:17 - [デバッグ] 正常です。
2020年12月29日火曜日 20:19:18 - [デバッグ] 
2020 年 12 月 29 日火曜日 20:19:17 - [デバッグ] [email protected](20.0.0.12:22) から [email protected](20.0.0.10:22) に SSH 経由で接続しています。
2020年12月29日火曜日 20:19:17 - [デバッグ] 正常です。
2020 年 12 月 29 日火曜日 20:19:17 - [デバッグ] [email protected](20.0.0.12:22) から [email protected](20.0.0.11:22) に SSH 経由で接続しています。
2020年12月29日火曜日 20:19:18 - [デバッグ] 正常です。
2020年12月29日火曜日 20:19:18 - [デバッグ] 
2020 年 12 月 29 日火曜日 20:19:16 - [デバッグ] [email protected](20.0.0.11:22) から [email protected](20.0.0.10:22) に SSH 経由で接続しています。
2020年12月29日火曜日 20:19:17 - [デバッグ] 正常です。
2020 年 12 月 29 日火曜日 20:19:17 - [デバッグ] [email protected](20.0.0.11:22) から [email protected](20.0.0.12:22) に SSH 経由で接続しています。
2020年12月29日火曜日 20:19:17 - [デバッグ] 正常です。
2020 年 12 月 29 日火曜日 20:19:18 - [情報] すべての SSH 接続テストが正常に合格しました。

2: MySQL マスター/スレーブ接続をテストします。最後に、「MySQL レプリケーションの健全性は正常です」というメッセージが表示されます。

[root@mha-manager ~]# masterha_check_repl --conf=/etc/mha/app1.cnf
2020 年 12 月 29 日火曜日 20:30:29 - [警告] グローバル構成ファイル /etc/masterha_default.cnf が見つかりません。スキップします。
2020 年 12 月 29 日火曜日 20:30:29 - [info] /etc/mha/app1.cnf からアプリケーションのデフォルト構成を読み取っています。
2020 年 12 月 29 日火曜日 20:30:29 - [情報] /etc/mha/app1.cnf からサーバー構成を読み取っています。
2020 年 12 月 29 日火曜日 20:30:29 - [情報] MHA::MasterMonitor バージョン 0.57。
2020 年 12 月 29 日火曜日 20:30:30 - [情報] GTID フェイルオーバー モード = 0
2020年12月29日火曜日 20:30:30 - [情報] デッドサーバー:
2020年12月29日火曜日 20:30:30 - [情報] 稼働中のサーバー:
2020 年 12 月 29 日火曜日 20:30:30 - [情報] 20.0.0.10 (20.0.0.10:3306)
2020年12月29日火曜日 20:30:30 - [情報] 20.0.0.11(20.0.0.11:3306)
2020 年 12 月 29 日火曜日 20:30:30 - [情報] 20.0.0.12 (20.0.0.12:3306)
2020年12月29日火曜日 20:30:30 - [情報] 生きた奴隷:
2020 年 12 月 29 日火曜日 20:30:30 - [情報] 20.0.0.11(20.0.0.11:3306) バージョン = 5.6.36-log (スレーブ間の最も古いメジャー バージョン) log-bin: 有効
.......省略スクリプトのステータスを確認しています..OK 
2020年12月29日火曜日 20:30:55 - [情報] OK。
2020 年 12 月 29 日火曜日 20:30:55 - [警告] Shutdown_script が定義されていません。
2020 年 12 月 29 日火曜日 20:30:55 - [情報] 終了コード 0 を取得しました (マスターは死んでいません)。

MySQL レプリケーションの健全性は正常です。

8: マスター1のVIPアドレスを表示する

20.0.0.200が存在するか確認する

このVIPアドレスは、マネージャーノードがMHAサービスを停止しても消えません。

mha を初めて起動すると、マスター データベースは VIP アドレスを自動的に生成しないため、手動で有効にする必要があります。

[root@master ~]# ifconfig ens33:1 20.0.0.200/24 ​​アップ
[root@master ~]# IPアドレス
2: ens33: <BROADCAST、MULTICAST、UP、LOWER_UP> mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000
 リンク/イーサ 00:0c:29:8d:e2:af brd ff:ff:ff:ff:ff:ff
 inet 20.0.0.10/24 brd 20.0.0.255 スコープ グローバル ens33
  valid_lft 永久 preferred_lft 永久
 inet 20.0.0.200/24 brd 20.0.0.255 スコープ グローバル セカンダリ ens33:1
  valid_lft 永久 preferred_lft 永久
 inet6 fe80::a6c1:f3d4:160:102a/64 スコープ リンク 
  valid_lft 永久 preferred_lft 永久

9. MHAを起動してステータスを確認する

[root@mha-manager ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
[1] 57152
[root@mha-manager ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:57152) が実行中です(0:PING_OK)、マスター:20.0.0.10

障害シミュレーションと修復

1. 故障シミュレーション

1: マスターサーバーをシャットダウンする

[root@master ~]# pkill mysqld

2: ログ情報を表示する

[root@mha-manager ~]# cat /var/log/masterha/app1/manager.log

master 20.0.0.10(20.0.0.10:3306) がダウンしています。 # 20.0.0.10 がダウンしています。詳細については、mha-manager:/var/log/masterha/app1/manager.log にある MHA マネージャー ログを確認してください。

自動(非対話型)フェイルオーバーを開始しました。
20.0.0.10(20.0.0.10:3306) のマスター IP アドレスが無効になりました
最新のスレーブ 20.0.0.11 (20.0.0.11:3306) には、リカバリ用のすべてのリレー ログがあります。
20.0.0.11(20.0.0.11:3306) を新しいマスターとして選択しました。# 20.0.0.11 がプライマリ サーバーになります 20.0.0.11(20.0.0.11:3306): OK: すべてのログの適用に成功しました。
20.0.0.11(20.0.0.11:3306): OK: マスター IP アドレスがアクティブ化されました。
20.0.0.12(20.0.0.12:3306): このホストには最新のリレー ログ イベントがあります。
最新のスレーブからのリレー diff ファイルの生成に成功しました。

3: 仮想アドレスを表示する

仮想アドレスが20.0.0.11に到達しました

[root@slave1 ~]# IPアドレス
2: ens33: <BROADCAST、MULTICAST、UP、LOWER_UP> mtu 1500 qdisc pfifo_fast 状態 UP qlen 1000
 リンク/イーサ 00:0c:29:49:77:39 brd ff:ff:ff:ff:ff:ff
 inet 20.0.0.11/24 brd 20.0.0.255 スコープ グローバル ens33
  valid_lft 永久 preferred_lft 永久
 inet 20.0.0.200/8 brd 20.255.255.255 スコープ グローバル ens33:1
  valid_lft 永久 preferred_lft 永久
 inet6 fe80::5cbb:1621:4281:3b24/64 スコープ リンク 
  valid_lft 永久 preferred_lft 永久

4: マスタースレーブステータスを確認する

マスターサーバーのバイナリファイルを表示する

[root@slave1 ~]# mysql

mysql> マスターステータスを表示します。
+-------------------+----------+--------------+------------------+------------------+
| ファイル | 位置 | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+------------------+
| マスターbin.000003 | 120 | | | |
+-------------------+----------+--------------+------------------+------------------+
セット内の 1 行 (0.00 秒)

2からステータスを表示

[root@slave2 ~]# mysql

mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
    Slave_IO_State: マスターがイベントを送信するのを待機中
     マスターホスト: 20.0.0.11
     マスターユーザー: myslave
     マスターポート: 3306
    接続再試行: 60
    マスターログファイル: master-bin.000003
   読み取りマスターログ位置: 120
    リレーログファイル: リレーログbin.000002
    リレーログ位置: 284
  リレーマスターログファイル: master-bin.000003
    スレーブIO実行中: はい
   スレーブSQL実行中: はい
    レプリケート_Do_DB: 
   レプリケート_無視_DB:

2. トラブルシューティング

1: ダウンデータベースを開く

[root@master ~]# systemctl mysqldを起動します
[root@master ~]# systemctl ステータス mysqld
● mysqld.service - LSB: MySQL の起動と停止
 ロード済み: ロード済み (/etc/rc.d/init.d/mysqld; 不良; ベンダープリセット: 無効)
 アクティブ: 2020-12-29 21:50:03 CST からアクティブ (実行中)、25 秒前
  ドキュメント: man:systemd-sysv-generator(8)
 プロセス: 977 ExecStart=/etc/rc.d/init.d/mysqld 開始 (コード=終了、ステータス=0/成功)
 Cグループ: /system.slice/mysqld.service
   ├─1026 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/usr/local/mysql/data --pid-file...
   └─1358 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/m

2: ダウンしたデータベースでマスタースレーブレプリケーションを実行する

マスタースレーブレプリケーション

[ルート@マスター ~]#mysql

mysql> マスターを master_host='20.0.0.11'、master_user='myslave'、master_password='123'、master_log_file='master-bin.000003'、master_log_pos=120 に変更します。 
クエリは正常、影響を受けた行は 0 行、警告は 2 件 (0.01 秒)
# マスター サーバーがダウンした後は、20.0.0.11 がマスター サーバーになります。mysql> start slave;
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

ステータスを表示

mysql> スレーブステータスを表示します\G;
************************** 1. 行 ****************************
    Slave_IO_State: マスターがイベントを送信するのを待機中
     マスターホスト: 20.0.0.11
     マスターユーザー: myslave
     マスターポート: 3306
    接続再試行: 60
    マスターログファイル: master-bin.000003
   読み取りマスターログ位置: 120
    リレーログファイル:mysqld-relay-bin.000002
    リレーログ位置: 284
  リレーマスターログファイル: master-bin.000003
    スレーブIO実行中: はい
   スレーブSQL実行中: はい
    レプリケート_Do_DB: 
   レプリケート_無視_DB:

3: mha設定ファイルを変更する

[root@mha-manager ~]# vi /etc/mha/app1.cnf

セカンダリチェックスクリプト=/usr/local/bin/masterha_secondary_check -s 20.0.0.10 -s 20.0.0.12
# 20.0.0.11 はマスターサーバーなので、20.0.0.10 と 20.0.0.12 をスレーブサーバーとして追加する必要があります [server1]
ホスト名=20.0.0.10
候補マスター=1
チェック_repl_delay=0
ポート=3306
[サーバー2]
ホスト名=20.0.0.11
ポート=3306
# 20.0.0.10 がダウンしているため、server1 ファイルは自動的に削除されます。server1 を再度追加し、バックアッププライマリサーバーとして設定します。server2 を変更します

4: データベースに入り、再認証する

[ルート@マスター ~]#mysql

mysql> 'manager' によって識別される 'mha'@'master' に *.* のすべての権限を付与します。
クエリは正常、影響を受けた行は 0 行 (0.00 秒)

mysql> 権限をフラッシュします。
クエリは正常、影響を受けた行は 0 行 (0.00 秒)

5: mhaを再度起動する

[root@mha-manager ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover < /dev/null > /var/log/masterha/app1/manager.log 2>&1 &
[1] 58927
[root@mha-manager ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:58927) が実行中(0:PING_OK)、マスター:20.0.0.11

6: ログを再度確認する

[root@mha-manager ~]# cat /var/log/masterha/app1/manager.log
......
2020 年 12 月 29 日火曜日 22:16:53 - [情報] 停止サーバー: # 停止したサービス2020 年 12 月 29 日火曜日 22:16:53 - [情報] 稼働サーバー: # 存続中のサービス2020 年 12 月 29 日火曜日 22:16:53 - [情報] 20.0.0.10(20.0.0.10:3306)
2020年12月29日火曜日 22:16:53 - [情報] 20.0.0.11(20.0.0.11:3306)
2020年12月29日火曜日 22:16:53 - [情報] 20.0.0.12 (20.0.0.12:3306)
.......

7: プライマリデータベースに書き込まれたデータを同期して表示する

他のデータベースは

mysql> データベース ooo を作成します。
クエリは正常、1 行が影響を受けました (0.00 秒)

mysql> データベースを表示します。
+--------------------+
| データベース |
+--------------------+
| 情報スキーマ |
|mysql |
|おおおお|
| パフォーマンススキーマ |
| テスト |
| テストデータベース |
+--------------------+
セット内の 6 行 (0.00 秒)

これで、MySQL で MHA アーキテクチャ デプロイメントを構築する手順に関するこの記事は終了です。MySQL で MHA アーキテクチャ デプロイメントを構築する方法に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • Python を使用して MySQL MHA の展開と操作ステータス情報を収集する方法
  • MySQL の高可用性アーキテクチャの完全な説明: MHA アーキテクチャ
  • MySQL MHA の高可用性構成とフェイルオーバーの詳細な導入手順
  • MySQL MHA のセットアップと切り替えに関するいくつかのエラー ログの概要
  • Mysql GTID Mha 設定方法
  • MySQL での MHA 高可用性フェイルオーバー ソリューションのスーパー デプロイメント チュートリアル
  • MHAはMySQLマスタースレーブデータベースの手動切り替えを実装します
  • MySQL MHA 操作ステータス監視の概要

<<:  W3C チュートリアル (8): W3C XML スキーマのアクティビティ

>>:  Vueのシンプルストアの詳しい説明

推薦する

AngularでTweenMaxアニメーションライブラリを使用する際の問題と解決策

最近何もすることがないのでCSSをいじっていますより良いアニメーションライブラリTweenMaxを見...

Dockerボリュームのファイルマッピング方法

背景ブロックチェーン ログ モジュールで作業しているときに、コンテナーが実行されている場合は、ログ ...

MySQL 8で追加された3つの新しいインデックスは、非表示、降順、関数です。

目次MySQL 8 の隠しインデックス、降順インデックス、関数インデックス1. 隠しインデックス1....

HTML割引価格計算の実装原理とスクリプトコード

コードをコピーコードは次のとおりです。 <!DOCTYPE HTML PUBLIC "...

Windows での Tomcat サーバーのインストールに関するチュートリアル

1 ダウンロードして準備するまず、公式ウェブサイトからTomcatをダウンロードする必要があります。...

MySQL データベースの大文字と小文字の区別の問題

MySQL では、データベースはデータ ディレクトリ内のディレクトリに対応します。データベース内の各...

MySQL アクティブ-アクティブ同期レプリケーションの 4 つのソリューションの詳細な説明

目次MySQLネイティブレプリケーションに基づくマスター-マスター同期ソリューションGaleraレプ...

Linux でファイル権限を変更する chmod コマンドの詳細な分析

Linux chmodコマンドを使用して、ターゲット ファイルにアクセス、読み取り、書き込み、または...

JavaScript でネットワーク速度をテストする方法

目次序文ネットワーク速度のフロントエンド判定原理のまとめ1. img を読み込むか Ajax リクエ...

JS関数のカリー化の詳細な説明

目次1. 補足知識ポイント: 関数の暗黙的な変換2. 補足知識: call/apply を使って配列...

ネイティブ JavaScript 継承方法とその長所と短所の詳細な説明

目次序文プロトタイプ継承アドバンテージ欠点コンストラクタの継承アドバンテージ欠点組み合わせ継承寄生的...

HTML で水平ナビゲーション構造を設定する方法

この記事では、主にリスト構造を使用して水平ナビゲーション構造を設定する 2 つの方法を紹介します。こ...

CSS クラスと ID の一般的な命名規則

ページの公開名: #wrapper - ページの外側の端が全体のレイアウト幅を制御します#conta...

Linux環境でよく使われるMySQLコマンドの紹介

mysql コマンドを入力します: mysql -u+(ユーザー名) -p+(パスワード) mysq...

MySQL クエリにおける LIMIT の大きなオフセットによって引き起こされるパフォーマンス低下の分析

序文MySQLクエリはselectコマンドを使用し、limitとoffsetパラメータを使用して、指...