コンセプト

MHA (マスター高可用性) は、現在、MysaL 高可用性のための比較的成熟したソリューションです。これは、日本の DeNA 会社の従業員 (現在は Facebook で働いています) によって開発されました。これは、MysaL 高可用性環境のための優れたフェイルオーバーソリューションのセットです。強化されたマスター/スレーブの役割を備えた可用性ソフトウェア。MysaL フェイルオーバープロセス中、MHA はデータベースのマスター/スレーブフェイルオーバー操作を 0 ～ 30 秒以内に自動的に完了できます。フェイルオーバープロセス中、MHA はデータの一貫性を最大限に確保して真の高可用性を実現します。

MHA は、MHA マネージャー (管理ノード) と MHA ノード (データノード) の 2 つの部分で構成されます。MHA マネージャーは、
独立したマシンに展開して複数のマスター/スレーブクラスターを管理することも、スレーブノードに展開することもできます。MHA ノードは、各 MysaL サーバーとマネージャーサーバーで実行されます。MHA マネージャーは、クラスター内のマスターノードを定期的に検出します。マスターに障害が発生すると、最新のデータを持つスレーブを新しいマスターに自動的に昇格させ、その後、他のすべてのスレーブが再ポイントされます。新しく昇格したマスターへ。フェールオーバープロセス全体は、アプリケーションレベルに対して完全に透過的です。
931 口頭ゼマ経典試験・口頭内容資格

MHA 自動フェイルオーバープロセス中、MHA はデータが最大限失われないようにコンテナマシンのメインサーバーからバイナリログを保存しようとしますが、この操作は確率的なものです。たとえば、プライマリサーバーハードウェアに障害が発生した場合、または ssh 経由でアクセスできない場合、MHA はバイナリログを保存できず、フェイルオーバーのみを行うため、最新のデータが失われます。MvSaL
5.5 の準同期レプリケーションを使用すると、データ損失のリスクを軽減できます。MHA は半同期レプリケーションと組み合わせることができます。1 つのスレーブのみが最新のバイナリログを受信した場合、MHA は最新のバイナリログを他のすべてのスレーブサーバーに適用できるため、すべてのノードでデータの一貫性が確保されます。

現在、MHA は主に 1 マスター、複数スレーブのアーキテクチャをサポートしています。MHA を構築するには、MysaL レプリケーションクラスターに
少なくともスレーブデータベースには少なくとも 3 台のサーバーが必要です。マシンのコストを考慮して、淘宝網もこれに基づいて変更しました。現在、淘宝網 TMHA は 1 台のマスターと 1 台のスレーブをサポートしています。なお、素早くセットアップしたい方は「MHAクイックセットアップ」を参考にしてください。そしてバイナリログ
を完了できません。
マスターの mysgld プロセスがクラッシュした後でも、切り替えは成功し、バイナリログが完了する可能性があります。

ワークフロー
(1) クラッシュしたマスターからのバイナリログイベントの保存を試行します
(2) 最新のアップデートを適用したスレーブサーバーを特定します:
(3) 差分リレーログを他のスレーブに適用します。
(4) 保存されたバイナリログイベント (binlog イベント) を適用します。マスターから;
(5) スレーブを新しいマスターサーバーに昇格します:
(6) マスター/スレーブレプリケーションのために他のスレーブ接続を新しいマスターにポイントします:

MHA ソフトウェアは、マネージャーツールキットとノードツールキットの 2 つの部分で構成されており、具体的な手順は次のとおりです。

Manager ツールキットには主に次のツールが含まれています。

masterha_check_ssh MHA の SSH 設定ステータスを確認する
masterha_check_rep MysQL レプリケーションステータスを確認する
masterha_manger MHA を開始する
masterha_check_status 現在の MHA 実行ステータスを確認する
masterha_master_monitor マスターがダウンしているかどうかを確認する
masterha_master_switch フェイルオーバーを制御する (自動または手動)
masterha_conf_host 設定済みのサーバー情報を追加または削除する

ノードツールキット (これらのツールは通常、MHA マネージャースクリプトによってトリガーされ、人間の操作を必要としません) には、主に次のツールが含まれています。

save binary_logs マスターのバイナリログを保存してコピーします。
apply diff リレーログを適用します。差分リレーログイベントを特定し、その差分イベントを他の
スレーブに適用
します。 filter_mysqlbinlog 不要な ROLLBACK イベントを削除します (MHA はこのツールを使用しなくなりました)。
purge valley_logs リレーログをクリアします (SQL をブロックしません)。糸）

