Day12-数据库服务冗余架构

1、数据库MGR组复制实践 （强一致性主从同步)
2、数据库高可用MHA应用介绍
3、数据库高可用MHA环境准备
4、数据库高可用MHA原理机制
5、数据库高可用MHA功能配置
6、数据库高可用MHA故障切换
7、数据库高可用MHA故障修复 （一次性高可用）
8、数据库高可用MHA日常维护

主从涉及的扩展知识：
1）延时从库
作用：在主库出现逻辑数据损坏，可以更快速修复数据
原理：阻塞从库SQL线程回放的时间
配置：

stop slave sql_thread;
CHANGE REPLICATION FILTER REPLICATE_DO_DB = (word, ppt);
start slave sql_thread;

2）过滤复制
作用：在主从同步数据时，从库过滤掉不想同步的数据（不想主库所有数据都同步）
原理：
1）在从库上限制SQL线程，回放语句信息
2）在主库限制binlog日志记录信息（限制binlog记录信息）
配置：

# 查看从库复制过滤限制参数信息
mysql> show slave status\G
*************************** 1. row ***************************
Replicate_Do_DB: xiaoQ
Replicate_Ignore_DB: xiaoA
-- 表示库级别的过滤操作，白名单设置表示回放库级别操作，黑名单设置表示忽略库级别操作Replicate_Do_Table: xiaoQ.t1
Replicate_Ignore_Table: xiaoA.t1
-- 表示表级别的过滤操作，白名单设置表示回放表级别操作，黑名单设置表示忽略表级别操作Replicate_Wild_Do_Table: xiaoQ.t*
Replicate_Wild_Ignore_Table: xiaoA.t*
-- 表示模糊级别的过滤操作，主要是可以针对多表信息，配置白名单或黑名单；   
-- 以上在从库上线实现数据同步过滤机制的参数信息有6个，主要可以分为3组，一般应用使用一个参数即可；mysql> stop slave sql_thread;
mysql> CHANGE REPLICATION FILTER REPLICATE_DO_DB = (word, ppt);
mysql> start slave sql_thread;

3）半同步复制
作用：提高了主从同步的一致性（保证了主库的信息能发送到从库）
原理：主库需要接收到从库的确认信息，才能保证事务正常提交（超过时间，也会采用异步方式提交）
配置：

# 主库安装半同步插件（3307）
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
-- 主库利用插件控制ack_receiver线程接收ack确认信息，并且会控制commit阻塞，实现半同步复制功能
# 从库安装半同步插件（3309）
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
-- 从库利用插件控制IO线程发送ack确认信息；# 主库启动半同步功能
mysql> set global rpl_semi_sync_master_enabled =1;
# 从库启动半同步功能
mysql> set global rpl_semi_sync_slave_enabled =1;# 重启从库上的IO线程
mysql> stop slave IO_THREAD;
mysql> start slave IO_THREAD;# 核实确认半同步功能状态：
mysql> show status like 'rpl_semi_sync_master_status';

4）克隆复制
作用：可以实现历史主库有海量数据同步时，可以采用克隆机制恢复大量数据（数据库上云操作）
原理：可以实现同步数据目录信息（两个数据库数据目录的无差异同步）
配置：

INSTALL PLUGIN clone SONAME 'mysql_clone.so';
create user test@'%' identified by '123456';grant backup_admin on *.* to 'test'@'%'; -- 管理要克隆的主机数据 
create user test@'%' identified by '123456';grant clone_admin on *.* to 'test'@'%'; -- 控制克隆主机的clone instance from test@'192.168.30.101':3306 identified by '123456';

5）GTID主从复制
作用：可以自动化的进行主从之间数据信息同步
原理：可以根据GTID事务编号，在从库和主库之间的binlog日志做比较，随之可以获取同步位置点
配置：

# 配置参数信息
gtid-mode=on
-- 启用gtid复制方式，默认采用传统的复制方式
enforce-gtid-consistency=true
-- 开启gtid所有节点的强制一致性
log-slave-updates=1
-- 定义slave更新是否记入二进制日志，从而增强数据一致性，是在高可用架构中重要配置环节change master to
master_auto_position=1;
-- 表示让从库自己找寻复制同步数据的起点；
-- 在第一次启动gtid功能时，会读取从库中的binlog日志信息，根据主库uuid信息，获取从库中执行过的主库gtid信息
-- 从从库中没有执行过的主库gtid信息之后进行进行数据同步操作

