別々の読み取りと書き込みの章Xの高可用性

その他 2019-12-21 17:07:33 訪問数: null

マスタースレーブのレプリケーション・アーキテクチャは、導入を進化します

基本的な構造

（1）一主一从
​（2）一主多从
​（3）多级主从
​（4）双主
​（5）循环复制

高度なアプリケーションアーキテクチャの進化

高性能アーキテクチャ

(1) 读写分离架构(读性能较高)
代码级别
MySQL proxy (Atlas,mysql router,proxySQL(percona),maxscale)、amoeba(taobao) ,xx-dbproxy等。

(2) 分布式架构(读写性能都提高):
分库分表——cobar--->TDDL(头都大了),DRDS
Mycat--->DBLE自主研发等。
NewSQL-->TiDB

高可用性アーキテクチャ

（1）单活:MMM架构——mysql-mmm（google）
（2）单活:MHA架构——mysql-master-ha（日本DeNa）,T-MHA
（3）多活:MGR ——5.7 新特性 MySQL Group replication(5.7.17) --->Innodb Cluster  
（4）多活:MariaDB Galera Cluster架构,(PXC)Percona XtraDB Cluster、MySQL Cluster(Oracle rac)架构

可用性MHA *****

アーキテクチャの作品

#主库宕机处理过程

1. 监控节点 (通过配置文件获取所有节点信息)
   系统,网络,SSH连接性
   主从状态,重点是主库
2. 选主
(1) 如果判断从库(position或者GTID),数据有差异,最接近于Master的slave,成为备选主
(2) 如果判断从库(position或者GTID),数据一致,按照配置文件顺序,选主.
(3) 如果设定有权重(candidate_master=1),按照权重强制指定备选主.
    1. 默认情况下如果一个slave落后master 100M的relay logs的话，即使有权重,也会失效.
    2. 如果check_repl_delay=0的化,即使落后很多日志,也强制选择其为备选主
3. 数据补偿
(1) 当SSH能连接,从库对比主库GTID 或者position号,立即将二进制日志保存至各个从节点并且应用(save_binary_logs )
(2) 当SSH不能连接, 对比从库之间的relaylog的差异(apply_diff_relay_logs) 
4. Failover
将备选主进行身份切换,对外提供服务
其余从库和新主库确认新的主从关系
5. 应用透明(VIP)
6. 故障切换通知(send_reprt)
7. 二次数据补偿(binlog_server)
8. 自愈自治(待开发...)


# Failover

1. MHA通过脚本(masterha_master_monitor)实时(ping_interval=2)监控主库的状态(主机,数据库状态)
2. 监控到主库宕机之后,会发生自动选主(masterha_master_switch )
    (1) 权重: 参数
    (2) 日志量
    (3) 配置文件的顺序
3. 数据补偿
    (1) 当主库SSH能够连接,各个从库会立即保存(save_binary_logs)缺失部分的日志到/var/tmp,进行数据补偿.
    (2) 当主库SSH无法连接,通过脚本(apply_diff_relay_logs)自动进行从库的relaylog的差异处理,进行数据补偿.
4. 构建新的主从关系,并将故障节点移除(配置文件移除)    
5. MHA主进程完成工作后,自动退出.

6. 应用透明 VIP(master_ip_failover_script=/usr/local/bin/master_ip_failover)
7. 故障通知 (report_script=/usr/local/bin/send)
8. 提供额外数据补偿的手段(binlog server)

   自动自愈,待开发....

アーキテクチャの説明：

1主2从，

master：db01   

slave：db02   db03 ）：
MHA 高可用方案软件构成
Manager软件：选择一个从节点安装
Node软件：所有节点都要安装

MHAソフトウェア構成

Manager 工具包主要包括以下几个工具：

masterha_manger             # 启动MHA 
masterha_check_ssh          #检查MHA的SSH配置状况 
masterha_check_repl         #检查MySQL复制状况 
masterha_master_monitor     #检测master是否宕机 
masterha_check_status       #检测当前MHA运行状态 
masterha_master_switch      #控制故障转移（自动或者手动）
masterha_conf_host          #添加或删除配置的server信息

Node工具包主要包括以下几个工具：
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs            保存和复制master的二进制日志 
apply_diff_relay_logs       识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs            清除中继日志（不会阻塞SQL线程）

ビルドにMHA環境

計画：

主库: 51    node 
从库: 
52      node
53      node    manager

環境を準備します

（わずかにメインGTID .1から2）

構成プログラムソフトキー接続

ln -s /application/mysql/bin/mysqlbinlog    /usr/bin/mysqlbinlog
ln -s /application/mysql/bin/mysql          /usr/bin/mysql

各ノードの信頼を設定します

手動で接続する初めてイエスを確認するために、

db01：

rm -rf /root/.ssh 
ssh-keygen
cd /root/.ssh 
mv id_rsa.pub authorized_keys
scp  -r  /root/.ssh  10.0.0.52:/root 
scp  -r  /root/.ssh  10.0.0.53:/root 

