MHA创设MySQL高可用平台最好推行,白屏化背后

by admin on 2019年4月23日

mysql-tmpdir

3.4.7.创制MHA、BINLOG工作目录
# mkdir -p /data1/mha/masterha/app3389
# mkdir -p /data1/mha/binlog/3389
# chown -R mysql:mysql /data1/mha/binlog/3389

MySQL高可用系统

MySQL高可用,顾名思义正是当MySQL主机或服务暴发别的故障时能够立时有别的主机顶替其行事,并且最低供给是要保险数据①致性。因而,对于三个MySQL高可用系统必要高达的靶子有以下几点:

(1)、数据一致性保险这几个是最宗旨的还要也是前提,如若主备的数据分化,那么切换就无法进展,当然那里的一致性也是二个相持的,不过要做到最终一致性。

(2)、故障神速切换,当master故障时那里能够是机械故障大概是实例故障,要确认保证工作能在最长期切换来备用节点,使得业务受影响时间最短。

(叁)、简化日常体贴,通过高可用平台来机关落成高可用的安顿、维护、监察和控制等职务,能够最大程度的解放DBA手动操作,升高普通运转成效。

(四)、统1保管,当复制集众多的情事下,能够合并保管高可用实例消息、监察和控制消息、切换信息等。

(伍)、高可用的配备要对现存的数据库架构无影响,尽管因为安顿高可用,需求改换或然调治数据库架构则会造成资金扩充。

时下MySQL高可用方案得以一定水准上贯彻数据库的高可用,比方MMM,heartbeat+drbd,NDB
Cluster等。还有玛丽亚DB的Galera Cluster,以及MySQL 伍.柒.一七 Group
Replication等。那一个高可用软件各有上下。在开始展览高可用方案选拔时,首如果看事情对数码1致性方面包车型地铁要求。最终由于对数据库的高可用和高可信的渴求,目前援引使用MHA架构,因为MySQL
GP还无法在生养应用,但是相信之后渐渐就会被用到生育情形的。

/storage/fioa/mysql3308:

文/Bruce.Liu1

MHA技能介绍

MHA(Master High
Availability)近来在MySQL高可用方面是叁个相对成熟的化解方案,它由东瀛DeNA集团youshimaton(现就职于照片墙集团)开荒,是1套精美的当作MySQL高可用性碰着下故障切换和核心提升的高可用软件。在MySQL故障切换进程中,MHA能到位在0~30秒之内自动实现数据库的故障切换操作,并且在进展故障切换的经过中,MHA能在最大程度上保险数据的壹致性,以高达确实意义上的高可用。除了failover之外,MHA还扶助在线master切换,分外安全和快捷,大约只要求(0.五
~ 2秒)的不通写时间。

该软件由两部分组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA
Manager能够单独安顿在1台独立的机械上管住多个master-slave集群,也足以布署在1台slave节点上。MHA
Node运营在每台MySQL服务器上,MHA
Manager会定时探测集群中的master节点,当master出现故障时,它能够自行将新型数据的slave升高为新的master,然后将全体其余的slave重新指向新的master。整个故障转移进度对应用程序完全透明。

时下MHA首要支撑1主多从的架构,要搭建MHA,供给八个复制集群中必须至少有3台数据库服务器,1主贰从,即1台充当master,壹台充当备用master,别的一台充当slave。当然,纵然您处在资金思虑,也能够使用多个节点的MHA,壹主一从(实地衡量过的)。

小结一下,MHA提供了如下效果:

(1)master自动监察和控制,故障转移1体化(Automated master monitoring and
failover)

(2)MHA能够在三个复制组中监督master的事态,假若挂了,就足以活动的做failover。

(三)MHA通过具备slave的差别relay-log来保险数据的一致性。

(四)MHA在做故障转移,日志补偿这一个动作的时候,平时只供给10~30秒。

(5)日常状态下,MHA会选拔新型的slave作为new
master,可是你也能够指定哪些是候选maser,那么新master公投的时候,就从这么些host里面挑。

(六)导致复制意况中断的一致性难点,在MHA中是不会产生的,请放心使用。

在MHA自动故障切换进度中,MHA试图从宕机的主服务器上保存2进制日志,最大程度的保险数据的不丢掉,但这并不连续实惠的。比如,假如主服务器硬件故障或不能透过ssh访问,MHA没办法保存二进制日志,只进行故障转移而丢掉了新星的数码。使用MySQL
5.5及以上版本的半同步复制,能够大大下落数据丢失的高危机。MHA能够与半一块复制结合起来。要是唯有2个slave已经接收了流行的二进制日志,MHA能够将新型的2进制日志应用于任何具备的slave服务器上,因此能够保险拥有节点的多少一致性。

(柒)手工业-交互式master故障转移(Interactive manually initiated Master
Failover)

MHA能够铺排成手工业-交互式方式展开故障转移,不支持监督master的情景。

(八)非交互式master故障转移 (Non-interactive master failover)

非交互式,自动的故障转移,不提供监督master状态功效,监察和控制能够付出别的零件做(如:Pacemaker
heartbeat)。

(9)在线master切换 (Online switching master to a different host)

假若您有更加快,越来越好的master,安插要将老master替换到新的master,那么这么些职能尤其吻合那样的场地。

那不是master真的挂掉了,只是大家有多数要求要拓展master例行维护。

MHA的优点

  1. master failover和slave promotion极流行速。

2. 活动探测,多重检查测试,切换进度中帮忙调用别的脚本的接口。

  1. master crash不会形成数据不均等,自动补齐数据,维护数据壹致性。

  2. 不须要修改复制的别的设置,简单易安插,对现存架构无影响。

  3. 不须要扩大许多外加的机器来布局MHA,辅助多实例聚集管理。

  4. 尚无其它性质影响。

  5. 扶助在线切换。

  6. 跨存款和储蓄引擎,辅助其余引擎。