6）MSR多源复制
作用：可以将多个独立数据库数据进行整合，便于对数据进行分析处理（实现数据中台技术）
原理：在一个从库上，可以开辟多个逻辑同步隧道，实现和不同的主库进行数据同步
配置：

master_auto_position=1 for channel 'Master_1';
master_auto_position=1 for channel 'Master_2';start slave for channel 'Master_1';
start slave for channel 'Master_2';

7）MGR组复制
作用：可以实现主从同步的强一致性（高可用 高扩展）
原理：

• 主从同步过程中，具有仲裁机制，可以实现所有事务是否全部数据都提交的判断机制
• 可以实现故障转移，

配置：
MGR单主模式

loose-group_replication_group_name="eb8441e9-8aef-4a86-a4bc-5beea315f04f"  -- 定义多个成员的组名
loose-group_replication_start_on_boot=OFF  -- 是否自动开启组功能
(start group_replication;)
loose-group_replication_bootstrap_group=OFF -- 是否将指定节点自动设置为引导者

1、数据库MGR组复制实践

MGR多主模式：
方式一：直接配置多主模式

# 在所有主机配置文件中：
group_replication_single_primary_mode=0
group_replication_enforce_update_everywhere_checks=1# 激活MGR功能，并生成组成员
# DB01 引导主机
set global group_replication_bootstrap_group=ON;
start group_replication;
set global group_replication_bootstrap_group=OFF;# 其他主机DB02 DB03
start group_replication;

方式二：从单主模式切换为多主模式

group_replication_single_primary_mode=0
-- 设置参数表示关闭掉单master模式
group_replication_enforce_update_everywhere_checks=1
-- 这个参数设置表示多主模式下，各个节点进行严格一致性检查# 多主模式功能配置（在所有节点上执行）
stop group_replication;
set global group_replication_single_primary_mode=OFF;
set global group_replication_enforce_update_everywhere_checks=1;
select @@group_replication_single_primary_mode,@@group_replication_enforce_update_everywhere_checks;
-- 检查参数配置信息是否生效set global group_replication_bootstrap_group=ON;
start group_replication;
set global group_replication_bootstrap_group=OFF;
-- 引导数据库操作（第一个群组主机）start group_replication;
-- 其他群组主机重新加入群组，自动成为主库select * from performance_schema.replication_group_members;
-- 查看集群节点状态信息，以及集群成员信息，此时所有节点成员都变为主库（实现多主模式）
db03 [(none)]>select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | cb5ceaa4-7243-11ef-b4bd-000c29978564 | 10.0.0.51   |        3306 | ONLINE       | PRIMARY     | 8.0.26         |
| group_replication_applier | cbbe48ad-7243-11ef-b219-000c293e27f0 | 10.0.0.53   |        3306 | ONLINE       | PRIMARY     | 8.0.26         |
| group_replication_applier | cbe48e48-7243-11ef-b388-000c291290fe | 10.0.0.52   |        3306 | ONLINE       | PRIMARY     | 8.0.26         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.01 sec)

完成上面的配置后就可以执行多点写入了，多点写入会存在冲突检查，这对数据库性能耗损是挺大的，官方建议采用网络区分功能，
在程序端把相同的业务定位到同一节点，尽量减少冲突发生的几率；

# 停止组复制功能（在所有节点执行）
stop group_replication;
set global group_replication_single_primary_mode=OFF;
set global group_replication_enforce_update_everywhere_checks=ON;# 随便选择某个节点执行操作
set global group_replication_bootstrap_group=ON;
start group_replication;
set global group_replication_bootstrap_group=OFF;# 其他节点执行
start group_replication;# 查看组信息，所有节点的member_role 都为primary;
select * from performance_schema.replication_group_members;

MGR复制同步功能运维管理：