展開する

MHA をインストールする

環境を整える

5 つの仮想マシン

5 つの仮想マシンは、より適切に分割できるように名前が変更されました。

命令：hostnamectl set-hostname server

更新: bash

マネージャー

メインサーバー

サーバー1から

サーバー2から

サーバー3から

全マシン設置

ファイアウォールをオフにする

yum を表示、CD マウントを表示

epel リリースソースをダウンロード

仮想マシンに直接取り込むことができます

次に、rpm -ivh を使用してインストールします。

rpm -ivh epel-release-latest-7.noarch.rpm

Alibaba ソースファイルのインストールも仮想マシンに直接取り込まれます。

次のコマンドを使用してインストールすることもできます

wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

次にMHAをインストールします

yum install -y perl-DBD-MySQL.x86_64 perl-DBI.x86_64 perl-CPAN perl-ExtUtils-CBuilder perl-ExtUtils-MakeMaker

MHA ノードのインストール

rz 送信に問題がある場合は、rz 送信を仮想マシンに直接取り込むことができます。

cd してノードソフトウェアパッケージを見つけ、現在のディレクトリに解凍するだけです (5 つの仮想マシンすべてを操作する必要があります)。

tar xf mha4mysql-node-0.56.tar.gz

解凍したディレクトリを入力して実行します

Perl ソースによる設定

perl Makefile.PL

次にコンパイルしてインストールします

メイク&&メイクインストール

MHA Nodeのインストール後、/usr/local/binに以下のスクリプト(4つのスクリプトファイル)が生成されます。

ls -l /usr/local/bin/

MHA マネージャーをインストールする

インストールする必要があるマシンは 1 台のみ(server1)

MHA Mangerが依存するperlモジュールをインストールする

yum install -y perl perl-Log-Dispatch perl-Parallel-ForkManager perl-DBD-MySQL perl-DBI perl-Time-HiRes

次に、perl パッケージをインストールして仮想マシンにプルする必要があります。

または、rz でウィンドウを開いて仮想マシンにプルします

perl-Config-Tiny-2.14-7.el7.noarch.rpm

ビュー

rpm -ivh を使用してインストールする

perl-Config-Tiny-2.14-7.el7.noarch.rpm

MHA マネージャーパッケージをインストールする

rz はウィンドウを開いて仮想マシンに引き込みます

mha4mysql-manager-0.56.tar.gz

その後、次のコマンドを実行します

tar xf mha4mysql-manager-0.56.tar.gz 解凍

cd mha4mysql-manager-0.56/ ディレクトリに入る

perl Makefile.PL は Perl 言語でファイルをコンパイルします

make && make install コンパイルしてインストールする

インストールが完了すると、以下のスクリプトファイル（13個のスクリプトファイル）が作成されます。

ls -l /usr/local/bin/

SSH キーペアの検証を構成する

[各仮想マシンはパスワードなしのログインを実装する必要があることに注意してください]! ！！

まず各仮想マシンの構成を分析します

vim /etc/hosts

キーの生成

ssh-keygen

ループで4回連続生成可能

for i in 115 116 117 126;do ssh-copy-id 192.168.1.$i;done

パスワードなしのログインを検証する

SSHサーバー1...5

mysqlをインストールする

サーバー2....5

4 つのホストをインストールする必要がある

yum -y インストール mariadb mariadb-server

次にシステムを起動します

systemctl マリアDBを起動します

再起動後

コマンドを入力してポートを表示します

netstat -lnpt | グリップ：3306

コマンドを入力してください

mysqladmin -u root パスワード 123456 はデータベースの初期パスワードを設定します

マスター/スレーブレプリケーション構成ファイルを設定する

vim /etc/my.cnf

【サーバー2】マスター

サーバーID = 1
ログビン=マスタービン
ログスレーブ更新=真
リレーログパージ=0

【server3】補助マスター

サーバーID = 2
ログビン=マスタービン
ログスレーブ更新=真
リレーログパージ=0

【server4】より

サーバーID=3
log-bin=mysql-bin
リレーログ=スレーブリレービン
ログスレーブ更新=真
リレーログパージ=0

【server5】より

サーバーID=4
log-bin=mysql-bin
リレーログ=スレーブリレービン
ログスレーブ更新=真
リレーログパージ=0

サーバーを再起動します

systemctl mariadb を再起動します

承認する

Server2...4 データベースはすべて認証が必要です

許可されたユーザーを作成する

4 台の仮想マシンが mysql にログインします

