1、数据损坏的类型

  1. 物理损坏: 磁盘、主机、程序、数据文件
  2. 逻辑损坏: drop ..

2、高级应用架构演变

2.1、高性能架构

无故障时间           故障时间                     解决方案
99.9%                0.1%     = 525.6  min        Kepplived + 双主: 人为干预 
99.99%               0.01%    = 52.56  min        MHA: 半自动化  
应用场景: 比较适合非金融类互联网公司, 替代产品: ORCH
99.999%              0.001%   = 5.256  min        PXC 、 MGR 、MGC
应用场景: 金融类业务
99.9999%             0.0001%  = 0.5256 min        自动化、云化、平台化

2.2、高可用架构

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

3、MHA架构环境介绍

3.1、HAM架构介绍

1. 不能使用双主结构, 采用1主2从
2. 最好使用GTID主从复制
3. 部署MHA高可用架构
  Manager软件: 理论上单独找一台机器安装, (本机实验选择一个从节点安装)
  Node软件: 所有节点都要安装

3.2、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 组件

save_binary_logs      : 保存和复制master的二进制日志 
apply_diff_relay_logs : 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs      : 清除中继日志 (不会阻塞SQL线程)

4、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. 自愈自治 (待开发...)

张种恩技术小站
https://www.zze.xyz
阿里云搭建MHA踩坑
https://www.cnblogs.com/galengao/p/7417520.html