# MGR日常管理监控操作：
select * from performance_schema.replication_group_members;
-- 根据命令信息输出，获取各个节点主机的状态情况；# MGR故障模拟操作过程：
[root@xiaoQ-01 ~]# /etc/init.d/mysqld stop
db02 [(none)]>select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 0a09b03e-7b95-11ed-9af8-000c29f5669f | 192.168.30.103 |       13306 | ONLINE       | PRIMARY     | 8.0.26         |
| group_replication_applier | fe73f0b4-7b94-11ed-96ea-000c2961cd06 | 192.168.30.102 |       13306 | ONLINE       | SECONDARY   | 8.0.26         |
+---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)
-- 模拟主节点宕掉，会自动选举新的主节点

总结：利用MGR可以构建主从架构 高可用集群**** 灵活扩展或减少节点（不能少于3个节点）信息

应用限制说明：
在应用MGR组复制功能时，也存在一些应用的限制条件：

• 仅支持innodb存储引擎应用组复制功能；
  MGR集群中只支持innodb存储引擎，能够创建非innodb引擎的表，但是无法写入数据，向非innodb表写入数据直接报错；
• 数据表中必须有主键，或者非null的唯一键；
  MGR集群中只支持innodb存储引擎，并且该表必须有显示的主键，或者非null的唯一键，否则即使能够创建表，也无法向表中写数据
• 组复制存在网络限制，MGR组通信引擎目前仅支持IPv4网络，并且对节点间的网络性能要求较高；
  对于低延迟、高带宽的网络是部署MGR集群的基础；
• 组复制功能会自动忽略表锁和命名锁，在MGR中lock tables、unlock tables、get_lock、release_lock等这些表锁和命名锁将忽略
• MGR多主模式中，默认不支持 SERIALIZABLE 隔离级别，建议使用RC隔离级别；
• 组复制多主模式中，对同一个对象进行并发是有冲突的，ddl和dml操作导致这种冲突在部分成员节点中无法检测到；
  最终可能导致数据不一致
• 组复制多主模式中，不支持级联约束的外键，可能造成有冲突的操作无法检查；
• 组复制功能不支持超大事务同步；
• 组复制多主模式下可能导致死锁，比如select … for update在不同节点执行，由于多节点锁无法共享，很容易导致死锁；
• 组复制是不支持复制过滤的，如果有节点设置了复制过滤功能，将影响节点间决议的达成；
• 组复制功能最多支持9个节点，当大于9个节点，将拒绝新节点的加入；

2、数据库高可用MHA应用介绍

数据库中的高可用功能，主要是用于避免数据库服务或数据信息的损坏问题，其中数据损坏的类型有：

• 数据物理损坏：磁盘、主机、程序实例、数据文件误删除
• 数据逻辑损坏：drop update …

其中，数据库高可用技术的出现主要解决的是物理损坏/逻辑损坏的业务中断问题，而主从架构技术主要解决的是数据物理损坏问题；
数据库高可用解决方案选型依据：（全年无故障率）

无故障率	故障时间	解决方案
99.9%	0.1%（525.6min）	keepalived+双主架构，但需要人为干预
99.99%	0.01%（52.56min）	MHA ORCH TMHA，具有自动监控，自动切换，自动数据补偿，但还是属于半自动化 比较适合非金融类互联网公司 eg: facebook taobao前端-TMHA–>polaradb
99.999%	0.001%（5.256min）	PXC MGR MGC，数据是高一致性 比较适合金融类互联网公司
99.9999%	0.0001%（0.5256min）	自动化、云计算化、平台化，仍然属于概念阶段

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton研发，
此人目前就职于Facebook公司，MHA是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。
MySQL进行故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换过程中；
MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

MHA主要有两部分组成：
MHA Manager（管理节点）
可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。

MHA Node（数据节点）
运行在每台MySQL服务器上
MHA Manager 会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master；
然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序是完全透明的；
MHA软件结构介绍：（MHA中的所有组件就是perl语言编写的功能脚本）

节点信息	软件组件	作用介绍
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信息
MHA Node（数据节点）	save_binary_logs	保存和复制master的二进制日志
	apply_diff_relay_logs	识别差异的中继日志事件并将其差异的事件应用于其他slave
	purge_relay_logs	清除中继日志（不会阻塞SQL线程）

3、数据库高可用MHA环境准备

第一步：进行数据库服务初始化