mysql -uroot -p123456

それから許可する

*.* のレプリケーションスレーブを '123456' で識別される 'repl'@'192.168.1.%' に許可します。

認証の更新

フラッシュ権限。

メインライブラリのステータスを確認する

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

次に、3 台のスレーブサーバーがマスターサーバーを指定します。

最初にスレーブサーバーをシャットダウンします

スレーブを停止します。

次のように入力します

マスターを次のように変更します

  MASTER_HOST='192.168.1.115',

  MASTER_USER='repl',

  MASTER_PASSWORD='123456',

  MASTER_LOG_FILE='mastar-binlog.000001',

  MASTER_LOG_POS=472;

次のコマンドを入力して、MySQL データベースのレプリケーションステータスを表示します。

スレーブステータスを表示\G

【！知らせ！！！何か問題が発生した場合は、このコマンドを試してトラブルシューティングを行ってください]

スレーブを停止します。
スレーブをリセットします。
グローバル sql_slave_skip_counter =1 を設定します。
スレーブを開始する

サーバーから読み取り専用ステータスを設定する

これを実行すると、スレーブサーバーは何も書き込めなくなります。

図書館の外で書き物をする

mysql -uroot -p123456 -e 'グローバル read_only=1 を設定;'

カレーの書き方

グローバル読み取り専用=1を設定します。

監視ユーザーserver2....5 を作成して、監視ノードに高い権限を提供します。

*.* に対するすべての権限を「123456」で識別される「root」@「192.168.1.%」に付与します。

権限を更新する

フラッシュ権限。

次のステップは、自分のホスト名を認証することです。

彼らです：

*.* に対するすべての権限を「123456」で識別される「root」@「server2」に付与します。

*.* に対するすべての権限を「123456」で識別される「root」@「server3」に付与します。

*.* に対するすべての権限を「123456」で識別される「root」@「server4」に付与します。

*.* に対するすべての権限を「123456」で識別される「root」@「server5」に付与します。

サーバー1に戻る

/etc/masterha ディレクトリの作成構成ディレクトリの作成テンプレートファイルのコピー

mkdir /etc/masterha

次に、root の下にある mha4mysql-manager-0.56 を、先ほど作成したディレクトリにコピーします。

cp mha4mysql-manager-0.56/samples/conf/app1.cnf /etc/masterha

コピーしたファイル構成を変更します

vim /etc/masterha/app1.cnf

[サーバーのデフォルト]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/manager.log
master_binlog_dir=/var/lib/mysql
master_ip_failover_script= /usr/local/bin/master_ip_failover

パスワード=123456
ユーザー=ルート
ping_interval=1
リモートワークディレクトリ=/tmp
reql_password=123456
reql_user=repl

[サーバー1]
ホスト名=サーバー2
ポート=3306

[サーバー 2]
ホスト名 = サーバー 3
候補マスター = 1
ポート = 3306
チェック_repl_遅延 = 0

[サーバー3]
ホスト名=サーバー4
ポート=3306

[サーバー4]
ホスト名=サーバー5
ポート=3306

フェイルオーバースクリプトの構成

開いたら、スクリプトの内容をコピーして、VIP を変更し、ネットワークカード名を変更します。

vim /usr/local/bin/master_ip_failover

#!/usr/bin/env perl