法定介绍:https://code.google.com/p/mysql-master-ha

  • Level
    一为底层援助模块:
    比方SSH操作模块、MySQL连接和操作模块、音信模块(短信,邮件,内部新闻)、日志模块、外部接口模块(DNS更换,CDMD同步等)、元数据保养模块(meatdata)等。
  • Level
    二为底蕴单元模块:
    比如说设置MySQL节点、配置基本、配置MHA、创造数据库、DB授权等等,那一个都以二级模块,基本正是成功某1个一定成效。注意Level
    二里代码除了职业逻辑部分,别的只须要调用Level
    壹的模块就能够。举个例子上边是一个设置MySQL实例的截图,属于二级模块:
三.4.六.上传MHA切换脚本

master_ip_failover.sh
master_ip_online_change.sh
power_manager

瞩目:脚本内容中要修改网卡名字

my $vip  = shift;
my $interface = 'eth1';
my $key = shift;
  • 上传故障切换脚本并授权

# chmod 755 master_ip_*
# chmod 755 power_manager

MHA组件介绍

MHA软件由两有的构成,Manager工具包和Node工具包,具体的辨证如下。

Manager工具包主要包罗以下多少个工具:

(1)masterha_check_ssh    #检查MHA的SSH配置意况;

(2)masterha_check_repl    #自己争执MySQL复制场景;

(3)masterha_manger    #启动MHA;

(4)masterha_check_status  #检查实验当前MHA运营情形;

(5)masterha_master_monitor  #检查实验master是还是不是宕机;

(6)masterha_master_switch    #垄断故障转移(自动也许手动);

(7)masterha_conf_host    #加多或删除配置的server新闻;

Node工具包(这一个工具平时由MHA
Manager的台本触发,无需人工操作)紧要不外乎以下几个工具:

(1)save_binary_logs      #保留和复制master的2进制日志;

(2)apply_diff_relay_logs 
#识假差距的连片日志事件并将其差距的事件选拔于其余的slave;

(3)purge_relay_logs      #破除中继日志(不会阻塞SQL线程);

注意:为了尽可能的缩减主库硬件损坏宕机造成的数量丢失,因而在布置MHA的同时建议配置成MySQL半共同复制。关于半协同复制原理各位本身开始展览查看(不是必须)。

转自:

3.4.8.启动BINLOG SERVER
# su - mysql
$ cd /data1/mha/binlog/3389;
$ mysqlbinlog -R --host=192.168.217.130 -P3389 --user=mha --password=mysqlDBA  --raw --stop-never 2171303389-bin.000003 &
$ ps -ef | grep mysqlbinlog | grep -v grep  # 验证binlog server进程是否存在
root       7008   6233  0 07:00 pts/0    00:00:00 mysqlbinlog -R --host=192.168.217.130 -P3389 --user=mha --password=x xxxxxx --raw --stop-never 2171303389-bin.000003

MHA工作流程

下图呈现了何等通过MHA
Manager处理多组主从复制,能够将MHA职业规律总括为如下:

图片 1

一、MHA怎么着监察和控制master和故障转移?

一.一 验证复制设置以及确认当前master状态

一而再全部hosts,MHA自动来认同当前master是哪个,配置文件中无需点名哪个是master。

万1内部有别的三个slave挂了,脚本马上退出,甘休监察和控制。

只要有部分须求的脚本未有在MHA
Node节点安装,那么MHA在那些阶段终止,且停止监察和控制。

1.2 监控master

监控master,直到master挂了。

这么些等级,MHA不会监察和控制slave,Stopping/Restarting/Adding/Removing操作在slave上,不会潜移默化当下的MHA监察和控制过程。当你增加也许去除slave的时候,请更新好安插文件,最佳重启MHA。

一.三 检测master是还是不是退步

一经MHA Manger一遍间隔时间都不能够连接master server,就会进来那个品级。

假设你设置了secondary_check_script
,那么MHA会调用脚本做三次检查测试来判别master是还是不是是真的挂了。

接下去的手续,就是masterha_master_switch的办事流程了。

一.肆 双重验证slave的安顿

若果开采其余违规的复制配置(有个别slave的master不是同三个),那么MHA会截止监察和控制,且报错。能够安装ignore_fail忽略。

这一步是地处安全着想,很有望,复制的配置文件已经被改掉了,所以double
check是相比推荐的做法。

反省最终一遍failover(故障转移)的动静

壹旦上一次的failover报错,或然上一遍的failover甘休的太近(私下认可叁天),MHA结束监察和控制,结束failover,那么在masterha_manager命令中安装ignore_last_failover,wait_on_failover_error来退换这1检查评定。这么做,也是由于安全着想。频仍的failover,检查下是不是互联网出难题,大概此外错误吗?

1.五 关掉退步的master的服务器(可选)

万1在配置文件中定义了master_ip_failover_script and/or
shutdown_script ,MHA会调用这一个的剧本。

关门dead master,制止脑裂(值得商榷)。

1.陆 苏醒1台新master

从crashed master服务器上保存binlog到Manager(如果能够的话

若是dead master能够SSH的话,拷贝binary
logs从最新的slave上的end_log_pos(Read_Master_Log_Pos)地方上马拷贝。

选举新master

诚如依照配置文件的设置来调控推选什么人,要是想设置某些候选master,设置candidate_master=一;如若想设置有个别host,永久都不会选出,设置no_master=1;确认最新的slave
(那台slave具备新型的relay-log)。

过来和进级新master

依附老master binlog生成差别日志,应用日志到new
master,假诺这一步发生错误(如:duplicate key
error),MHA甘休恢复生机,并且其余的slave也截至恢复。

二)MHA如何在线飞速切换master?

