zoukankan      html  css  js  c++  java
  • MHA原理分析

    mysql复制是个异步过程,当主库上的日志还没来及传到从库上时主库发生crash容易导致主从数据不一致,例如mysql crash,os crash,掉电等,这时便引出了MHA技术。

    安装基本环境介绍:一主一从

    Mha manager & slave test2 192.168.1.115
    Master test1 192.168.1.114
    vip   192.168.1.100

    思考:MHA manager 为什么要放到slave上。

    为实验方便将防火墙关闭:

    [root@test1 ~]# service iptables stop && setenforce 0

    [root@test2 ~]# service iptables stop && setenforce 0

    1.两台服务器建立key信任:

    [root@test1 ~]# ssh-keygen 

    [root@test1 ~]# cd ~/.ssh/

    [root@test1 .ssh]# cat id_rsa.pub >> authorized_keys              

    [root@test1 .ssh]# chmod  600 *

    [root@test1 .ssh]# scp * 192.168.1.115:/root/.ssh/

    2.创建复制账号和mha_manager监控账号:

    root@test1:mysql3306.sock [(none)]>grant replication slave on *.* to 'zhangshuo' identified by 'zhangshuo';

    root@test1:mysql3306.sock [(none)]>grant all privileges on *.* to 'mysql'@'%' identified by 'mysql';

    root@test1:mysql3306.sock [(none)]>flush privileges;

    3.搭建主从复制结构。

    4.使用epel源解决依赖关系:yum install epel-release -y , yum -y localinstall  mha4mysql-node-0.56-0.el6.noarch.rpm mha4mysql-manager-0.56-0.el6.noarch.rpm,在一主一从的结构中建议两个节点都要安装manager,node包。安装文件可从https://code.google.com/p/mysql-master-ha/wiki/Downloads下载。

    5.主从Mha配置相同,如下:

    配置文件:

    更多参数详解请看http://wubx.net/mha-parameters/

    6.主库上启动vip :192.168.1.100对外提供服务

    [root@test1 masterha]# sh init_vip.sh

    7.检测ssh和复制是否ok

    [root@test2 masterha]#   masterha_check_repl --global-conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 

    [root@test2 masterha]#   masterha_check_ssh --global-conf=/etc/masterha/masterha_default.conf --conf=/etc/masterha/app1.conf 

    8.启动masterha_manager监控master server,如果狗带就进行切换。

     

    模拟master  mysqld  crash 并分析mha切换过程

    [root@test1 debug]# /usr/local/mysql/bin/mysqladmin -S /tmp/mysql3306.sock shutdown

    vip成功漂移到test2。

    mha_manager调用save_binary_logs到master上找到比slave多的日志并在master生成以slave机器名为前缀的增量日志。

    4次尝试ssh master


    确定master Dead并检查所有在线的从库

    vip切换

    检查所有slave 的binary log file/position 同步位置是否与master_bin_log位置一致,若不一致将save_binary_logs生成的增量日志 scp到slave,然后在slave调用mysqlbinlog做日志重放,实现所有slave数据一致。

    选举新master

    在新master上做show master status动作,告诉所有从库从这里开始复制。

    最后生成故障接管报告。

    mha处理一主两从主库宕机时会找到同步靠前的节点,从relay log中把差异数据提取出来补给同步靠后的节点,从而达到节点数据一致。

  • 相关阅读:
    IdentityServer4系列 | 资源密码凭证模式
    IdentityServer4系列 | 客户端凭证模式
    IdentityServer4系列 | 快速搭建简易项目
    Java9系列第九篇-对HTTP2协议的支持与非阻塞HTTP-API
    跨站资源共享CORS原理深度解析
    Java9系列第8篇-Module模块化编程
    Java9系列第7篇:Java.util.Optional优化与增强
    Kubernetes的Local Persistent Volumes使用小记
    CoProcessFunction实战三部曲之三:定时器和侧输出
    CoProcessFunction实战三部曲之二:状态处理
  • 原文地址:https://www.cnblogs.com/xxmysql/p/5564066.html
Copyright © 2011-2022 走看看