各节点验证
db01:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

db02:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

db03:
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date

ソフトウェアのインストール

ダウンロードソフトウェアMHA

MHA公式サイト：HTTPS：//code.google.com/archive/p/mysql-master-ha/
GitHubのダウンロードします。https：//github.com/yoshinorim/mha4mysql-manager/wiki/Downloads

すべてのノードは、ノードのソフトウェアの依存関係をインストール

yum install perl-DBD-MySQL -y
rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpm

MHAは、マスター・データベースdb01にユーザーを作成する必要があります

grant all privileges on *.* to mha@'10.0.0.%' identified by 'mha';

Managerソフトウェアのインストール（DB03）

yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
rpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpm

設定ファイルの準備（DB03）

プロファイルディレクトリを作成します。

mkdir -p /etc/mha

ログディレクトリを作成します。

mkdir -p /var/log/mha/app1

編集mhaプロフィール

[root@db03 ~]#  vim /etc/mha/app1.cnf

[server default]
manager_log=/var/log/mha/app1/manager        
manager_workdir=/var/log/mha/app1            
master_binlog_dir=/data/binlog       
user=mha                                   
password=mha                               
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root                               
[server1]                                   
hostname=10.0.0.51
port=3306                                  
[server2]            
hostname=10.0.0.52
port=3306
[server3]
hostname=10.0.0.53
port=3306

ステータスチェック

## 互信检查
[root@db03 ~]# masterha_check_ssh  --conf=/etc/mha/app1.cnf 


## 主从状态检查
[root@db03 ~]# masterha_check_repl  --conf=/etc/mha/app1.cnf 

MySQL Replication Health is OK.

オープンMHA（DB03）：

[root@db03 ~]#  masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &

ビューMHAのステータス

[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:4719) is running(0:PING_OK), master:10.0.0.51
2.4.10故障シミュレーションと処理

（1）メインライブラリDB01を停止します。

[root@db01 ~]# /etc/init.d/mysqld stop

观察manager  日志 tail -f /var/log/mha/app1/manager
末尾必须显示successfully，才算正常切换成功。

（2）主なライブラリを修復

[root@db01 ~]# /etc/init.d/mysqld start

（3）メイン修復から

[root@db01 ~]# mysql -e "change master to master_host='10.0.0.52',master_user='repl',master_password='123' ,MASTER_AUTO_POSITION=1;"
[root@db01 ~]# mysql -e  "start slave;"
[root@db01 ~]# mysql -e  "show slave status \G"|grep Running:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

（4）コンフィギュレーションファイルを復元します

[root@db03 /etc/mha]# cat /etc/mha/app1.cnf 
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
password=mha
ping_interval=2
repl_password=123
repl_user=repl
ssh_user=root
user=mha
[server1]
hostname=10.0.0.51
port=3306

[server2]
hostname=10.0.0.52
port=3306

[server3]
hostname=10.0.0.53
port=3306

（5）スタートMHA

[root@db03 ~]# nohup masterha_manager --conf=/etc/mha/app1.cnf --remove_dead_master_conf --ignore_last_failover  < /dev/null> /var/log/mha/app1/manager.log 2>&1 &
    
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf

Managerは、追加のパラメータを紹介します

説明：
主なライブラリは引き継ぐために誰かダウンしているのですか？

  1. ノードからのすべてのログが同じで、デフォルトでは新しいマスターを選択するための設定ファイルの順になります。
  2. ノードからのログの矛盾は、自動的にライブラリからメインライブラリに最も近いを選択します
  3. 重みが設定されている場合（candidate_master = 1）、好ましいノードのノードに対する重み。
    しかし、主なライブラリーの背後にあるログノード100Mログのこの量は、それが選択されません。ログの量のブレンドcheck_repl_delay = 0、厳重な検査、強制的に選択候補ノードかもしれません。
(1)  ping_interval=1
# 设置监控主库，发送ping包的时间间隔，尝试三次没有回应的时候自动进行failover

(2) candidate_master=1
# 设置为候选master，如果设置该参数以后，发生主从切换以后将会将此从库提升为主库，即使这个主库不是集群中事件最新的slave

(3)check_repl_delay=0
#默认情况下如果一个slave落后master 100M的relay logs的话，MHA将不会选择该slave作为一个新的master，因为对于这个slave的恢复需要花费很长时间，通过设置check_repl_delay=0,MHA触发切换在选择一个新的master的时候将会忽略复制延时，这个参数对于设置了candidate_master=1的主机非常有用，因为这个候选主在切换的过程中一定是新的master

VIPのMHA機能

（1）準備VIPスクリプト

[root@db03 ~]# cp master_ip_failover.txt  /usr/local/bin/master_ip_failover
[root@db03 ~]# cd /usr/local/bin/
[root@db03 /usr/local/bin]# yum install -y dos2unix
[root@db03 /usr/local/bin]# dos2unix master_ip_failover 
[root@db03 /usr/local/bin]# chmod +x master_ip_failover