上边包车型大巴步调,正是masterha_master_switch—master_state=alive做的政工。

二.一 验证复制设置以及确认当前master状态

连日配置文件中列出的全部hosts,MHA自动来认同当前master是哪个,配置文件中无需点名哪个是master。

推行 flush tables 命令在master上(可选). 那样能够缩小FLUSH TABLES WITH
READ LOCK的日子。

既不监察和控制master,也不会failover。

反省下边包车型大巴条件是否满意。

A. IO线程是不是在富有slave上都以running。

B. SQL线程是不是在有着slave上都以running。

C. Seconds_Behind_Master 是还是不是低于二秒(—running_updates_limit=N)。

D. master上是不是未有长的换代语句大于2秒。

2.2 确认新master

新master须求设置: –new_master_host参数。

原先的master和新的master必须要有雷同的复制过滤条件(binlog-do-db and
binlog-ignore-db)。

2.3 当前master停写

设若您在陈设中定义了master_ip_online_change_script,MHA会调用它。能够经过安装SET
GLOBAL read_only=一来宏观的阻挠写入。

在老master上奉行FLUSH TABLES WITH READ
LOCK来阻止全体的写(–skip_lock_all_tables可以忽略这一步)。

二.四 守候其余slave追上如今master,同步无延迟

调用这一个函数MASTE奇骏_LOG_POS()。

2.5 确保新master可写

进行SHOW MASTE福睿斯 STATUS来分明新master的binary log文件名和position。

1经设置了master_ip_online_change_script,会调用它。能够成立写权限的用户,SET
GLOBAL read_only=0。

2.6 让其他slave指向新master

并行施行CHANGE MASTEEscort, START SLAVE。

先是是大家DBA对个中一台服务器经过起始化设置和优化,举例按数据库的最优政策调节基本参数,分区和挂在磁盘,预装pt-tool
\ MHA Node \ Xtrbackup \ Innotop \
oak-tool等数据库常用的处理软件,然后交付给运行同学进行打包镜像,之后有所交付给DBA的服务器都是按此镜像举办布置。那样一来,我们的OS服务器就格外标准了,同时也预装了作者们常用的管理工科具。

叁.一.叁.设置系统要求
  • 关系全体服务器关闭iptables、NetworkManager服务、selinux安全安插

# /etc/init.d/NetworkManager stop
# chkconfig NetworkManager off
# /etc/init.d/iptables stop
# chkconfig iptables off

/etc/selinux/config 改成disable

原标题:白屏化背后,DBA应有的数据库自动化建设思路

三.1.一.软件参考文书档案

参照文书档案:
MHA原理:https://code.google.com/p/mysql-master-ha/wiki/HowMHAWorks
MHA原理PPT:http://www.slideshare.net/matsunobu/automated-master-failover
Linux配置代理方法:http://blog.csdn.net/bojie5744/article/details/42148719

软件下载:
Centos Base Yum Repository:
http://mirrors.163.com/.help/CentOS6-Base-163.repo
epel(RHEL 6)Yum
Repository:http://dl.fedoraproject.org/pub/epel/6/x86\_64/epel-release-6-8.noarch.rpm
MySQL5.7 Yum
Repository:https://dev.mysql.com/get/mysql57-community-release-el6-11.noarch.rpm
mysql-master-ha(mgr):https://github.com/linyue515/mysql-master-ha/raw/master/mha4mysql-manager-0.57-0.el7.noarch.rpm
mysql-master-ha(node):https://github.com/linyue515/mysql-master-ha/raw/master/mha4mysql-node-0.57-0.el7.noarch.rpm

在豪门的共同努力下,MySQL以及Redis平时安排和保护工作都落到实处了职分调治化管理。平常须求大家登入服务器的操作未来着力都在WEB分界面端就到位了。一般除了须求登服务器定位难点和管理线上故障,基本就白屏化了数据库管理。

图片 2

既然如此作为平台,那么WEB管理界面、义务调节、API服务多少个着力部分是不可能少的。上面浮现三个建设早先时代的三个基础架构:

3.4.部署MHA软件

有了上述自动化职分调整平台和设计标准作为基础,大家DBA基本都快速加入进行了进展模块开采。模块开辟的裨益正是大家很轻松上手开垦,乃至从前有不会Python的同桌,在简要学习了Python之后也能里丑捧心非常快成功贰个模块。

