标签：可用 app1 mha manager masterha master mysql MHA

mysql高可用-MHA

GTID:global transaction id

gtid_mode=on

enforce-gtid-consistency=true

log-slave-update=1 --slave日志是否记入日志

GTID复制配置过程（准备MHA环境，1主2从）

1. 环境准备

   1. db1:10.0.0.51,db2:10.0.0.52,db3:10.0.0.53

   2. cat > /etc/my.cnf << EOF
      
      [mysqld]
      
      basedir=/application/mysql
      
      datadir=/application/mysql/data
      socket=/tmp/mysql.sock
      
      log_error=/var/log/mysql.log
      
      log_bin=/data/mysql/mysql_bin
      
      server_id=51
      
      binlog_format=row
      
      gtid_mode=on
      
      enforce-gtid-consistency=true
      
      log-slave-update=1
      
      [client]
      
      socket=/tmp/mysql.sock
      EOF
      

2. 初始化数据

   /application/mysql/scripts/mysql_install_db --user=mysql --basedir=/application/mysql --datadir=/application/mysql/data/
   

3. 启动数据库

   /etc/init.d/mysql.d start

4. 构建主从

   51:grant replicaion slave on  *.* to repl@'10.0.0.%' identified by '123';
   52/53:
   change master to master_host='10.0.0.51',master_user='repl',master_password='123',master_auto_position=1;
   start slave;
   

GTID复制和普通复制的区别

• change master to 的时候不用指定position，binlog文件名
• 复制过程中不再依赖master.info,直接读取relaylog的GID号
• mysqldump备份时，默认会将备份中包含的事务操作以 set @GLOBAL.GTID_PURGED='';的方式告诉从库，我备份中已有以上事务，可以直接从下一个GTID开始请求binlog

MHA

masterha_check_ssh	检查MHA的ssh配置情况
masterha_check_repl	检查MYSQL复制情况
masterha_check_status	检测当前MHA运行情况
masterha_manager	启动关闭MHA
masterha_master_monitor	检测master是否宕机
masterha_master_switch	控制故障转移
masterha_conf_host     添加或删除配置的server信息

save_binary_logs	保存和复制master的二进制日志
apply_diff_relay_logs	识别差异的中继日志事件并将其差异的事件应用于其他的
save filter_mysqlbinlog		去除不必要的rollback事件（MHA已不再使用这个工具）
purge_relay_logs	清除中继日志（不会阻塞SQL线程）

环境搭建

1. 1主2从GTID

2. 设置从库relay的自动删除功能，从库设置只读

   set global relay_log_purge=0; ——所有节点

   slave: set global read_only=1;

3. 配置关键程序软连接（MHA源码用的yum安装的库）

   1. ln -s /application/mysql/bin/mysqlbinlog /usr/bin/musqlbinlog
   2. ln -s /applicaction/mysql/ /usr/bin/mysql

4. 配置互信

5. 安装软件

   传包--安装依赖 perl-DBD-MySQL -y

   所有节点：

   rpm -ivh mha4mysql-node-0.57-0.el7.noarch.rpm
   

   主库db1:grant all privilege on *.*  to mha@'10.0.0.%' identified by 'mha';
   

   db3:安装manager,依赖

6. db3配置文件

   mkdir /etc/mha
   mkdir /var/log/mha/app1
   vim /etc/mha/app1.cnf1
   	[server default]
   # 登陆mysql数据库账户及密码，缺省为root，因为需要STOP SLAVE, CHANGE MASTER, RESET SLAVE等。
   user=mha
   password=mha
   ping_intervar=2
   repl_password=123
   repl_user=repl
   ssh_user=root
   
   # working directory on the manager  #位于管理节点工作目录
   manager_workdir=/var/log/mha/app1
   
   # manager log file #位于管理节点工作日志文件
   manager_log= /var/log/mha/app1/app1/manager
   master_binlog_dir=/data/mysql/
   
   # working directory on MySQL servers
   # node 上用于产生日志的工作目录，如果不存在，MHA node会自动创建，前提需要有相应的权限，否则node会终止。
   # 缺省目录为 "/var/tmp".
   remote_workdir=/var/log/masterha/app1
   
   #[serverN] 部分，为各节点配置信息，作用域为各单独节点，各节点书写顺序影响成为新master的顺序
   #也可以通过配置candidate_master参数来影响哪个节点具有优先级成为新master
   [server1]
   hostname=host1
   port=
   
   [server2]
   hostname=host2
   port=
   
   [server3]
   hostname=host3
   port=
   

7. 状态检查

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

8. 开启MHA

   up 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
   

恢复MHA状态

1.修好db1

2.加入到主从复制中

​ change master to master_host='10.0.0.52',master_port=3306,master_auto_position=1,master_user='repl',master_passord='123';

3.start slave; 将修好的节点信息加入配置文件

4.启动MHA，查看状态

​

MHA工作原理：用主库的binlog，从库的relaylog差异

工作前提：

1.1主2从gtid复制环境

2.所有节点互信

3.manager配置文件添加所有节点信息

manager工作过程

1.监控所有节点

​ 系统层面：网络是否ping通，ssh连通性

​ 数据库层面：数据库实例是否启动：mysqladmin -umha -h 10.0.0.51 ping

​ 主从状态：show slave status\G

2.如果主库故障

​ 1.db1能够ssh上

​ 2.db01不能ssh上

3.选主

​ 算法：1.判断主库和从库的差距，如果主库连不上，基于从库show slave status\G（gtid或者position）判断哪个更新，选择最新的

​ 2.如果从库日志一样新，按照默认配置文件的书写顺序选择新主库

​ 3.自定制配置，强制选择备选主

4.数据补偿

​ 1.ssh能连上

​ 1.1查看从库gtid或者position

​ 1.2查看主库最后的binlog文件的gtid或者position

​ 1.3截取缺失部分的binlog日志

​ 1.4scp到各个从节点，进行恢复

​ 2.ssh连接不上

​ 2.1判断两个从库日志是否一致，如果一致不需要数据补偿，如果不一致通过apply_diff_relay_logs进行补偿即可

​ 2.2

5.failover（masterha_master_switch）

将新主库解除从库身份stop slave; reset slave all;

将剩余从库，change master to 新主库

6.清理故障主机信息（masterha_conf_host），停manager

============================================================================================================================================================================================================================================================================================================================================================================================================================================================

MHA的vip功能

1.参数 /etc/mha/app1.cnf

master_ip_failover_script=/usr/local/bin/master_ip_failover

2.主库上手动生成第一个vip地址

ifconfig eth0:0 10.0.0.55/24

3.重启mha

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

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

​ PS.如果有中文字符 dos2unix master_ip_failover

标签：可用,app1,mha,manager,masterha,master,mysql,MHA
来源： https://www.cnblogs.com/ddlearning/p/15376157.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。