999免费网站传奇,个人网站备案电话访谈,网站制作网站建设项目规划书,wordpress电影下载站主题Day-12-数据库服务高可用集群 1、数据库MGR组复制实践2、数据库高可用MHA应用介绍3、数据库高可用MHA环境准备4、数据库高可用MHA原理机制5、数据库高可用MHA功能配置 1、数据库MGR组复制实践 #xff08;强一致性主从同步) 2、数据库高可用MHA应用介绍 3、数据库高可用MHA环境… Day-12-数据库服务高可用集群 1、数据库MGR组复制实践2、数据库高可用MHA应用介绍3、数据库高可用MHA环境准备4、数据库高可用MHA原理机制5、数据库高可用MHA功能配置 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 test192.168.30.101:3306 identified by 123456;5GTID主从复制 作用可以自动化的进行主从之间数据信息同步 原理可以根据GTID事务编号在从库和主库之间的binlog日志做比较随之可以获取同步位置点 配置
# 配置参数信息
gtid-modeon
-- 启用gtid复制方式默认采用传统的复制方式
enforce-gtid-consistencytrue
-- 开启gtid所有节点的强制一致性
log-slave-updates1
-- 定义slave更新是否记入二进制日志从而增强数据一致性是在高可用架构中重要配置环节change master to
master_auto_position1;
-- 表示让从库自己找寻复制同步数据的起点
-- 在第一次启动gtid功能时会读取从库中的binlog日志信息根据主库uuid信息获取从库中执行过的主库gtid信息
-- 从从库中没有执行过的主库gtid信息之后进行进行数据同步操作6MSR多源复制 作用可以将多个独立数据库数据进行整合便于对数据进行分析处理实现数据中台技术 原理在一个从库上可以开辟多个逻辑同步隧道实现和不同的主库进行数据同步 配置
master_auto_position1 for channel Master_1;
master_auto_position1 for channel Master_2;start slave for channel Master_1;
start slave for channel Master_2;7MGR组复制 作用可以实现主从同步的强一致性高可用 高扩展 原理
主从同步过程中具有仲裁机制可以实现所有事务是否全部数据都提交的判断机制可以实现故障转移
配置 MGR单主模式
loose-group_replication_group_nameeb8441e9-8aef-4a86-a4bc-5beea315f04f -- 定义多个成员的组名
loose-group_replication_start_on_bootOFF -- 是否自动开启组功能
(start group_replication;)
loose-group_replication_bootstrap_groupOFF -- 是否将指定节点自动设置为引导者1、数据库MGR组复制实践
MGR多主模式 方式一直接配置多主模式
# 在所有主机配置文件中
group_replication_single_primary_mode0
group_replication_enforce_update_everywhere_checks1# 激活MGR功能并生成组成员
# DB01 引导主机
set global group_replication_bootstrap_groupON;
start group_replication;
set global group_replication_bootstrap_groupOFF;# 其他主机DB02 DB03
start group_replication;方式二从单主模式切换为多主模式
group_replication_single_primary_mode0
-- 设置参数表示关闭掉单master模式
group_replication_enforce_update_everywhere_checks1
-- 这个参数设置表示多主模式下各个节点进行严格一致性检查# 多主模式功能配置在所有节点上执行
stop group_replication;
set global group_replication_single_primary_modeOFF;
set global group_replication_enforce_update_everywhere_checks1;
select group_replication_single_primary_mode,group_replication_enforce_update_everywhere_checks;
-- 检查参数配置信息是否生效set global group_replication_bootstrap_groupON;
start group_replication;
set global group_replication_bootstrap_groupOFF;
-- 引导数据库操作第一个群组主机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_modeOFF;
set global group_replication_enforce_update_everywhere_checksON;# 随便选择某个节点执行操作
set global group_replication_bootstrap_groupON;
start group_replication;
set global group_replication_bootstrap_groupOFF;# 其他节点执行
start group_replication;# 查看组信息所有节点的member_role 都为primary;
select * from performance_schema.replication_group_members;MGR复制同步功能运维管理
# MGR日常管理监控操作
select * from performance_schema.replication_group_members;
-- 根据命令信息输出获取各个节点主机的状态情况# MGR故障模拟操作过程
[rootxiaoQ-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.6minkeepalived双主架构但需要人为干预99.99%0.01%52.56minMHA ORCH TMHA具有自动监控自动切换自动数据补偿但还是属于半自动化 比较适合非金融类互联网公司 eg: facebook taobao前端-TMHA–polaradb99.999%0.001%5.256minPXC MGR MGC数据是高一致性 比较适合金融类互联网公司99.9999%0.0001%0.5256min自动化、云计算化、平台化仍然属于概念阶段
MHAMaster 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用于启动MHAmasterha_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识别差异的中继日志事件并将其差异的事件应用于其他slavepurge_relay_logs清除中继日志不会阻塞SQL线程
3、数据库高可用MHA环境准备
第一步进行数据库服务初始化
-- 清除原有实例
[rootdb01 ~]# systemctl stop mysqld.service
[rootdb01 ~]# ps -ef|grep mysql
[rootdb01 ~]# 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_id51
port3306
secure-file-priv/tmp
autocommit0
log_bin/data/3306/data/mysql-bin
binlog_formatrow
gtid-modeon
enforce-gtid-consistencytrue
log-slave-updates1
[mysql]
promptdb01 [\\d]
EOF# 从库db02配置文件编写
cat /etc/my.cnf EOF
[mysqld]
basedir/usr/local/mysql
datadir/data/3306/data
socket/tmp/mysql.sock
server_id52
port3306
secure-file-priv/tmp
autocommit0
log_bin/data/3306/data/mysql-bin
binlog_formatrow
gtid-modeon
enforce-gtid-consistencytrue
log-slave-updates1
[mysql]
promptdb02 [\\d]
EOF# 从库db03配置文件编写
cat /etc/my.cnf EOF
[mysqld]
basedir/usr/local/mysql
datadir/data/3306/data
socket/tmp/mysql.sock
server_id53
port3306
secure-file-priv/tmp
autocommit0
log_bin/data/3306/data/mysql-bin
binlog_formatrow
gtid-modeon
enforce-gtid-consistencytrue
log-slave-updates1
[mysql]
promptdb03 [\\d]
EOF-- 进行数据库所有节点初始化操作
mysqld --initialize-insecure --usermysql --basedir/usr/local/mysql --datadir/data/3306/data-- 启动数据库所有节点服务
systemctl start mysqld.service第二步进行MHA集群节点主从构建
# 重构主从关系-主库操作
db01 [(none)]create user repl10.0.0.% identified with mysql_native_password by 123456;
db01 [(none)]grant replication slave on *.* to repl10.0.0.%;
-- 主库上创建主从复制用户信息# 重构主从关系-从库操作
db02 [(none)]change master to
master_host10.0.0.51,
master_userrepl,
master_password123456,
master_auto_position1;
-- 表示让从库自己找寻复制同步数据的起点
-- 在第一次启动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 mha10.0.0.% identified with mysql_native_password by mha;
grant all privileges on *.* to mha10.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目录
usermha
-- 监控用户利用此用户连接各个节点做心跳检测主要是检测主库的状态
passwordmha
-- 监控密码
ping_interval2
-- 心跳检测的间隔时间
repl_password123456
-- 复制密码
repl_userrepl
-- 复制用户用于告知从节点通过新主同步数据信息的用户信息
ssh_userroot
-- ssh互信的用户可以利用互信用户从主库scp获取binlog日志信息便于从库进行数据信息补偿
[server1]
-- 节点信息....
hostname10.0.0.51
port3306
[server2]
hostname10.0.0.52
port3306
#candidate_master1
[server3]
hostname10.0.0.53
port3306
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
usermha
passwordmha
ping_interval2
repl_password123456
repl_userrepl
ssh_userroot
[server1]
hostname10.0.0.51
port3306
[server2]
hostname10.0.0.52
port3306
#candidate_master1
[server3]
hostname10.0.0.53
port3306
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 21 # 查看MHA状态
[rootdb03 ~]# 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 21 根据以上启动命令需要先调取MHA启动脚本文件masterha_manager 然后在调取加载MHA软件的配置文件--conf.../app1.cnf会根据加载的MHA的配置文件不同实现管理多个高可用架构环境进行高可用业务的架构环境的区分 --remove_dead_master_conf参数表示在主节点出现宕机情况时将会从集群中被踢出即从配置文件中删除掉故障节点 --ignore_last_failover 默认MHA服务是不能频繁进行故障切换的需要有一定的间隔时间加此参数表示忽略切换的间隔时间 最后将MHA启动运行的信息放入到日志文件中即可 /var/log/mha/app1/manager.log 21
02 MHA实现监控 利用MHA启动脚本文件masterha_manager会自动调用监控脚本文件masterha_master_monitor并且每隔配置文件指定时间 ping_interval2 进行脚本监控一次从而判断主节点是否处于存活状态连续4次还没有主库心跳即说明主库宕机 利用/usr/bin/masterha_master_monitor脚本真正连接指定主库进行操作识别主库运行状态
03 MHA选主过程 在MHA中进行选主时根据选主源码文件信息分析主要会利用到四个数组alive latest pref bad并且会识别节点编号信息 在进行选主时主要会关注竞选新主节点的日志量、以及是否设置candidate_master参数配置信息
数组信息简述作用说明alive存活数组主要用于探测存活的节点状态当主库宕机后探测的就是两个从库节点latest最新数组表示获取日志最新的从库信息即数据量最接近主库的从库根据GTID信息 或 position信息pref备选数组在数组中具有candidate_master参数判断条件此参数可以放入配置文件节点中便于节点优先选择为新主bad不选数组如果设定了参数no_master1表示相应节点不参与竞选主 如果设定了参数log_bin0二进制日志没开表示相应节点不参与竞选主 如何设定了参数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_master1参数 该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所需的脚本文件
[rootxiaoQ-03 ~]# cd /usr/local/bin/
[rootxiaoQ-03 bin]# chmod x /usr/local/bin/*# 修改MHA脚本文件的信息
[rootxiaoQ-03 bin]# cp master_ip_failover master_ip_failover.bak
[rootxiaoQ-03 bin]# dos2unix /usr/local/bin/*
[rootxiaoQ-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;# 修改配置文件
[rootxiaoQ-03 ~]# vim /etc/mha/app1.cnf
master_ip_failover_script/usr/local/bin/master_ip_failover# 手工在主库上添加VIP
[rootxiaoQ-03 bin]# masterha_check_status --conf/etc/mha/app1.cnf
app1 (pid:103046) is running(0:PING_OK), master:192.168.30.101
-- 核实此时的MHA的主库节点
[rootxiaoQ-03 bin]# ifconfig eth0:1 10.0.0.50/24
-- 在主库节点手工添加vip地址信息# 重启MHA服务
[rootxiaoQ-03 bin]# masterha_stop --conf/etc/mha/app1.cnf
[rootxiaoQ-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 21 # 进行VIP地址连接测试
-- 可以使用navcat软件连接MHA的vip地址查看所连主机信息是否为主节点当故障转移后可以核实VIP地址是否持续连接说明进行MHA的VIP地址漂移时只能在局域网环境进行漂移不能实现跨网段的VIP地址漂移 07 MHA故障报警 实现MHA的报警功能利用脚本实现上传mha_script.tar文件到/usr/local/bin目录中然后进行解压处理
# 准备脚本文件
[rootxiaoQ-03 bin]# cp send_report send_report.bak
28 my $smtpsmtp.qq.com;
-- smtp服务器地址域名
29 my $mail_from330882721qq.com;
-- 发件箱信息配置
30 my $mail_user330882721;
-- 用户名 QQ号
31 my $mail_passypokkranqlgkcbba;
-- 邮箱授权码
32 my $mail_to330882721qq.com;
or
my $mail_to[to1qq.com,to2qq.com];
-- 收件箱信息配置# 修改配置文件
[rootxiaoQ-03 ~]# vim /etc/mha/app1.cnf
report_script/usr/local/bin/send_report# 重启MHA服务
[rootxiaoQ-03 bin]# masterha_stop --conf/etc/mha/app1.cnf
[rootxiaoQ-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 21 08 MHA额外补偿 利用binlog_server作为额外的日志补偿的冗余方案即实时保存主库的bin_log日志文件到特定节点目录中
-- 在MHA管理节点创建
# 创建日志存放目录
[rootxiaoQ-03 ~]# mkdir -p /data/binlog_server/
[rootxiaoQ-03 ~]# chown -R mysql.mysql /data/*
[rootxiaoQ-03 ~]# cd /data/binlog_server
[rootxiaoQ-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
-- 拉取日志的起点需要按照目前从库的已经获取到的二进制日志点为起点
[rootxiaoQ-03 binlog_server]# nohup mysqlbinlog -R --host10.0.0.51 --usermha --passwordmha --raw --stop-never mysql-bin.000004 # 编写配置文件信息
[rootdb03 binlog_server]# vim /etc/mha/app1.cnf
[binlog1]
no_master1
hostname10.0.0.53
master_binlog_dir/data/binlog_server/# 重启MHA服务
[rootdb03 binlog_server]# masterha_stop --conf/etc/mha/app1.cnf
[rootdb03 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 21
[rootdb03 binlog_server]# masterha_check_status --conf/etc/mha/app1.cnf
