Mysql GTID Mha 設定方法
|
Gtid + Mha + Binlog サーバー構成: 1: テスト環境 OS: CentOS 6.5 192.168.1.21 mysql1 M1 2: /etc/my.cnfの関連パラメータを設定し、3つのノードそれぞれで個別に設定します。 binlog 形式 = ROW ログスレーブ更新=true gtidモード=オン 強制GTID一貫性=true マスター情報リポジトリ=テーブル リレーログ情報リポジトリ=テーブル 同期マスター情報=1 スレーブ並列ワーカー = 2 binlog チェックサム = CRC32 マスター検証チェックサム=1 スレーブSQL検証チェックサム=1 binlog行クエリログイベント=1 ルート パスワードを設定し、レプリケーション ユーザーを作成します。
mysql> mysql を使用します。
mysql> *.* のすべての権限を root@"%" IDENTIFIED BY "oracle123" に付与します。
mysql> ユーザーを更新し、Password を password('oracle123') に設定し、User を 'root' に設定します。
mysql> 権限をフラッシュします。
mysql> 'oracle' によって識別される 'repl'@'%' に *.* レプリケーション スレーブを GRANT します。
mysql> 権限をフラッシュします。
3: mysql2とmysql3でGtidレプリケーションを構成する
マスターを変更
マスターホスト = '192.168.1.21'、
マスターポート = 3306、
MASTER_USER = 'repl'、
MASTER_PASSWORD = 'oracle'、
マスター自動位置 = 1;
スレーブを起動します。
mysql>スレーブステータスを表示\G
************************** 1. 行 ****************************
Slave_IO_State: マスターがイベントを送信するのを待機中
マスターホスト: 192.168.1.21
マスターユーザー: repl
マスターポート: 3306
接続再試行: 60
マスターログファイル: mysql-bin.000003
読み取りマスターログ位置: 524
リレーログファイル:mysql-relay-bin.000002
リレーログ位置: 734
リレーマスターログファイル: mysql-bin.000003
スレーブIO実行中: はい
スレーブSQL実行中: はい
レプリケート_Do_DB:
......
マスターSSLCrlパス:
取得Gtidセット: 9ee7c7af-cbf3-11e5-bf75-000c2923e459:1-2
実行されたGtidセット: 9ee7c7af-cbf3-11e5-bf75-000c2923e459:1-2
自動位置: 1
セット内の 1 行 (0.00 秒)
4: Mhaをインストールする rpm -Uvh epel-release-6-8.noarch.rpm SSH と同等の設定: すべてのノードで実行 ssh-keygen -t rsa ssh-copy-id -i /root/.ssh/id_rsa.pub root@mysql1 ssh-copy-id -i /root/.ssh/id_rsa.pub root@mysql2 ssh-copy-id -i /root/.ssh/id_rsa.pub root@mysql3 3 つのノードで ssh ログインをテストします。 SSH myqsl1 の SSH myqsl2 の SSH myqsl3 の Binlogサーバーの設定: mysql3 mkdir -p /mysql/backup/binlog /usr/local/mysql/bin/mysqlbinlog -R --raw --host=192.168.1.20 --user='root' --password='oracle123' --stop-never mysql- bin.000003 & その binlog ファイルから開始して、最後の binlog ファイルが提供されます。また、mysql1 上の mysql プロセスが終了すると、binlog サーバーも終了することに注意してください。 一部のパッケージは、サポートのためにyumネットワークソースを使用してインストールする必要があります。インストール中に問題が発生した場合は、yum updateでyumソースを更新するか、yum clean allでキャッシュをクリアしてみてください。 各ノードにmha4mysql-nodeをインストールする yum -y perl-DBD-MySQL ncftp をインストールします mysql3にmha-managerをインストールする yumでperlをインストール yum で cpan をインストール yum インストール perl-Config-Tiny yum インストール perl-Time-HiRes yum で perl-Log-Dispatch をインストールします yum で perl-Parallel-ForkManager をインストールします perl-Log-Dispatch をインストールすると、perl-Parallel-ForkManager インストール パッケージでエラーが報告されます。 まず epel をインストールする必要があります (https://fedoraproject.org/wiki/EPEL を参照) rpm -Uvh mha4mysql-manager-0.56-0.el6.noarch.rpm 5: mysql3でMhaを設定する
mkdir -p /etc/masterha/app1
vi /etc/masterha/app1.cnf
[サーバーのデフォルト]
ユーザー=root
パスワード=oracle123
マネージャーワークディレクトリ=/etc/masterha/app1
マネージャログ=/etc/masterha/app1/manager.log
リモートワークディレクトリ=/etc/masterha/app1
ssh_user=ルート
repl_user=リプラスユーザー
repl_password=oracle
ping_interval=3
マスターIPフェイルオーバースクリプト=/etc/masterha/app1/マスターIPフェイルオーバー
[サーバー1]
ホスト名=192.168.1.21
#ssh_port=9999
マスター_binlog_dir=/mysql/logs
check_repl_delay=0 #マスターの障害を防ぐため、スレーブへの切り替え時に遅延が発生しますが、そこで切り替えることはできません candidate_master=1
[サーバー2]
ホスト名=192.168.1.22
#ssh_port=9999
マスター_binlog_dir=/mysql/logs
候補マスター=1
[サーバー3]
ホスト名=192.168.1.23
#ssh_port=9999
マスター_binlog_dir=/mysql/logs
マスターなし=1
ignore_fail=1 #このノードに障害が発生すると、MHA は利用できなくなります。スレーブに障害が発生しても使用できるように、このパラメータを追加します [binlog1] #binlog サーバーには mysqlbinlog コマンドが必要です hostname=192.168.1.23
master_binlog_dir=/mysql/backup/binlog #binlogの保存場所を読み取り ignore_fail=1
マスターなし=1
vi /etc/masterha/app1/master_ip_failover
#!/usr/bin/env パール
厳密なものを使用します。
警告 FATAL => 'all' を使用します。
Getopt::Long を使用します。
私の
$コマンド、$ssh_user、$orig_master_host、$orig_master_ip、
$orig_master_port、$new_master_host、$new_master_ip、$new_master_port
);
my $vip = '192.168.1.20';#仮想IP
my $gateway = '192.168.1.1'; #ゲートウェイIP
私の$interface = 'eth0';
私の$key = "1";
私の $ssh_start_vip = "/sbin/ifconfig $interface:$key $vip;/sbin/arping -I $interface -c 3 -s $vip $gateway >/dev/null 2>&1";
my $ssh_stop_vip = "/sbin/ifconfig $interface:$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" の場合 {
# $orig_master_host、$orig_master_ip、$orig_master_port が渡されます。
# グローバルカタログデータベースでマスターIPアドレスを管理する場合、
# ここで orig_master_ip を無効にします。
私の$exit_code = 1;
評価 {
print "古いマスターの VIP を無効にしています: $orig_master_host \n";
&stop_vip();
$終了コード = 0;
};
もし（$@）{
warn "エラーが発生しました: $@\n";
終了 $exit_code;
}
終了 $exit_code;
}
elsif ( $command が "start" と等しい ) {
# すべての引数が渡されます。
# グローバルカタログデータベースでマスターIPアドレスを管理する場合、
# ここで new_master_ip を有効にします。
# ここで書き込みアクセスを許可することもできます (ユーザーの作成、read_only=0 の設定など)。
私の$exit_code = 10;
評価 {
print "新しいマスター $new_master_host で VIP $vip を有効にしています \n";
開始vip();
$終了コード = 0;
};
もし（$@）{
警告 $@;
終了 $exit_code;
}
終了 $exit_code;
}
elsif ( $command が "ステータス" と等しい ) {
print "スクリプトのステータスを確認しています。OK \n";
`ssh $ssh_user\@$orig_master_host \" $ssh_start_vip \"`;
終了0;
}
それ以外 {
＆使用法（）;
出口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 \"`;
}
サブの使用法 {
印刷
「使用方法: master_ip_failover --command=start|stop|stopssh|status --orig_master_host=host --orig_master_ip=ip --
orig_master_port=ポート --new_master_host=ホスト --new_master_ip=ip --new_master_port=ポート\n";
}
chmod 777 /etc/masterha/app1/
設定ファイルのテスト: # masterha_check_ssh --conf=/etc/masterha/app1.cnf 2016 年 5 月 26 日木曜日 23:25:35 - [警告] グローバル構成ファイル /etc/masterha_default.cnf が見つかりません。スキップします。 2016 年 5 月 26 日木曜日 23:25:35 - [info] /etc/masterha/app1.cnf からアプリケーションのデフォルト設定を読み取っています。 2016 年 5 月 26 日木曜日 23:25:35 - [info] /etc/masterha/app1.cnf からサーバー構成を読み取っています。 2016 年 5 月 26 日木曜日 23:25:35 - [情報] SSH 接続テストを開始しています。 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] [email protected](192.168.1.21:22) から [email protected](192.168.1.22:22) に SSH 経由で接続しています。 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] 正常です。 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] [email protected](192.168.1.21:22) から [email protected](192.168.1.23:22) に SSH 経由で接続しています。 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] 正常です。 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] [email protected](192.168.1.22:22) から [email protected](192.168.1.21:22) に SSH 経由で接続しています。 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] 正常です。 2016 年 5 月 26 日木曜日 23:25:35 - [デバッグ] [email protected](192.168.1.22:22) から [email protected](192.168.1.23:22) に SSH 経由で接続しています。 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] 正常です。 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] [email protected](192.168.1.23:22) から [email protected](192.168.1.21:22) に SSH 経由で接続しています。 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] 正常です。 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] [email protected](192.168.1.23:22) から [email protected](192.168.1.22:22) に SSH 経由で接続しています。 2016 年 5 月 26 日木曜日 23:25:36 - [デバッグ] 正常です。 2016 年 5 月 26 日木曜日 23:25:36 - [情報] すべての SSH 接続テストが正常に合格しました。 #masterha_check_repl --conf=/etc/masterha/app1.cnf 2016 年 5 月 26 日木曜日 22:52:30 - [警告] グローバル設定ファイル /etc/masterha_default.cnf が見つかりません。スキップします。 2016 年 5 月 26 日木曜日 22:52:30 - [info] /etc/masterha/app1.cnf からアプリケーションのデフォルト設定を読み取っています。 2016 年 5 月 26 日木曜日 22:52:30 - [info] /etc/masterha/app1.cnf からサーバー構成を読み取っています。 2016 年 5 月 26 日木曜日 22:52:30 - [情報] MHA::MasterMonitor バージョン 0.56。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] GTID フェイルオーバー モード = 1 2016年5月26日木曜日 22:52:31 - [情報] デッドサーバー: 2016年5月26日木曜日 22:52:31 - [情報] 稼働中のサーバー: 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.21(192.168.1.21:3306) 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.22(192.168.1.22:3306) 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.23(192.168.1.23:3306) 2016年5月26日木曜日 22:52:31 - [情報] 生きた奴隷: 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.22(192.168.1.22:3306) バージョン = 5.6.28-log (スレーブ間の最も古いメジャー バージョン) log-bin: 有効 2016年5月26日木曜日 22:52:31 - [情報] GTID ON 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.21(192.168.1.21:3306) から複製しています 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 新しいマスターの第一候補 (candidate_master が設定されています) 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.23(192.168.1.23:3306) バージョン = 5.6.28-log (スレーブ間の最も古いメジャー バージョン) log-bin: 有効 2016年5月26日木曜日 22:52:31 - [情報] GTID ON 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.21(192.168.1.21:3306) から複製しています 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 新しいマスターの候補ではありません (no_master が設定されています) 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 現在アクティブなマスター: 192.168.1.21(192.168.1.21:3306) 2016 年 5 月 26 日木曜日 22:52:31 - [情報] スレーブ構成を確認しています。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] スレーブ 192.168.1.22 (192.168.1.22:3306) に read_only=1 が設定されていません。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] スレーブ 192.168.1.23 (192.168.1.23:3306) で read_only=1 が設定されていません。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] レプリケーション フィルタリング設定を確認しています。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] binlog_do_db=、binlog_ignore_db= 2016 年 5 月 26 日木曜日 22:52:31 - [情報] レプリケーション フィルタリング チェックは正常です。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] GTID (自動位置指定付き) がサポートされています。SSH および Node パッケージのチェックはすべてスキップされます。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] HealthCheck: 192.168.1.23 への SSH は到達可能です。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] Binlog サーバー 192.168.1.23 に到達可能です。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.23 (192.168.1.23:3306) のリカバリ スクリプトの構成を確認しています。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] コマンドを実行しています: save_binary_logs --command=test --start_pos=4 --binlog_dir=/mysql/backup/binlog --output_file=/etc/masterha/app1/save_binary_logs_test --manager_version=0.56 --start_file=mysql-bin.000004 2016 年 5 月 26 日木曜日 22:52:31 - [情報] [email protected](192.168.1.23:22) に接続しています。 /etc/masterha/app1 が存在しない場合は作成します。 出力ディレクトリにアクセスできるかどうかを確認しています。 わかりました。 /mysql/backup/binlog に mysql-bin.000004 までのバイナリログが見つかりました 2016 年 5 月 26 日木曜日 22:52:31 - [情報] Binlog 設定チェックが完了しました。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 現在のマスターの SSH 公開鍵認証設定を確認しています。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] HealthCheck: 192.168.1.21 への SSH は到達可能です。 2016年5月26日木曜日 22:52:31 - [情報] 192.168.1.21(192.168.1.21:3306) (現在のマスター) +--192.168.1.22(192.168.1.22:3306) +--192.168.1.23(192.168.1.23:3306) 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.22 のレプリケーションの健全性を確認しています。 2016年5月26日木曜日 22:52:31 - [情報] わかりました。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] 192.168.1.23 のレプリケーションの健全性を確認しています。 2016年5月26日木曜日 22:52:31 - [情報] わかりました。 2016 年 5 月 26 日木曜日 22:52:31 - [情報] master_ip_failover_script のステータスを確認しています: 2016 年 5 月 26 日木曜日 22:52:31 - [情報] /etc/masterha/app1/master_ip_failover --command=status --ssh_user=root --orig_master_host=192.168.1.21 --orig_master_ip=192.168.1.21 --orig_master_port=3306 スクリプトテストの場合====/sbin/ifconfig eth1:1 down==/sbin/ifconfig eth1:1 192.168.1.20;/sbin/arping -I eth1 -c 3 -s 192.168.1.20 192.168.1.1 >/dev/null 2>&1=== スクリプトのステータスを確認しています。OK 2016年5月26日木曜日 22:52:34 - [情報] OK。 2016 年 5 月 26 日木曜日 22:52:34 - [警告] Shutdown_script が定義されていません。 2016 年 5 月 26 日木曜日 22:52:34 - [情報] 終了コード 0 を取得しました (マスターは死んでいません)。 MySQL レプリケーションの健全性は正常です。 MHA の起動とシャットダウン nohup masterha_manager --conf=/etc/masterha/app1.cnf > /etc/masterha/app1/manager.log < /dev/null 2>&1 & 開始されているかどうかを確認します: masterha_check_status --conf=/etc/masterha/app1.cnf app1 (pid:11447) が実行中です(0:PING_OK)、マスター:192.168.1.21 ストップ・マー： masterha_stop --conf=/etc/masterha/app1.cnf app1 を正常に停止しました。 [3]+ 終了 1 nohup masterha_manager --conf=/etc/masterha/app1.cnf > /etc/masterha/app1/manager.log < /dev/null 2>&1 テスト： 注: 各テストが完了したら、/etc/masterha/app1 の下のログをクリーンアップしてから、Mha マネージャーを起動する必要があります。 1: mysql1のmysqlを閉じ、そこからスレーブデータベースの同期とmhaログ出力を確認します。 2: mysql1 を mysql2 のスレーブとして復元します。マスター変更ステートメントは /etc/masterha/app1/manager.log にあります。 GTIDレプリケーションを設定するときに1032エラーが発生し、次の方法で解決します。 mysql> '%gtid%' のようなグローバル変数を表示します。 +---------------------------------+--------------------------------------------------------------------------------------------------+ | 変数名 | 値 | +---------------------------------+--------------------------------------------------------------------------------------------------+ | binlog_gtid_simple_recovery | オフ | | 強制GTID一貫性 | オン | | gtid_executed | 88b05570-2599-11e6-880a-000c29c18cf5:1-3、 9ee7c7af-cbf3-11e5-bf75-000c2923e459:1-4 | | gtid_mode | オン | | gtid_owned | | | gtid_purged | | | 簡素化されたbinlog_gtid_recovery | オフ | +---------------------------------+--------------------------------------------------------------------------------------------------+ 奴隷を停止します。 gtid_next='9ee7c7af-cbf3-11e5-bf75-000c2923e459:4' を設定します。 始める; 専念; gtid_next='自動' を設定します。 スレーブを起動します。 スレーブステータスを表示\G; 上記のMysql GTID Mha設定方法は、編集者が皆さんと共有するすべての内容です。参考になれば幸いです。また、123WORDPRESS.COMを応援していただければ幸いです。 以下もご興味があるかもしれません:
|
<<: Docker MQTT のインストールと使用のチュートリアル
>>: シンプルなメッセージボードケースを実現するJavaScript
推薦する
Vueスロットの使用の詳細
目次1. スロットを使用する理由1.1 スロット1.2 コンポーネントのスロット1.3 例2. この...
デザイン参考 WordPressウェブサイト構築成功事例
これら 16 のサイトはそれぞれ注意深く読む価値があり、どのサイトでも推奨されている Web サイト...
JS でページのスクリーンショット機能を実装する方法
「ページのスクリーンショット」は、ページポスターの生成、ポップアップ画像の共有など、フロントエンドで...
NextCloud プライベート クラウド ストレージ ネットワーク ディスクの構築に関する詳細なチュートリアル
Nextcloud は、オープンソースで無料のプライベート クラウド ストレージ ネットワーク ディ...
MySQL で珍しい文字を挿入できないときの対処方法 (文字列値が正しくない)
最近、ビジネス側から、一部のユーザー情報の挿入に失敗し、エラー メッセージが「不正な文字列値:&qu...
抽選効果を実現するJavaScript
この記事では、宝くじマシンの効果を実現するためのJavaScriptの具体的なコードを参考までに共有...
MySQL の高可用性アーキテクチャの完全な説明: MHA アーキテクチャ
目次1. はじめに2. 構成3. 作業プロセス4. 建築5. 表示例MHA (Master HA) ...
MySQL が innobackupex を使用して接続サーバーをバックアップできない場合の解決策
innobackupex を使用してバックアップする際に MySQL がサーバーに接続できない場合は...
Windows で Mysql を起動したときに 1067 が表示される場合の解決策
数日前に仕事を始めて、Mysql をインストールしたところ、開くことができました。今日、会社に行った...
Docker を使用して pypi プライベート リポジトリを構築する方法
1. 建設1. htpasswd.txtファイルを準備するファイルには、パッケージを倉庫にアップロー...
Node+socketでシンプルなチャットルーム機能を実現
この記事では、参考までに、シンプルなチャットルームを実装するためのnode+socketの具体的なコ...
Nginx は rtmp ライブ サーバーの実装コードを構築します
1. nginxソースディレクトリに新しいrtmpディレクトリを作成し、git clone http...
docker compose を使用して consul クラスタ環境を構築する例
領事の基本概念サーバーモードとクライアントモードサーバー モードとクライアント モードは、consu...
jQueryはテーブルのシームレスなスクロールを実現します
この記事の例では、テーブルのシームレスなスクロールを実現するためのjQueryの具体的なコードを参考...
Web デザイン リファレンス Firefox デフォルト スタイル
W3C は HTML の標準をいくつか確立していますが、ブラウザは独自の定義済みスタイルに従って W...