-- 清除原有实例
[root@db01 ~]# systemctl stop mysqld.service 
[root@db01 ~]# ps -ef|grep mysql
[root@db01 ~]# rm -rf /data/3306/data/*-- 编写配置文件
# 主库db01配置文件编写
cat >/etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/data/3306/data
socket=/tmp/mysql.sock
server_id=51
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/3306/data/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db01 [\\d]>
EOF# 从库db02配置文件编写
cat >/etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/data/3306/data
socket=/tmp/mysql.sock
server_id=52
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/3306/data/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db02 [\\d]>
EOF# 从库db03配置文件编写
cat >/etc/my.cnf <<EOF
[mysqld]
basedir=/usr/local/mysql
datadir=/data/3306/data
socket=/tmp/mysql.sock
server_id=53
port=3306
secure-file-priv=/tmp
autocommit=0
log_bin=/data/3306/data/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[mysql]
prompt=db03 [\\d]>
EOF-- 进行数据库所有节点初始化操作
mysqld --initialize-insecure --user=mysql --basedir=/usr/local/mysql --datadir=/data/3306/data-- 启动数据库所有节点服务
systemctl start mysqld.service

第二步：进行MHA集群节点主从构建

# 重构主从关系-主库操作
db01 [(none)]>create user repl@'10.0.0.%' identified with mysql_native_password by '123456';
db01 [(none)]>grant replication slave on *.* to repl@'10.0.0.%';
-- 主库上创建主从复制用户信息# 重构主从关系-从库操作
db02 [(none)]>change master to
master_host='10.0.0.51',
master_user='repl',
master_password='123456',
master_auto_position=1;
-- 表示让从库自己找寻复制同步数据的起点；
-- 在第一次启动gtid功能时，会读取从库中的binlog日志信息，根据主库uuid信息，获取从库中执行过的主库gtid信息
-- 从从库中没有执行过的主库gtid信息之后进行进行数据同步操作
db02 [(none)]> start slave;
-- 其他从库一并操作

第三步：安装部署MHA软件程序/与程序配置