2.4.MHA的优势

  • 障切换快

    主从复制集群中,只要从库在复制上尚未延迟,MHA经常能够在数秒内实现故障切换。九-10秒内检查到master故障,能够挑选在7-十秒关闭
    master以幸免出现裂脑,几分钟内,将出入中继日志(relay
    log)应用到新的master上,因而总的宕机时间平日为十-30秒。苏醒新的master后,MHA并行的复原其他的slave。尽管在有数万台
    slave,也不会潜移默化master的回涨时间。
    DeNA在超越一四十四个MySQL(首要伍.0/5.一本子)主从景况下使用了MHA。当mater故障后,MHA在四秒内就到位了故障切换。在观念的能动/被动集群消除方案中,肆秒内做到故障切换是不只怕的。

  • master故障不会形成数据分裂
    当 最近的master出现故障是,MHA自动识别slave之间衔接日志(relay
    log)的差异,并利用到持有的slave中。那样有着的salve能够有限帮助同步,只要抱有的slave处于存活状态。和Semi-
    Synchronous Replication一同使用,(大概)能够确定保障未有多少丢失。

  • 需修改当前的MySQL设置
    MHA的统一希图的要害条件之1正是不择手腕地大约易用。MHA专业在价值观的MySQL版本5.0和后来版本的主从复制意况中。和别的高可用化解情势比,MHA并不供给退换MySQL的铺排情形。MHA适用于异步和半联机的主从复制。
    运营/结束/晋级/降级/安装/卸载MHA不要求转移(包扩运营/结束)MySQL复制。当须要升高MHA到新的版本,不要求结束MySQL,仅仅替换来新本子的MHA,然后重启MHA Manager就好了。
    MHA运维在MySQL
    5.0早先的原生版本上。一些任何的MySQL高可用化解方案须求一定的版本(举例MySQL集群、带全局专门的学问ID的MySQL等等),但并不只为了
    master的高可用才迁移应用的。在大部场馆下,已经铺排了相比旧MySQL应用,并且不想单独为了完成Master的高可用,花太多的年月迁移到区别的仓储引擎或更新的前沿发行版。MHA工作的总结5.0/5.1/伍.五的原生版本的MySQL上,所以并不必要迁移。

  • 不要扩大大气的服务器
    MHA由MHA Manager和MHA Node组成。MHA
    Node运转在急需故障切换/苏醒的MySQL服务器上,因此并不必要额外扩充服务器。MHA
    Manager运行在特定的服务器上,由此须求充实1台(完毕高可用需求二台),但是MHA
    Manager能够监察和控制大批量(以致上百台)单独的master,因而,并不须要扩张大气的服务器。固然在1台slave上运行MHA
    Manager也是可以的。综上,达成MHA并没用额外扩大大气的服务。

  • 无性能下降
    MHA适用与异步或半共同的MySQL复制。监察和控制master时,MHA仅仅是每隔几秒(暗许是3秒)发送1个ping包,并不发送重查询。可以收获像原生MySQL复制同样快的习性。

  • 适用于其余存储引擎
    MHA能够运作在只要MySQL复制运维的囤积引擎上,并不仅只限制于InnoDB,纵然在正确迁移的观念意识的MyISAM引擎景况,一样能够使用MHA。

责编:

三.伍.壹.故障切换
  • 主库down只怕主机down,然后测试切换是不是成功。
  • 首先层为WEB调节层;
  • 第三层为任务管理层和多少收集层,用于别的调解管理和数据的互相管理;
  • 其三层为职业模块层,用于得以达成各职能的作用,比如设置实例、配置Replication、配置MHA、创立数据库、授权等等,那些都以由分裂的最底层模块来产生,日常由1雨后春笋脚本组成。

2.MHA原理

/etc/my3308.cnf

1.一.mha零件介绍

  • MHA Manager
    运行一些工具,比方masterha_manager工具落成全自动监察和控制MySQL
    Master和贯彻master故障切换,别的工具落成手动落成master故障切换、在线mater转移、连接检查等等。三个Manager可以管理多少个master-slave集群

  • MHA Node
    配置在有着运营MySQL的服务器上,无论是master仍然slave。首要效率有八个。
    一.封存二进制日志
    壹经能够访问故障master,会拷贝master的二进制日志
    贰.用到差别中继日志
    从具备最新数据的slave上转移差别中继日志,然后使用差别日志。
    叁.免除中继日志
    在不截至SQL线程的情景下删除中继日志

mysql-error.log

三.一.背景介绍

图片 3

二.一.MHA行事原理

图片 4

image.png

当master出现故障时,通过对照slave之间I/O线程读取masterbinlog的职位,选择最相仿的slave做为latestslave。
别的slave通过与latest slave相比较变化差距中继日志。在latest
slave上采纳从master保存的binlog,同时将latest
slave提高为master。最终在其余slave上应用相应的差别中继日志并开始从新的master伊始复制。

在MHA落成Master故障切换进度中,MHA
Node会试图访问故障的master(通过SSH),倘使能够访问(不是硬件故障,比方InnoDB数据文件损坏等),会保留二进制文件,以最大程度保证数据不丢掉。MHA和半一起复制一同利用会大大降低数据丢失的险恶。流程如下:

  • 从宕机崩溃的master保存2进制日志事件(binlog events)。
  • 鉴定分别含有最新更新的slave。
  • 动用差别的连结日志(relay log)到任何slave。
  • 应用从master保存的2进制日志事件(binlog events)。
  • 提高三个slave为新master并记录binlog file和position。
  • 使别的的slave连接新的master进行理并答复制。
  • 形成切换manager主进度OFFLINE

mysql-error.log

1.MHA简介

MHA是什么?
MHA是由东瀛Mysql
yoshinorim专家(原就职于DeNA现就职于FaceBook)用Perl写的一套Mysql故障切换方案,来维周全据库的高可用性,它的效应是能在0-30s之内完毕主Mysql故障转移(failover),MHA故障转移能够很好的帮大家减轻从库数据的壹致性难题,同时最大化挽回故障产生后数据的壹致性。
官网:https://code.google.com/p/mysql-master-ha/

MHA(Master High
Availability)近期在MySQL高可用方面是二个针锋相对成熟的化解方案,它由东瀛DeNA公司youshimaton(现就职于推文(Tweet)集团)开拓,是一套精美的当作MySQL高可用性情形下故障切换和中坚提高的高可用软件。在MySQL故障切换进度中,MHA能不辱职务在0~30秒之内自动完结数据库的故障切换操作,并且在拓展故障切换的进度中,MHA能在十分的大程度上保证数据的壹致性,以实现确实含义上的高可用。