マネージャー構成ファイルを変更する（2）：

vi /etc/mha/app1.cnf

#添加：
master_ip_failover_script=/usr/local/bin/master_ip_failover

（3）ファイルの内容を変更します。

[root@db03 /usr/local/bin]# vim /usr/local/bin/master_ip_failover 

my $vip = '10.0.0.55/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";

メインデータベース上の（4）、手動で生成された第1のアドレスVIP

ハンドメインライブラリVIPにバインドされ、注意がのethnと構成ファイル一致していなければならない、私はeth0をした：（1が指定されたキー値です）1

ifconfig eth0:1 10.0.0.55/24

（5）再起動MHA

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

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

Eメール警告

（1）の設定オプションを追加

vi /etc/mha/app1.cnf
report_script=/usr/local/bin/send

（2）スクリプトのコピー

[root@db03 ~]# cp -a email/*  /usr/local/bin

（3）ストップMHA

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

（4）オープンMHA

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

（5）警告メッセージが表示され、メインのライブラリを閉じます

メインライブラリーが閉じられた後、それが自動的に警告メッセージを送信すると同時に、メインのライブラリを切り替えます。しかし、MHAが停止します、我々は再ビルドMHAに必要

binlogのサーバー（DB03）

（1）コンフィギュレーション情報を追加します

vim /etc/mha/app1.cnf 
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog

（2）は、必要なディレクトリを作成します

mkdir -p /data/mysql/binlog
chown -R mysql.mysql /data/*

（3）マスタデータベースログバイナリログを引っ張ります

注：ログを引っ張っするための出発点、現在のニーズに応じてポイントライブラリを起動バイナリログから取得されています

cd /data/mysql/binlog
mysqlbinlog  -R --host=10.0.0.51 --user=mha --password=mha --raw  --stop-never mysql-bin.000001 &

（4）再起動MHA

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

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

MHAのトラブルシューティング

MHAのステータスを確認

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

コンフィギュレーション・ファイルをチェックしてくださいMHA

[root@db03 ~]# vim /etc/mha/app1.cnf 
[server default]
manager_log=/var/log/mha/app1/manager
manager_workdir=/var/log/mha/app1
master_binlog_dir=/data/binlog
master_ip_failover_script=/usr/local/bin/master_ip_failover
password=mha
ping_interval=2
repl_password=123
repl_user=repl
report_script=/usr/local/bin/send
ssh_user=root
user=mha

[server1]
hostname=10.0.0.51
port=3306

[server2]
hostname=10.0.0.52
port=3306

[server3]
hostname=10.0.0.53
port=3306

[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/mysql/binlog

相互の信頼関係を確認してください3。

[root@db03 ~]# masterha_check_ssh --conf=/etc/mha/app1.cnf

スクリプトを確認してください4。

同時に、スクリプトの内容を確認する必要が正しいです

ls -l /usr/local/bin/
-rwxr-xr-x 1 root root  2166 Aug 20 15:45 master_ip_failover
-rwxr-xr-x 1 root root    35 Aug 20 15:51 send
-rwxr-xr-x 1 root root 80213 Aug 20 15:51 sendEmail
-rwxr-xr-x 1 root root   198 Aug 20 16:01 testpl

5.チェックbinlogserver

ps -ef| grep mysqlbinlog

6.ことを確認し、メインライブラリー、回復のbinlogログもの

db02 [(none)]>show master status


cd /data/mysql/binlog
rm -rf *
mysqlbinlog -R --host=10.0.0.52 --user=mha --password=mha --raw --stop-never mysql-bin.000005 &

メインライブラリVIPをチェック7.

ifconfig eth0:1 10.0.0.55/24
ifconfig

マスタとスレーブのステータスを確認する8.

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

9. [スタート] MHA

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

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

おすすめ

転載: www.cnblogs.com/lpcsf/p/12077328.html
おすすめ
ランキング
Tongyi Lingma Enterprise Edition は、プライベート ドメインの知識の検索、データ コンプライアンス、統合管理などの企業のニーズを満たすために正式にリリースされました。
Свойство «значение» не существует для типа «EventTarget» в vue3 (ts)
Фильтрация и картографирование потокового потока
アヒルを数える Python コード
python read csvcsvファイルの一部を新しいファイルに読み取ります
[スウィフト] LeetCode1281整数あなたの製品との違い|。整数の桁のプロダクトと和を減算
Huawei OD コンピュータベースの試験アルゴリズムの問題: ブロックチェーン ファイル ダンプ システム
BigDecimalの使い方
Python実装ハングマンゲーム
タイタニック（タイタニック生存予測）に生存
アーカイブ
もっと
2024-05-28(0)
2024-05-27(1)
2024-05-26(0)
2024-05-25(1)
2024-05-24(11)
2024-05-23(35)
2024-05-22(9)
2024-05-21(36)
2024-05-20(5)
2024-05-19(0)

コードワールド

© 2018 codetd.com