# 创建程序命令软链接
ln -s /usr/local/mysql/bin/mysqlbinlog /usr/bin/mysqlbinlog
ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql
-- 所有节点均执行以上操作，因为MHA程序加载数据库命令，会默认在/usr/bin下面进行加载（会影响数据补偿和监控功能）# 配置各节点互信
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
ssh 10.0.0.51 date
ssh 10.0.0.52 date
ssh 10.0.0.53 date
-- 各节点验证# MHA安装软件程序 
yum install perl-DBD-MySQL -y
cd /usr/local
rpm -ivh mha4mysql-node-0.58-0.el7.centos.noarch.rpm 
-- 所有节点安装Node软件依赖包
yum install -y perl-Config-Tiny epel-release perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
yum install -y mha4mysql-manager-0.58-0.el7.centos.noarch.rpm 
-- Manager软件安装（db03）# 在db01主库中创建mha需要的用户
create user mha@'10.0.0.%' identified with mysql_native_password by 'mha';
grant all privileges on *.* to mha@'10.0.0.%';
-- 在主库创建完毕后，主从复制功能，核实所有从库也都有mha用户信息# Manager配置文件准备(db03)
mkdir -p /etc/mha
-- 创建配置文件目录
mkdir -p /var/log/mha/app1
-- 创建日志目录cat > /etc/mha/app1.cnf <<EOF
[server default]
manager_log=/var/log/mha/app1/manager         
-- MHA的工作日志设置
manager_workdir=/var/log/mha/app1             
-- MHA的工作目录        
master_binlog_dir=/data/binlog                
-- 主库的binlog目录
user=mha                                      
-- 监控用户，利用此用户连接各个节点，做心跳检测（主要是检测主库的状态）                
password=mha                                  
-- 监控密码
ping_interval=2                              
-- 心跳检测的间隔时间
repl_password=123456                             
-- 复制密码
repl_user=repl                                
-- 复制用户（用于告知从节点通过新主同步数据信息的用户信息）
ssh_user=root                                
-- ssh互信的用户（可以利用互信用户从主库scp获取binlog日志信息，便于从库进行数据信息补偿）
[server1]                                     
-- 节点信息....
hostname=10.0.0.51
port=3306                                  
[server2]            
hostname=10.0.0.52
port=3306
#candidate_master=1
[server3]
hostname=10.0.0.53
port=3306
EOF
-- 编辑mha配置文件cat > /etc/mha/app1.cnf <<EOF
[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=123456
repl_user=repl
ssh_user=root
[server1]
hostname=10.0.0.51
port=3306                                  
[server2]            
hostname=10.0.0.52
port=3306
#candidate_master=1
[server3]
hostname=10.0.0.53
port=3306
EOF

第四步：进行环境准备测试/运行MHA程序

# MHA状态检查（db03）
masterha_check_ssh   --conf=/etc/mha/app1.cnf 
Wed Dec 28 20:54:42 2022 - [info] All SSH connection tests passed successfully.
-- 在MHA管理节点，进行ssh互信功能检查，并且显示成功表示检查通过
masterha_check_repl  --conf=/etc/mha/app1.cnf 
MySQL Replication Health is OK.
-- 在MHA管理节点，检查主从关系与配置文件信息是否正确# 开启MHA-manager
开启MHA(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 &# 查看MHA状态
[root@db03 ~]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:1931) is running(0:PING_OK), master:10.0.0.51
-- 显示以上提示信息，表示MHA基础环境搭建成功了，但还不能在生产环境使用，还需要有后续的操作配置

4、数据库高可用MHA原理机制

在熟悉高可用服务工作原理前，可以先思考下应用高可用服务可以解决哪些需求，或者也可以理解为解决哪些痛点：
① 如何在高可用架构中，当主库宕机异常后，使之及时的发现主库服务程序产生了运行异常？
​ 解决此痛点问题，需要实现高可用的监控需求；
② 如何在高可用架构中，当主库宕机异常后，可以找到可以替代主库的服务器主机进行切换？
​ 解决此痛点问题，需要实现高可用的选主功能；（并且选择数据量越接近主库的从库成为新主）
③ 如何在高可用架构中，当主库宕机异常后，新的主库接管后可以保证与原有主库数据一致？
​ 解决此痛点问题，需要实现高可用的数据补偿；
④ 如何在高可用架构中，当主库宕机异常后，将应用程序的读写请求对接切换到新的主库上？
​ 解决此痛点问题，需要实现高可用的应用透明；（VIP技术）
⑤ 如何在高可用架构中，当主库宕机异常后，能够及时向管理员发起告知提醒使之进行修复？(MHA切换是一次性的)
​ 解决此痛点问题，需要实现高可用的报警功能；
⑥ 如何在高可用架构中，当主库宕机异常后，当整体主库系统环境都异常时实现数据的补偿？
​ 解决此痛点问题，需要实现高可用的额外补偿；
⑦ 如何在高可用架构中，当主库宕机异常后，根据主库服务器的异常情况进行原有主库修复？
​ 解决此痛点问题，需要实现高可用的自愈功能；（待开发，只有云平台RDS具有此功能）

5、数据库高可用MHA功能配置

01 MHA软件启动
根据启动命令，分析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 &

根据以上启动命令，需要先调取MHA启动脚本文件masterha_manager ，然后在调取加载MHA软件的配置文件--conf=.../app1.cnf会根据加载的MHA的配置文件不同，实现管理多个高可用架构环境，进行高可用业务的架构环境的区分；
--remove_dead_master_conf参数表示在主节点出现宕机情况时，将会从集群中被踢出，即从配置文件中删除掉故障节点；
--ignore_last_failover 默认MHA服务是不能频繁进行故障切换的，需要有一定的间隔时间，加此参数表示忽略切换的间隔时间；
最后将MHA启动运行的信息放入到日志文件中即可 /var/log/mha/app1/manager.log 2>&1

02 MHA实现监控
利用MHA启动脚本文件masterha_manager会自动调用监控脚本文件masterha_master_monitor，并且每隔配置文件指定时间；
ping_interval=2 进行脚本监控一次，从而判断主节点是否处于存活状态，连续4次还没有主库心跳，即说明主库宕机；
利用/usr/bin/masterha_master_monitor脚本，真正连接指定主库，进行操作，识别主库运行状态

03 MHA选主过程
在MHA中进行选主时，根据选主源码文件信息分析，主要会利用到四个数组：alive latest pref bad，并且会识别节点编号信息；
在进行选主时，主要会关注竞选新主节点的日志量、以及是否设置candidate_master参数配置信息；

数组信息	简述	作用说明
alive	存活数组	主要用于探测存活的节点状态；当主库宕机后，探测的就是两个从库节点
latest	最新数组	表示获取日志最新的从库信息，即数据量最接近主库的从库（根据GTID信息 或 position信息）
pref	备选数组	在数组中具有candidate_master参数判断条件，此参数可以放入配置文件节点中，便于节点优先选择为新主
bad	不选数组	如果设定了参数：no_master=1，表示相应节点不参与竞选主； 如果设定了参数：log_bin=0（二进制日志没开），表示相应节点不参与竞选主； 如何设定了参数：check_slave_delay，检查从库延迟主库100M数据信息日志量，表示节点不参与竞选主

MHA选主判断总结（利用if判断选主的情况）

• 循环对比latest数组和pref数组的slave，如果存在相同的slave，并且这个slave不在bad数组当中，该slave会被推选为新的master
  DB02节点即满足latest数组信息，又满足perf数组信息，但不满足bad数据信息，即会被选为新主，有多个按照号码顺序选举；
• 如果pref和bad数组当中的个数为0，则选择latest数组当中的第一个slave为master；
  DB02节点没有candidate_master参数配置，又没有不选数组里的三种情况配置，即db02恰好是latest，为新主；
• 循环对比alive数组和pref数组当中的slaves，如果有一个slave相同，并且不在bad数组当中，该节点就会成为新的master；
  DB02节点即不满足latest，也不满足bad，但是满足pref，也会被选择作为新主；
• 循环latest数组，如果又循环到slave不在bad数组当中，这个slave就会成为master，就算添加了candidate_master=1参数；
  该slave也不一定会成为主库；
  DB02节点即满足latest数组，不是bad数组，也会成为新的主；
• 从活着的slave当中进行循环，如果循环到slave不在bad数组当中，那么这个slave就会成为主库；
  DB02节点是活着的，不满足bad，也可以成为新的主；
• 如果进行了多次选择都找不到主库，那么主库选择失败，failover失败；

选主策略简述表：

优先级	alive数组	latest数组	pref数组	bad数组	选主策略	多个选择情况
01	满足	满足	满足	不满足	优选选择	按照节点号码顺序选择
02	满足	满足	不满足	不满足	优选选择	按照节点号码顺序选择
03	满足	不满足	满足	不满足	优选选择	按照节点号码顺序选择
04	满足	不满足	不满足	不满足	优选活着节点	按照节点号码顺序选择

说明：在进行手工指定切换新主时，即应用了prio_new_master_host参数信息时，会最优先选择相应节点为新主；

04 MHA数据补偿
在进行数据补偿之前，需要让新主库与原有宕机主库进行对比，获悉需要补偿的数据量情况，即对比差的数据日志量信息；
然后可以从binlog日志中，进行补充数据信息的截取，随之进行数据信息补偿，但是有种特殊情况，若原有主库无法访问了；
所以进行数据补偿操作，也需要分各种情景进行处理：

• 原主库SSH连接正常：
  各个从节点自动调用：save_binary_logs脚本文件，立即保存缺失部分的bin_log，到各节点/var/tmp/目录；
• 原主库SSH连接异常：
  各个从节点自动调用：apply_diff_relay_logs脚本文件，进行relay_log日志差异信息补偿；
• 额外特殊数据补充：（利用主库日志冗余机制）
  MHA提供了binlog_server功能，可以实时拉取主库的binlog日志到备份节点，从而进行数据额外补偿；

05 MHA业务切换（主从关系切换）
选举结束，其他从库会重置主从关系，选择新主同步数据

# 所有从库解除主从关系操作
stop slave;
reset slave;# 所有从库重构主从关系操作
change master to ...

06 MHA应用透明
实现MHA的VIP功能，利用脚本实现，上传mha_script.tar文件到/usr/local/bin目录中，然后进行解压处理；

# 上传MHA所需的脚本文件
[root@xiaoQ-03 ~]# cd /usr/local/bin/
[root@xiaoQ-03 bin]# chmod +x /usr/local/bin/*# 修改MHA脚本文件的信息
[root@xiaoQ-03 bin]# cp master_ip_failover master_ip_failover.bak
[root@xiaoQ-03 bin]# dos2unix /usr/local/bin/*
[root@xiaoQ-03 bin]# vim master_ip_failover
13 my $vip = '192.168.30.110/24';
14 my $key = '1';
15 my $if = 'eth0';
16 my $ssh_start_vip = "/sbin/ifconfig $if:$key $vip";
17 my $ssh_stop_vip = "/sbin/ifconfig $if:$key down";
18 my $ssh_Bcast_arp= "/sbin/arping -I $if -c 3 -A 192.168.30.110";# 修改配置文件
[root@xiaoQ-03 ~]# vim /etc/mha/app1.cnf
master_ip_failover_script=/usr/local/bin/master_ip_failover# 手工在主库上添加VIP
[root@xiaoQ-03 bin]# masterha_check_status --conf=/etc/mha/app1.cnf
app1 (pid:103046) is running(0:PING_OK), master:192.168.30.101
-- 核实此时的MHA的主库节点
[root@xiaoQ-03 bin]# ifconfig eth0:1 10.0.0.50/24
-- 在主库节点手工添加vip地址信息# 重启MHA服务
[root@xiaoQ-03 bin]# masterha_stop --conf=/etc/mha/app1.cnf
[root@xiaoQ-03 bin]# 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 &# 进行VIP地址连接测试
-- 可以使用navcat软件，连接MHA的vip地址，查看所连主机信息是否为主节点，当故障转移后可以核实VIP地址是否持续连接；

说明：进行MHA的VIP地址漂移时，只能在局域网环境进行漂移，不能实现跨网段的VIP地址漂移；

07 MHA故障报警
实现MHA的报警功能，利用脚本实现，上传mha_script.tar文件到/usr/local/bin目录中，然后进行解压处理；

# 准备脚本文件
[root@xiaoQ-03 bin]# cp send_report send_report.bak
28 my $smtp='smtp.qq.com';
-- smtp服务器地址域名
29 my $mail_from='[e-mail]';
-- 发件箱信息配置
30 my $mail_user='330882721';
-- 用户名 QQ号
31 my $mail_pass='ypokkranqlgkcbba';
-- 邮箱授权码
32 my $mail_to='[e-mail]';
or
my $mail_to=['[e-mail]','[e-mail]'];
-- 收件箱信息配置# 修改配置文件
[root@xiaoQ-03 ~]# vim /etc/mha/app1.cnf
report_script=/usr/local/bin/send_report# 重启MHA服务
[root@xiaoQ-03 bin]# masterha_stop --conf=/etc/mha/app1.cnf
[root@xiaoQ-03 bin]# 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 &

08 MHA额外补偿
利用binlog_server作为额外的日志补偿的冗余方案，即实时保存主库的bin_log日志文件到特定节点目录中；

-- 在MHA管理节点创建
# 创建日志存放目录
[root@xiaoQ-03 ~]# mkdir -p /data/binlog_server/
[root@xiaoQ-03 ~]# chown -R mysql.mysql /data/*
[root@xiaoQ-03 ~]# cd /data/binlog_server
[root@xiaoQ-03 binlog_server]# mysql -e "show slave status\G"|grep "Master_Log"
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 1201
Relay_Master_Log_File: mysql-bin.000002
Exec_Master_Log_Pos: 1201
-- 拉取日志的起点，需要按照目前从库的已经获取到的二进制日志点为起点
[root@xiaoQ-03 binlog_server]# nohup mysqlbinlog -R --host=10.0.0.51 --user=mha --password=mha --raw --stop-never mysql-bin.000004 &# 编写配置文件信息
[root@db03 binlog_server]# vim /etc/mha/app1.cnf
[binlog1]
no_master=1
hostname=10.0.0.53
master_binlog_dir=/data/binlog_server/# 重启MHA服务
[root@db03 binlog_server]# masterha_stop --conf=/etc/mha/app1.cnf
[root@db03 binlog_server]# 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 binlog_server]# masterha_check_status --conf=/etc/mha/app1.cnf