厳密を使用します。
警告を使用します。 FATAL => 'all';
Getopt::Long を使用します。
my (
$command, $ssh_user, $orig_master_host, $orig_master_ip,
$orig_master_port, $new_master_host, $new_master_ip, $new_master_port,
);
私の $vip = '192.168.200.100';
私の $key = "1";
私の $ssh_start_vip = "/sbin/ifconfig ens32:$key $vip";
私の $ssh_stop_vip = "/sbin/ifconfig ens32:$key down";
$ssh_user = "ルート";
GetOptions(
'command=s' => \$command,
'ssh_user=s' => \$ssh_user,
'orig_master_host=s' => \$orig_master_host,
'orig_master_ip=s' => \$orig_master_ip,

'new_master_host=s' => \$new_master_host,
'new_master_ip=s' => \$new_master_ip,
'new_master_port=i' => \$new_master_port,
);
&main(); を終了します。
sub main {
print "\n\nIN SCRIPT TEST====$ssh_stop_vip==$ssh_start_vip===\n\n";
if ( $command eq "stop" || $command eq "stopssh" ) {
# $orig_master_host、$orig_master_ip、$orig_master_port が渡されます。
# マスター IP アドレスをグローバルカタログデータベースで管理している場合は、
# ここで orig_master_ip を無効にします。
私の$exit_code = 1;
#eval {
# print "古いマスターでの VIP の無効化:

print "古いマスターで VIP を無効にしています: $orig_master_host \n";
#my $ping=`ping -c 1 10.0.0.13 | grep "パケットロス" | awk -F',' '{print $3}' | awk '{print $1}' `;
#if ( $ping le "90.0%"&& $ping gt "0.0%" ){
#$exit_code = 0;
#}
#else {
&stop_vip();
# グローバルカタログなどの更新
$exit_code = 0;
#}
};

if ($@) {
warn "エラーが発生しました: $@\n";
$exit_code を終了します。 $exit_code を終了します
。 } elsif ( $command eq "start" ) { # すべての引数が渡されます。 # マスター IP アドレスをグローバルカタログデータベースで管理する場合は、 # ここで new_master_ip を有効にします。 # ここで書き込みアクセスを許可することもできます (ユーザーの作成、read_only=0 の設定など)。私の $exit_code = 10; eval { print "新しいマスターで VIP - $vip を有効にします - $new_master_host \n"; &start_vip(); $exit_code = 0; }; if ($@) { $@ に警告します。 $exit_code を終了します。 $exit_code を終了します。 }

elsif ( $command eq "status" ) {
print "スクリプトのステータスを確認しています。OK \n";
`ssh $ssh_user\@$orig_master_ip \" $ssh_start_vip \"`;
0番出口;
}
else {
&usage();
1番出口。
}
}
# 新しいマスター
サブサブで VIP を有効にする簡単なシステムコール 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 \"`;
}
サブの使用法 {
print
"使用法: 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"; }

設定が完了したら、x 個の実行権限を付与します。

chmod +x /usr/local/bin/master_ip_failover

検出

MHA ssh通信状態が正常か確認する

masterha_check_ssh --conf=/etc/masterha/app1.cnf

正常に返された場合は問題がないことを意味します

クラスタ全体のステータスを確認する

masterha_check_repl --conf=/etc/masterha/app1.cnf

[「NET OK」が表示された場合は、上記の手順に従って、コマンドが正しく入力されているか、文字が間違って入力されているかを確認できます]

マネージャーのステータスを確認する

masterha_check_status --conf=/etc/masterha/app1.cnf

正常であれば「PING_OK」と表示されます。

NOT_RUNNING」は、MHA 監視が有効になっていないことを示します。

モニタリングをオンにして、オンになっているかどうかを確認します。

マネージャーの監視を有効にする

nohup masterha_manager --conf=/etc/masterha/app1.cnf --remove_dead_master_conf --ignore_last_failover< /dev/null >/var/log/masterha/app1/manager.log 2>&1 &

--remove_dead_master_conf マスター/スレーブの切り替えが発生すると、古いマスターライブラリの IP アドレスが設定ファイルから削除されます。

--manger_log ログの保存場所

--ignore_last_failover

デフォルトでは、MHA が継続的なダウンタイムを検出し、2 つのダウンタイムの間隔が 8 時間未満の場合、フェールオーバーは実行されません。この制限の理由は、ピンポン効果を回避するためです。このパラメータは、最後の MHA トリガースイッチによって生成されたファイルを無視することを意味します。デフォルトでは、MHA スイッチが発生した後、app1.failover.complete ファイルがログディレクトリ (上で設定した /data) に生成されます。次回再び切り替えるときに、このファイルが存在することがわかります。このディレクトリにこのファイルが存在すると、最初の切り替え後にファイルが削除されない限り、切り替えをトリガーできません。便宜上、これは --ignore_last_failover に設定されています。

監視をオフにする

masterha_stop --conf=/etc/masterha/app1.cnf

テストの失敗

モニタリングホストの構成が完了したら、メインデータベースネットワークカードをチェックして VIP を取得できます。

ip a | grep ens33

メインデータベースの障害をシミュレートする

systemctl stop mariadb はサービスをオフにします

それぞれのマシンが何をしているのか、どのような役割を果たしているのかを確認する

tail -f /etc/masterha/app1/manger

前の手順を完了したら、ライブラリから mysql を入力します。

スレーブステータスを表示\G

ライブラリから指定されたIPが変更されていることがわかります。

修理

再起動するだけです

systemctl mariadb を再起動します

ただし、元の IP は戻りません

コマンドを使用して表示します

ip a | grep ens33

[MHA] Mysql 高可用性クラスター MHA 検証

目次