该软件由两片段组成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA
Manager能够单独安顿在一台独立的机器上管理三个master-slave集群,也能够安顿在壹台slave节点上。MHA
Node运维在每台MySQL服务器上,MHA
Manager会定期探测集群中的master节点,当master出现故障时,它能够自动将数据的slave进步为新的master,然后将有着其余的slave重新指向新的master。整个故障转移进程对应用程序完全透明。

在MHA自动故障切换过程中,MHA试图从宕机的主服务器上保存贰进制日志,异常的大程度的保险数据的不丢掉,但那并不总是实惠的。例如,若是主服务器硬件故障或不可能透过ssh访问,MHA无法保存2进制日志,只实行故障转移而丢失了的多少。使用MySQL
伍.伍的半一块复制,能够大大下降数据丢失的危害。MHA能够与半联袂复制结合起来。如果唯有一个slave已经接收了的二进制日志,MHA能够将的②进制日志应用于任何兼具的slave服务器上,由此能够保险具有节点的数额一致性。

诸几个人在想,代码实现效益不就好了吗?还须要什么样规划观念?那或者也正是开垦与运行同学的思辨差距。

三.三.四.主库传输至从库
# scp /data1/tmp/full_3389.tar.gz 192.168.217.131:/data1/tmp

图片 5

3.2.安装MySQL实例

mysql-error.log

3.2.6.启动mysql实例
# mysqld_safe --defaults-file=/etc/mysql/my3389.cnf &
# cat /data1/db3389/error.log | grep temp
# mysql -S /data1/db3389/my3389.sock -p'z&Di4b_oSM*-'
mysql> set password=''; #重置密码为空

然后大家监察和控制上报的天职日志能够看到底层试行进度,大家能够见见职责会创设1个实例,然后配置了着力,最后布置了MHA,当然那一个中还有一些元数据保养,备份和监察开关设置等等,其实在后台已经完结了。大约陆分钟,完结了三个DBA半天的行事,并且保障了布置的数据库都以标准的,分化DBA安排未有其他差异。

3.二.2.制造布局文件目录
# mkdir /etc/mysql

系统的着力是职分调节管理层,我们职责管理的分界面如下所示,能够看来各样职务都有3个职务模块名称,并实时记录职分执汇兑况和实行日志:

3.4.3.配置SSH互信

在现网情况中差不多都是明确命令禁止root远程登6服务器得,所以ssh免密码登入要在mysql用户下进展配置,那是居于安全角度思念出发。

  • master:

# su - mysql
$ ssh-keygen -t rsa
$ rm -rf ~/.ssh/*
  • slave:

# su - mysql
$ ssh-keygen -t rsa
$ rm -rf ~/.ssh/*
  • manager:

# su - mysql
$ ssh-keygen -t rsa
$ cd ~/.ssh
$ mv id_rsa.pub authorized_keys
$ scp * 192.168.217.130:~/.ssh/
$ scp * 192.168.217.131:~/.ssh/
$ #测试ssh
$ ssh 192.168.217.130 date 
Wed Nov 22 05:48:54 PST 2017
$ ssh 192.168.217.131 date 
Wed Nov 22 05:47:58 PST 2017

大家的数据库也有谈得来的配备专门的工作,比如配置文件原则,除了有的可调参数是变量,其余参数全体使用标准模板;其它像MySQL的装置目录、数据目录、贰进制日志目录、权且文件目录都有统一的科班,依据分裂的实例端口来区分。

三.三.六.从库开始化同步数据
mysql> change master to master_host='192.168.217.130',master_port=3389,master_user='replica',master_password='mycatDBA',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.03 sec)


mysql> show slave status \G
*************************** 1. row ***************************
...... 省略 ......
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
...... 省略 ......

下边那幅图能够很好的解释底层的三级模块调用流程:

三.1.2.种类意况介绍

图片 6

图表来源于原创

  • 系统版本
    CentOS release 6.7 (Final) x86_64

  • MySQL版本
    mysql-5.7.20.-x86_64(RPM)

  • MHA版本
    mha4mysql-manager-0.57
    mha4mysql-node-0.57

一、背景

叁.肆.九.验证并运营manager进度
$ masterha_check_ssh --conf=/etc/mha/app3389.cnf 
Wed Nov 22 07:35:07 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Nov 22 07:35:07 2017 - [info] Reading application default configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:35:07 2017 - [info] Reading server configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:35:07 2017 - [info] Starting SSH connection tests..
Wed Nov 22 07:35:08 2017 - [debug] 
Wed Nov 22 07:35:07 2017 - [debug]  Connecting via SSH from root@192.168.217.130(192.168.217.130:22) to root@192.168.217.131(192.168.217.131:22)..
Wed Nov 22 07:35:08 2017 - [debug]   ok.
Wed Nov 22 07:35:08 2017 - [debug] 
Wed Nov 22 07:35:07 2017 - [debug]  Connecting via SSH from root@192.168.217.131(192.168.217.131:22) to root@192.168.217.130(192.168.217.130:22)..
Wed Nov 22 07:35:08 2017 - [debug]   ok.
Wed Nov 22 07:35:08 2017 - [info] All SSH connection tests passed successfully.

$ masterha_check_repl --conf=/etc/mha/app3389.cnf 
Wed Nov 22 07:47:07 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Wed Nov 22 07:47:07 2017 - [info] Reading application default configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:47:07 2017 - [info] Reading server configuration from /etc/mha/app3389.cnf..
Wed Nov 22 07:47:07 2017 - [info] MHA::MasterMonitor version 0.57.
Wed Nov 22 07:47:08 2017 - [info] GTID failover mode = 1
Wed Nov 22 07:47:08 2017 - [info] Dead Servers:
Wed Nov 22 07:47:08 2017 - [info] Alive Servers:
Wed Nov 22 07:47:08 2017 - [info]   192.168.217.130(192.168.217.130:3389)
Wed Nov 22 07:47:08 2017 - [info]   192.168.217.131(192.168.217.131:3389)
Wed Nov 22 07:47:08 2017 - [info] Alive Slaves:
Wed Nov 22 07:47:08 2017 - [info]   192.168.217.131(192.168.217.131:3389)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Wed Nov 22 07:47:08 2017 - [info]     GTID ON
Wed Nov 22 07:47:08 2017 - [info]     Replicating from 192.168.217.130(192.168.217.130:3389)
Wed Nov 22 07:47:08 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
Wed Nov 22 07:47:08 2017 - [info] Current Alive Master: 192.168.217.130(192.168.217.130:3389)
Wed Nov 22 07:47:08 2017 - [info] Checking slave configurations..
Wed Nov 22 07:47:08 2017 - [info]  read_only=1 is not set on slave 192.168.217.131(192.168.217.131:3389).
Wed Nov 22 07:47:08 2017 - [info] Checking replication filtering settings..
Wed Nov 22 07:47:08 2017 - [info]  binlog_do_db= , binlog_ignore_db= 
Wed Nov 22 07:47:08 2017 - [info]  Replication filtering check ok.
Wed Nov 22 07:47:08 2017 - [info] GTID (with auto-pos) is supported. Skipping all SSH and Node package checking.
Warning: Permanently added '192.168.217.132' (RSA) to the list of known hosts.
Wed Nov 22 07:47:08 2017 - [info] HealthCheck: SSH to 192.168.217.132 is reachable.
Wed Nov 22 07:47:14 2017 - [info] Binlog server 192.168.217.132 is reachable.
Wed Nov 22 07:47:14 2017 - [info] Checking recovery script configurations on 192.168.217.132(192.168.217.132:3306)..
Wed Nov 22 07:47:14 2017 - [info]   Executing command: save_binary_logs --command=test --start_pos=4 --binlog_dir=/data1/mha/binlog/3389 --output_file=/data1/mha/masterha/app3389/save_binary_logs_test --manager_version=0.57 --start_file=2171303389-bin.000003 
Wed Nov 22 07:47:14 2017 - [info]   Connecting to root@192.168.217.132(192.168.217.132:22).. 
  Creating /data1/mha/masterha/app3389 if not exists..    ok.
  Checking output directory is accessible or not..
   ok.
  Binlog found at /data1/mha/binlog/3389, up to 2171303389-bin.000003
Wed Nov 22 07:47:14 2017 - [info] Binlog setting check done.
Wed Nov 22 07:47:14 2017 - [info] Checking SSH publickey authentication settings on the current master..
Wed Nov 22 07:47:15 2017 - [info] HealthCheck: SSH to 192.168.217.130 is reachable.
Wed Nov 22 07:47:15 2017 - [info] 
192.168.217.130(192.168.217.130:3389) (current master)
 +--192.168.217.131(192.168.217.131:3389)

Wed Nov 22 07:47:15 2017 - [info] Checking replication health on 192.168.217.131..
Wed Nov 22 07:47:15 2017 - [info]  ok.
Wed Nov 22 07:47:15 2017 - [info] Checking master_ip_failover_script status:
Wed Nov 22 07:47:15 2017 - [info]   /etc/mha/master_ip_failover.sh 192.168.217.201  1 --command=status --ssh_user=root --orig_master_host=192.168.217.130 --orig_master_ip=192.168.217.130 --orig_master_port=3389 
Checking the Status of the script.. OK 
Wed Nov 22 07:47:15 2017 - [info]  OK.
Wed Nov 22 07:47:15 2017 - [info] Checking shutdown script status:
Wed Nov 22 07:47:15 2017 - [info]   /etc/mha/power_manager --command=status --ssh_user=root --host=192.168.217.130 --ip=192.168.217.130 
Wed Nov 22 07:47:15 2017 - [info]  OK.
Wed Nov 22 07:47:15 2017 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.

$ nohup masterha_manager --conf=/etc/mha/app3389.cnf --ignore_last_failover &
[2] 7307
$ nohup: ignoring input and appending output to `nohup.out'

$ masterha_check_status --conf=/etc/mha/app3389.cnf 
app3389 (pid:7307) is running(0:PING_OK), master:192.168.217.130

图片 7

图表来自网络

本文就将针对我们DBA
Team完毕的数据库自动化平台营造和之间的建设思路做一些回顾介绍,首要分享先前时代条件营造和自动化模型搭建思路方面的有的。后续倘诺大家风乐趣,小编得以更进一步见解彻底的牵线一下自动化平台其余方面包车型大巴剧情。

③.伍.二.在线切换

在线切换(Mha manager进程(binlog
server进度可选)是关门的,Mha结构是常规的情形,适用于生产种类硬件、软件升级维护等情景)

  • --orig_master_is_new_slave
    切换时抬高此参数是讲原master产生slave节点,不加该参数,原master将不运营
  • --running_updates_limit=10000
    切换时选master
    假若有延期的话,mha切换不会马到成功,加上此参数表示切换在此时间范围内都足以切换(单位为
    s),可是切换的时间长度是由recover时relay日志大小决定

专注:在备库先进行DDL,一般先stop slave,一般不记录mysql日志,能够因此set
session
sql_log_bin=0完结,然后举行3次主备切换操作,再在原来的主库上施行DDL.那种艺术适用于增减索引.

$ masterha_master_switch --master_state=alive --conf=/etc/mha/app3389.conf --orig_master_is_new_slave
Sat Nov 25 11:06:04 2017 - [info] MHA::MasterRotate version 0.57.
Sat Nov 25 11:06:04 2017 - [info] Starting online master switch..
Sat Nov 25 11:06:04 2017 - [info] 
Sat Nov 25 11:06:04 2017 - [info] * Phase 1: Configuration Check Phase..
Sat Nov 25 11:06:04 2017 - [info] 
Sat Nov 25 11:06:04 2017 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sat Nov 25 11:06:04 2017 - [info] Reading application default configuration from /etc/mha/app3389.conf..
Sat Nov 25 11:06:04 2017 - [info] Reading server configuration from /etc/mha/app3389.conf..
Sat Nov 25 11:06:04 2017 - [info] GTID failover mode = 1
Sat Nov 25 11:06:04 2017 - [info] Current Alive Master: 192.168.1.121(192.168.1.121:3389)
Sat Nov 25 11:06:04 2017 - [info] Alive Slaves:
Sat Nov 25 11:06:04 2017 - [info]   192.168.1.120(192.168.1.120:3389)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Sat Nov 25 11:06:04 2017 - [info]     GTID ON
Sat Nov 25 11:06:04 2017 - [info]     Replicating from 192.168.1.121(192.168.1.121:3389)
Sat Nov 25 11:06:04 2017 - [info]     Primary candidate for the new Master (candidate_master is set)

It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 192.168.1.121(192.168.1.121:3389)? (YES/no): YES
Sat Nov 25 11:06:07 2017 - [info] Executing FLUSH NO_WRITE_TO_BINLOG TABLES. This may take long time..
Sat Nov 25 11:06:07 2017 - [info]  ok.
Sat Nov 25 11:06:07 2017 - [info] Checking MHA is not monitoring or doing failover..
Sat Nov 25 11:06:07 2017 - [info] Checking replication health on 192.168.1.120..
Sat Nov 25 11:06:07 2017 - [info]  ok.
Sat Nov 25 11:06:07 2017 - [info] Searching new master from slaves..
Sat Nov 25 11:06:07 2017 - [info]  Candidate masters from the configuration file:
Sat Nov 25 11:06:07 2017 - [info]   192.168.1.120(192.168.1.120:3389)  Version=5.7.20-log (oldest major version between slaves) log-bin:enabled
Sat Nov 25 11:06:07 2017 - [info]     GTID ON
Sat Nov 25 11:06:07 2017 - [info]     Replicating from 192.168.1.121(192.168.1.121:3389)
Sat Nov 25 11:06:07 2017 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat Nov 25 11:06:07 2017 - [info]   192.168.1.121(192.168.1.121:3389)  Version=5.7.20-log log-bin:enabled
Sat Nov 25 11:06:07 2017 - [info]     GTID ON
Sat Nov 25 11:06:07 2017 - [info]  Non-candidate masters:
Sat Nov 25 11:06:07 2017 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
Sat Nov 25 11:06:07 2017 - [info] 
From:
192.168.1.121(192.168.1.121:3389) (current master)
 +--192.168.1.120(192.168.1.120:3389)

To:
192.168.1.120(192.168.1.120:3389) (new master)
 +--192.168.1.121(192.168.1.121:3389)

Starting master switch from 192.168.1.121(192.168.1.121:3389) to 192.168.1.120(192.168.1.120:3389)? (yes/NO): YES
Sat Nov 25 11:06:11 2017 - [info] Checking whether 192.168.1.120(192.168.1.120:3389) is ok for the new master..
Sat Nov 25 11:06:11 2017 - [info]  ok.
Sat Nov 25 11:06:11 2017 - [info] 192.168.1.121(192.168.1.121:3389): SHOW SLAVE STATUS returned empty result. To check replication filtering rules, temporarily executing CHANGE MASTER to a dummy host.
Sat Nov 25 11:06:11 2017 - [info] 192.168.1.121(192.168.1.121:3389): Resetting slave pointing to the dummy host.
Sat Nov 25 11:06:11 2017 - [info] ** Phase 1: Configuration Check Phase completed.
Sat Nov 25 11:06:11 2017 - [info] 
Sat Nov 25 11:06:11 2017 - [info] * Phase 2: Rejecting updates Phase..
Sat Nov 25 11:06:11 2017 - [info] 
Sat Nov 25 11:06:11 2017 - [info] Executing master ip online change script to disable write on the current master:
Sat Nov 25 11:06:11 2017 - [info]   /etc/mha/master_ip_online_change.sh 192.168.1.200 1 --command=stop --orig_master_host=192.168.1.121 --orig_master_ip=192.168.1.121 --orig_master_port=3389 --orig_master_user='mha' --new_master_host=192.168.1.120 --new_master_ip=192.168.1.120 --new_master_port=3389 --new_master_user='mha' --orig_master_ssh_user=mysql --new_master_ssh_user=mysql   --orig_master_is_new_slave --orig_master_password=xxx --new_master_password=xxx
Unknown option: orig_master_ssh_user
Unknown option: new_master_ssh_user
Unknown option: orig_master_is_new_slave
Sat Nov 25 11:06:11 2017 918769 Set read_only on the new master.. ok.
Sat Nov 25 11:06:11 2017 923401 Waiting all running 1 threads are disconnected.. (max 1500 milliseconds)
{'Time' => '78','Command' => 'Binlog Dump GTID','db' => undef,'Id' => '46','Info' => undef,'User' => 'replica','State' => 'Master has sent all binlog to slave; waiting for more updates','Host' => '192.168.1.120:39100'}
Sat Nov 25 11:06:12 2017 426422 Waiting all running 1 threads are disconnected.. (max 1000 milliseconds)
{'Time' => '79','Command' => 'Binlog Dump GTID','db' => undef,'Id' => '46','Info' => undef,'User' => 'replica','State' => 'Master has sent all binlog to slave; waiting for more updates','Host' => '192.168.1.120:39100'}
Sat Nov 25 11:06:12 2017 929834 Waiting all running 1 threads are disconnected.. (max 500 milliseconds)
{'Time' => '79','Command' => 'Binlog Dump GTID','db' => undef,'Id' => '46','Info' => undef,'User' => 'replica','State' => 'Master has sent all binlog to slave; waiting for more updates','Host' => '192.168.1.120:39100'}
Sat Nov 25 11:06:13 2017 433392 Set read_only=1 on the orig master.. ok.
Sat Nov 25 11:06:13 2017 436292 Waiting all running 1 queries are disconnected.. (max 500 milliseconds)
{'Time' => '80','Command' => 'Binlog Dump GTID','db' => undef,'Id' => '46','Info' => undef,'User' => 'replica','State' => 'Master has sent all binlog to slave; waiting for more updates','Host' => '192.168.1.120:39100'}
Disabling the VIP on old master: 192.168.1.121 
===========sudo /sbin/ifconfig eth1:1 down===========================
Sat Nov 25 11:06:14 2017 071486 Killing all application threads..
Sat Nov 25 11:06:14 2017 072793 done.
Sat Nov 25 11:06:14 2017 - [info]  ok.
Sat Nov 25 11:06:14 2017 - [info] Locking all tables on the orig master to reject updates from everybody (including root):
Sat Nov 25 11:06:14 2017 - [info] Executing FLUSH TABLES WITH READ LOCK..
Sat Nov 25 11:06:14 2017 - [info]  ok.
Sat Nov 25 11:06:14 2017 - [info] Orig master binlog:pos is 11213389-bin.000003:194.
Sat Nov 25 11:06:14 2017 - [info]  Waiting to execute all relay logs on 192.168.1.120(192.168.1.120:3389)..
Sat Nov 25 11:06:14 2017 - [info]  master_pos_wait(11213389-bin.000003:194) completed on 192.168.1.120(192.168.1.120:3389). Executed 0 events.
Sat Nov 25 11:06:14 2017 - [info]   done.
Sat Nov 25 11:06:14 2017 - [info] Getting new master's binlog name and position..
Sat Nov 25 11:06:14 2017 - [info]  11203389-bin.000003:346
Sat Nov 25 11:06:14 2017 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.1.120', MASTER_PORT=3389, MASTER_AUTO_POSITION=1, MASTER_USER='replica', MASTER_PASSWORD='xxx';
Sat Nov 25 11:06:14 2017 - [info] Executing master ip online change script to allow write on the new master:
Sat Nov 25 11:06:14 2017 - [info]   /etc/mha/master_ip_online_change.sh 192.168.1.200 1 --command=start --orig_master_host=192.168.1.121 --orig_master_ip=192.168.1.121 --orig_master_port=3389 --orig_master_user='mha' --new_master_host=192.168.1.120 --new_master_ip=192.168.1.120 --new_master_port=3389 --new_master_user='mha' --orig_master_ssh_user=mysql --new_master_ssh_user=mysql   --orig_master_is_new_slave --orig_master_password=xxx --new_master_password=xxx
Unknown option: orig_master_ssh_user
Unknown option: new_master_ssh_user
Unknown option: orig_master_is_new_slave
Sat Nov 25 11:06:14 2017 186596 Set read_only=0 on the new master.
Enabling the VIP - 192.168.1.200 on the new master - 192.168.1.120 
===========sudo /sbin/ifconfig eth1:1 192.168.1.200 broadcast 192.168.1.255 netmask 255.255.255.0 && sudo /sbin/arping -f -q -c 5 -w 5 -I eth1 -s 192.168.1.200  -U 192.168.1.1===========================
Sat Nov 25 11:06:14 2017 - [info]  ok.
Sat Nov 25 11:06:14 2017 - [info] 
Sat Nov 25 11:06:14 2017 - [info] * Switching slaves in parallel..
Sat Nov 25 11:06:14 2017 - [info] 
Sat Nov 25 11:06:14 2017 - [info] Unlocking all tables on the orig master:
Sat Nov 25 11:06:14 2017 - [info] Executing UNLOCK TABLES..
Sat Nov 25 11:06:14 2017 - [info]  ok.
Sat Nov 25 11:06:14 2017 - [info] Starting orig master as a new slave..
Sat Nov 25 11:06:14 2017 - [info]  Resetting slave 192.168.1.121(192.168.1.121:3389) and starting replication from the new master 192.168.1.120(192.168.1.120:3389)..
Sat Nov 25 11:06:14 2017 - [info]  Executed CHANGE MASTER.
Sat Nov 25 11:06:14 2017 - [info]  Slave started.
Sat Nov 25 11:06:14 2017 - [info] All new slave servers switched successfully.
Sat Nov 25 11:06:14 2017 - [info] 
Sat Nov 25 11:06:14 2017 - [info] * Phase 5: New master cleanup phase..
Sat Nov 25 11:06:14 2017 - [info] 
Sat Nov 25 11:06:14 2017 - [info]  192.168.1.120: Resetting slave info succeeded.
Sat Nov 25 11:06:14 2017 - [info] Switching master to 192.168.1.120(192.168.1.120:3389) completed successfully.

环顾下方贰维码关切自己微能量信号!迎接大家交换学习!

图片 8

Bruce.Liu

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图