云顶娱乐 > 互联网科技 > MySQL基于MHA高可用理论篇

原标题:MySQL基于MHA高可用理论篇

浏览次数:167 时间:2019-08-29

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

图片 1

MySQL高可用系统

MySQL高可用,看名称就能够想到其意义正是当MySQL主机或服务发生任何故障时亦可及时有其余主机顶替其专门的职业,而且最低必要是要有限帮忙数据一致性。因而,对于二个MySQL高可用系统要求高达的靶子有以下几点:

(1)、数据一致性保险这一个是最基本的同一时候也是前提,如若主备的数据不均等,那么切换就不只怕进行,当然这里的一致性也是多个针锋相对的,不过要做到最后一致性。

(2)、故障赶快切换,当master故障时这里可以是机械故障或许是实例故障,要保管职业能在最短期切换来备用节点,使得业务受影响时间最短。

(3)、简化经常尊崇,通过高可用平台来机关完成高可用的布局、维护、监察和控制等职分,可以最大程度的解放DBA手动操作,提升普通运行功效。

(4)、统一管理,当复制集众多的情状下,可以合併保管高可用实例新闻、监察和控制新闻、切换音信等。

(5)、高可用的布局要对现存的数据库架构无影响,假如因为布置高可用,要求更改大概调度数据库架构则会招致资本扩展。

当下MySQL高可用方案得以不容争辩程度上落到实处数据库的高可用,比方MMM,heartbeat drbd,NDB Cluster等。还会有MariaDB的Galera Cluster,以及MySQL 5.7.17 Group Replication等。这么些高可用软件各有高低。在进行高可用方案采纳时,首如若看职业对数据一致性方面包车型客车渴求。最终由于对数据库的高可用和高可信的要求,如今引进应用MHA架构,因为MySQL GP还不能够在生育应用,不过相信现在逐年就能被用到生产条件的。

小编介绍茹作军,曾任职作者检查运转技术员、1号店MySQL DBA,现就职于平安好先生。Lepus开源数据库监察和控制系统小编(www.lepus.cc)。

图片来源于互联网

MHA才能介绍

MHA(Master High Availability)近些日子在MySQL高可用方面是四个周旋成熟的减轻方案,它由日本DeNA公司youshimaton(现就职于照片墙公司)开采,是一套精美的作为MySQL高可用性遭遇下故障切换和中坚升高的高可用软件。在MySQL故障切换进度中,MHA能幸不辱命在0~30秒之内自动达成数据库的故障切换操作,并且在扩充故障切换的进程中,MHA能在最大程度上保障数据的一致性,以高达确实意义上的高可用。除了failover之外,MHA还援救在线master切换,特别安全和高速,差不多只供给(0.5 ~ 2秒)的堵截写时间。

该软件由两局部构成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA Manager能够独自布署在一台独立的机器上管理四个master-slave集群,也足以计划在一台slave节点上。MHA Node运转在每台MySQL服务器上,MHA Manager会定期探测集群中的master节点,当master出现故障时,它能够活动将流行数据的slave提高为新的master,然后将富有其余的slave重新指向新的master。整个故障转移进度对应用程序完全透明。

现阶段MHA首要支撑一主多从的架构,要搭建MHA,须求二个复制集群中必需至少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,别的一台充当slave。当然,就算你处于资金思考,也得以行使多少个节点的MHA,一主一从(实地衡量过的)。

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

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

(2)MHA能够在八个复制组中监督master的场馆,假设挂了,就足以自行的做failover。

(3)MHA通过具备slave的差距relay-log来保证数据的一致性。

(4)MHA在做故障转移,日志补偿这么些动作的时候,平时只需求10~30秒。

(5)经常状态下,MHA会选取新型的slave作为new master,不过你也能够内定哪些是候选maser,那么新master大选的时候,就从这几个host里面挑。

(6)导致复制情形中断的一致性难点,在MHA中是不会时有发生的,请放心使用。

在MHA自动故障切换进程中,MHA试图从宕机的主服务器上保存二进制日志,最大程度的有限帮衬数据的不吐弃,但那并不三番五次平价的。举例,假如主服务器硬件故障或不或然透过ssh访谈,MHA没有办法保存二进制日志,只实行故障转移而遗失了新型的数据。使用MySQL 5.5及以上版本的半联合实行理并答复制,能够大大裁减数据错过的高危害。MHA能够与半齐声复制结合起来。假如唯有贰个slave已经接受了新星的二进制日志,MHA能够将风尚的二进制日志应用于别的具有的slave服务器上,由此得以确定保障全部节点的多寡一致性。

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

MHA能够布置成手工业-交互式方式开展故障转移,不协理监督master的意况。

(8)非交互式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

事情与技巧往往是共同前进的,二〇一四年,小编加入平安好先生,在业务迅Camry飞的同期,大家的数据库自动化平台也得到了神速的建设和发展。

文/Bruce.Liu1

MHA工作流程

下图展现了怎么通过MHA Manager管理多组主从复制,能够将MHA工作规律总括为如下:

图片 2

1、MHA怎么样监控master和故障转移?

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

连天全体hosts,MHA自动来承认当前master是哪些,配置文件中无需点名哪个是master。

若是内部有任何二个slave挂了,脚本立刻退出,结束监察和控制。

假设有一对必得的本子未有在MHA Node节点安装,那么MHA在那一个品级终止,且甘休监察和控制。

1.2 监控master

监控master,直到master挂了。

那一个品级,MHA不会监察和控制slave,Stopping/Restarting/Adding/Removing操作在slave上,不会影响当下的MHA监察和控制进度。当你增添或然去除slave的时候,请更新好布署文件,最棒重启MHA。

1.3 检查评定master是不是失利

即使MHA Manger一次间隔时间都不可能连接master server,就能进去那一个等第。

借让你设置了secondary_check_script ,那么MHA会调用脚本做一回检验来推断master是还是不是是真的挂了。

接下去的手续,正是masterha_master_switch的行事流程了。

1.4 再一次验证slave的布署

就算开采别的违法的复制配置(有个别slave的master不是同多少个),那么MHA会结束监察和控制,且报错。能够安装ignore_fail忽略。

这一步是高居安全着想,很有希望,复制的布署文件已经被改掉了,所以double check是相比推荐的做法。

检查最终一遍failover(故障转移)的境况

设若上叁次的failover报错,或者上二次的failover甘休的太近(暗许3天),MHA结束监察和控制,甘休failover,那么在masterha_manager命令中设置ignore_last_failover,wait_on_failover_error来退换这一检查评定。这么做,也是由于安全思量。频仍的failover,检查下是还是不是网络出题目,恐怕别的错误吧?

1.5 关掉失败的master的服务器(可选)

假如在布局文件中定义了master_ip_failover_script and/or shutdown_script ,MHA会调用那些的脚本。

关闭dead master,幸免脑裂(值得商榷)。

1.6 恢复生机一台新master

从crashed master服务器上保存binlog到Manager(即使得以的话

一旦dead master能够SSH的话,拷贝binary logs从新型的slave上的end_log_pos(Read_Master_Log_Pos)地点上马拷贝。

选举新master

貌似依据配置文件的设置来调整推选什么人,要是想设置某些候选master,设置candidate_master=1;假诺想设置有个别host,永久都不会公投,设置no_master=1;确认最新的slave (这台slave具备新型的relay-log)。

回复和晋升新master

据书上说老master binlog生成差距日志,应用日志到new master,如果这一步产生错误(如:duplicate key error),MHA截止恢复生机,况且其余的slave也停下恢复。

2)MHA怎么样在线火速切换master?

上面包车型地铁步子,正是masterha_master_switch—master_state=alive做的作业。

2.1 验证复制设置以及确认当前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 是不是低于2秒(—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=1来完善的遏止写入。

在老master上实施FLUSH TABLES WITH READ LOCK来阻止全体的写(–skip_lock_all_tables能够忽略这一步)。

2.4 等候其余slave追上前段时间master,同步无延迟

调用这一个函数MASTEXC90_LOG_POS()。

2.5 确保新master可写

举办SHOW MASTEENCORE STATUS来明确新master的binary log文件名和position。

万一设置了master_ip_online_change_script,会调用它。能够创制写权限的客户,SET GLOBAL read_only=0。

2.6 让其他slave指向新master

并行施行CHANGE MASTEPRADO, START SLAVE。

一、背景

文章大纲

  1. MHA简介
    1.1. mha组件介绍
    1.2. 背景和对象
  2. MHA原理
    2.1. MHA专门的学业规律
    2.2. MHA工具介绍
    2.3. 当前高可用方案
    2.4. MHA的优势
  3. MHA最棒实行
    3.1. 背景介绍
    3.2. 安装MySQL实例
    3.3. 部署MySQL复制
    3.4. 部署MHA软件
    3.5. 故障自动切换与在线切换

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)apply_diff_relay_logs  #辨认差距的对接日志事件并将其距离的事件采纳于别的的slave;

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

注意:为了尽或者的滑坡主库硬件损坏宕机形成的数量错过,因而在安顿MHA的还要建议配置成MySQL半手拉手复制。关于半手拉手复制原理各位本人开展查看(不是必得)。

转自:

七年多的大运里,大家DBA Team火速产生了数据库自动化、白屏化、闭环化、服务化的建设。达成了JKDB数据库自动化平台(含元数据管理、自动化安插调整系统、监控种类、备份系统、高可用和在线切换、容积趋势深入分析规划、校验中央等)、数据库自助查询平台、权限申请和审查批准平台、自助更动施行平台、流程引擎、工单系统、敏感新闻探测系统等等。

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(现就职于Instagram公司)开垦,是一套精美的当作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没办法保存二进制日志,只举办故障转移而不见了的数码。使用MySQL 5.5的半同台复制,能够大大收缩数据遗失的高风险。MHA能够与半协助举行理并答复制结合起来。要是独有叁个slave已经接到了的二进制日志,MHA能够将的二进制日志应用于别的具备的slave服务器上,因而得以确认保障全数节点的数目一致性。

在这里面,除了偶然故障和异样协助之外,DBA基本无需登入服务器去布署和操作数据。从二〇一五年到明天,大家管理的数据库实例大约翻了3倍,不过DBA人数基本未有变化,近日是4个DBA维护了约一千 的MySQL实例、1500 Redis实例,其余还维护着多少PostgreSQL / Oracle / MongoDB / Hbase集群。

1.1.mha零部件介绍

  • MHA Manager
    运转一些工具,比方masterha_manager工具完毕活动监察和控制MySQL Master和兑现master故障切换,别的工具完毕手动达成master故障切换、在线mater转移、连接检查等等。三个Manager能够管理多个master-slave集群

  • MHA Node
    配备在富有运营MySQL的服务器上,无论是master依然slave。重要职能有多少个。
    1.保留二进制日志
    假如能够访问故障master,会拷贝master的二进制日志
    2.施用差距中继日志
    从具备最新数据的slave上转移差距中继日志,然后利用差距日志。
    3.免除中继日志
    在不结束SQL线程的景况下删除中继日志

本文就将本着大家DBA Team实现的数据库自动化平台营造和中间的建设思路做一些简介,首要分享中期条件塑造和自动化模型搭建思路方面包车型大巴有个别。后续纵然大家有意思味,小编能够进一步长远的牵线一下自动化平台其余方面包车型大巴源委。

1.2.背景和指标

在刚开始阶段的MySQL架构中最主流就就是MySQL复制的主旨结构,但伴随时间的推迟以及数额的膨大会并发转手几类难点。

  • 原先几十台DB服务器,人工登入服务器就会维护好,也未有高可用,当master挂了,布告工作将IP切换成slave然后重启也能基本满意工作要求,然则工作神速升高,实例数不断充实,复制集不断充实,数据库架构种种化,而这种人造维护情势分明大大增添了DBA工作量,并且功用低下、轻便出错。

  • DB规模的增大,机器故障、SQL故障、实例故障出现的可能率也平添、还应该有来自业务方的DB改变,比方大表增加字段、扩张索引、批量去除数据等非常维护操作,当然这一个在必然标准下可用采取在线改换,例如选用pt-online-schema-change工具,然则当不满足在线退换规范、大概在线改变复杂的气象下,就要求动用滚动更改的法子,先在各种slave上改造、在线切换后再在master上改动,然后再进行三遍切换还原,而那个切换操作要是全部手工业敲命令来进行分明是不可取的。

  • 乘凌霄花户数的再三追加,业务方对DB这种基础服务的可用性也就一发高,在中兴业务对DB的可用性须要是各种月须求达到多少个9,也就象征各个月的故障时间独有不到5分钟,此前这种公告专门的职业转移IP重启的措施分明是达不到这些供给的。

    在这一个背景和须要下,大家需求摆脱手工业操作,要求一套一蹴而就的MySQL高可用方案和三个快捷的高可用平台来支撑DB的连忙增进。MySQL高可用平台需求到达的对象有以下几点:

    1.数据一致性保障这几个是最中央的同时也是前提,假若主备的数额的不相同,那么切换就不可能举行,当然这里的一致性也是一个针锋相对的,不过要到位最后一致性。
    2.故障飞速切换,当master故障时这里能够是机器故障大概是实例故障,要保险业务能在最长期切换成备用节点,使得业务受影响时间最短。这里也得以指工作例行维护操作,例如前边提到的不恐怕使用在线举办DDL的DDL操作,相当多分表批量的DDL操作,这个操作通过在线切换方式来滚动实现。
    3.简化常常维护,通过高可用平台来机关实现高可用的配备、维护、监控等职分,能够最大程度的解放DBA手动操作,进步普通运行功能。
    4.集结保管,当复制集众多的情事下,能够联合管理高可用实例音信、实例音讯、监察和控制新闻、切换音讯等。
    高可用的配备要对现存的数据库架构无影响,如若因为布署高可用,须要改动也许调解数据库架构则会促成资金大增。

关于数据库规范化营造

2.MHA原理

二零一四年,当自身入职公司时,大概经过了两周的熟知,简直开掘公司数据库自动化的黑影。

2.1.MHA专业规律

图片 3

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保存二进制日志事件(binlog events)。
  • 鉴定分别含有最新更新的slave。
  • 动用差距的连接日志(relay log)到别的slave。
  • 应用从master保存的二进制日志事件(binlog events)。
  • 进级贰个slave为新master并记录binlog file和position。
  • 使别的的slave连接新的master举办复制。
  • 变成切换manager主进度OFFLINE

其一是法规,标准化是自动化的第一前提。二零一六年,大家那边标准化是做得相比好的,从OS的原则到DB层的原则都存有统一的科班。举例OS的操作系统版本、文件系统格式、磁盘挂载点、预装软件、内核参数等等,大家具备MySQL服务器基本都是平等的。

2.2.MHA工具介绍

1.Manager工具:

  • masterha_check_ssh : 检查MHA的SSH配置。
  • masterha_check_repl : 检查MySQL复制。
  • masterha_manager : 启动MHA。
  • masterha_check_status : 检查测验当前MHA运转情形。
  • masterha_master_monitor : 监测master是还是不是宕机。
  • masterha_master_switch : 调节故障转移(自动或手动)。
  • masterha_conf_host : 增加或删除配置的server消息。

2. Node工具

  • save_binary_logs : 保存和复制master的二进制日志。
  • apply_diff_relay_logs : 识别差别的连片日志事件并行使于另外slave。
  • filter_mysqlbinlog : 去除不供给的ROLLBACK事件(MHA已不复采纳这么些工具)。
  • purge_relay_logs : 清除中继日志(不会卡住SQL线程)。
    只顾:Node这一个工具常常由MHA Manager的剧本触发,无需人手操作。

此间大家是怎么完结保持一致的啊?

2.3.脚下高可用方案

  • keepalived mysql复制
    该组织与MHA类似,但keepalived的优势在于无状态组件的故障切换,常用来web前端的故障转移,应用于数据库场景中,最致命的主题材料就是脑裂未来数据乱写的高风险,为厂家带来巨大麻烦。

  • MySQL Cluster
    MySQL Cluster真正完毕了高可用,不过使用的是NDB存款和储蓄引擎,而且SQL节点有单点故障难题。

  • 半同步复制(5.5 )
    半手拉手复制大大减弱了“binlog events只设有故障master上”的难点。在付出时,有限帮忙至少四个slave(并非享有的)接收到binlog,由此有些slave大概没有吸取到binlog。

  • PXC
    PXC达成了劳务高可用,数据同步时是出新复制。不过仅帮助InnoDB引擎,全数的表都要有主键。锁争辨、死锁难点相对很多等等难题。

先是是我们DBA对内部一台服务器经过开端化设置和优化,例如按数据库的最优政策调度基础参数,分区和挂在磁盘,预装pt-tool MHA Node Xtrbackup Innotop oak-tool等数据库常用的管理软件,然后交付给运营同学实行打包镜像,之后有所交付给DBA的服务器都以按此镜像进行布置。这样一来,大家的OS服务器就可怜规范了,同一时间也预装了笔者们常用的管理工科具。

2.4.MHA的优势

  • 障切换快
    在 主从复制集群中,只要从库在复制上从未有过延迟,MHA经常能够在数秒内达成故障切换。9-10秒内检查到master故障,能够选拔在7-10秒关闭 master防止止出现裂脑,几分钟内,将出入中继日志(relay log)应用到新的master上,因而总的宕机时间一般为10-30秒。复苏新的master后,MHA并行的还原别的的slave。尽管在有数万台 slave,也不会影响master的复原时间。
    DeNA在当先1四十九个MySQL(首要5.0/5.1本子)主从境况下利用了MHA。当mater故障后,MHA在4秒内就完事了故障切换。在观念的积极/被动集群建设方案中,4秒内成功故障切换是不容许的。

  • master故障不会变成数据不均等
    当 最近的master出现故障是,MHA自动识别slave之间连接日志(relay log)的不一样,并行使到具备的slave中。那样有着的salve能够有限协助同步,只要抱有的slave处于存活状态。和Semi- Synchronous Replication一齐利用,(大约)能够保障未有数据错失。

  • 需修改当前的MySQL设置
    MHA的陈设的基本点条件之一正是不择花招地大致易用。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/5.5的原生版本的MySQL上,所以并不须求迁移。

  • 不要扩展大气的服务器
    MHA由MHA Manager和MHA Node组成。MHA Node运维在急需故障切换/恢复的MySQL服务器上,由此并不须求额外扩张服务器。MHA Manager运维在特定的服务器上,由此必要充实一台(完成高可用要求2台),不过MHA Manager能够监督大量(以至上百台)单独的master,由此,并无需扩张大气的服务器。即便在一台slave上运维MHA Manager也是足以的。综上,完成MHA并没用额外扩张大气的劳动。

  • 无品质裁减
    MHA适用与异步或半联合举行的MySQL复制。监察和控制master时,MHA仅仅是每隔几秒(暗中认可是3秒)发送三个ping包,并不发送重查询。能够博得像原生MySQL复制同样快的性质。

  • 适用于任何存款和储蓄引擎
    MHA能够运作在只要MySQL复制运维的囤积引擎上,并不只限制于InnoDB,尽管在科学迁移的古板的MyISAM引擎情形,一样能够运用MHA。

咱们的数据库也许有和好的布署专门的学问,比方配置文件原则,除了部分可调参数是变量,其余参数全体选择原则模板;别的像MySQL的装置目录、数据目录、二进制日志目录、不时文件目录都有联合的正统,依据不一样的实例端口来区分。

3.MHA至上推行

图片 4

图表源于网络

本来MySQL严苛要完毕标准,在未到位自动化陈设从前,是比较不方便的,困难的不是计划技巧,而是法规意识。常常三个合营社都有成千上万个DBA共同管理数据库,由于从前的劳作习贯大家心爱鲁人持竿自身的不二秘籍来布署数据库,只怕未有正规配置准则、有平整不过从未严酷依照,都以无力回天做到口径的。大家是从一最先就做了原则准则和自动化安排脚本,所以大家日前线上享有数据库的配备都以规范的,为后续自动化平台建设打下了那多少个好的底子。

3.1.背景介绍

比如,大家在管理机使用如下命令,则会在对应的IP服务器上创办二个innodb_buffer_pool等于10GB的数据库实例,端口为3306,挂载设备为fioa,版本为MySQL-5.6.28-OS7-x86_64,数据库编码为utf8:

3.1.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

#pythonInstall_MySQL_Multi.py --ip=xx.xx.xx.xx --port=3306 --mem=10240 --device=/storage/fioa--mysql-version=MySQL-5.6.28-OS7-x86_64 --character=utf8

3.1.2.体系意况介绍

图片 5

图形来自原创

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

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

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

自动化创造的实例根据端口进行标准化布置,如下所示,某台服务器安装了3306、3307、3308四个端口,则陈设目录如下所示:

3.1.3.安装系统供给
  • 关系全部服务器关闭iptables、NetworkManager服务、selinux安全安插
# /etc/init.d/NetworkManager stop
# chkconfig NetworkManager off
# /etc/init.d/iptables stop
# chkconfig iptables off

/etc/selinux/config 改成disable

配置文件路线:

3.2.安装MySQL实例

/etc/my3306.cnf

3.2.1.安装mysql数据库
  • 创建mysql用户
# useradd mysql
# passwd mysql
  • 安装软件
# yum -y install mysql-community-server.x86_64

/etc/my3307.cnf

3.2.2.创设布局文件目录
# mkdir /etc/mysql

/etc/my3308.cnf

3.2.3.创办布局文件
[mysqld]
# GENERAL #
user                           = mysql
port                           = 3389
default_storage_engine         = InnoDB
socket                         = /data1/db3389/my3389.sock
pid_file                       = /data1/db3389/mysql.pid
#read-only =0
tmpdir                  = /data1/tmp
#key_buffer_size                = 128M
max_allowed_packet             = 32M
max_connect_errors             = 1000000
datadir          = /data1/db3389/
log_bin = 2171303389-bin
relay-log=  2171303389-relay-bin
expire_logs_days               = 7
#sync_binlog                    = 0
tmp_table_size                 = 32M
max_heap_table_size            = 32M
max_connections                = 5000
thread_cache_size              = 512
table_definition_cache         = 4096
table_open_cache               = 4096
wait_timeout            = 28800
interactive_timeout     = 28800
transaction-isolation = READ-COMMITTED
binlog-format=row
character-set-server=utf8
skip-name-resolve
back_log=1024
explicit_defaults_for_timestamp=true
server_id=2171303389

# INNODB #
innodb_flush_method            = O_DIRECT
#innodb_data_home_dir = /data1/db3389
innodb_data_file_path = ibdata1:100M:autoextend
#redo log
#innodb_log_group_home_dir=./
innodb_log_files_in_group      = 3
innodb_log_file_size           = 128M
#innodb performance
innodb_flush_log_at_trx_commit = 0
innodb_file_per_table          = 1
innodb_buffer_pool_instances   = 8
innodb_io_capacity             = 2000
innodb_lock_wait_timeout       = 30
binlog_error_action = ABORT_SERVER
innodb_buffer_pool_size        = 128M
innodb_max_dirty_pages_pct=90
innodb_file_format=Barracuda
innodb_support_xa=0
innodb_buffer_pool_dump_at_shutdown = 1
innodb_buffer_pool_load_at_startup = 1
#innodb undo log
innodb_undo_tablespaces=4
innodb_undo_logs=2048
innodb_purge_rseg_truncate_frequency=512
innodb_max_undo_log_size=2G
innodb_undo_log_truncate=1

log_error                      = error.log
#log_queries_not_using_indexes = 1
slow_query_log                 = 1
slow_query_log_file            = slow-queries.log
long_query_time=2
gtid_mode=ON
enforce-gtid-consistency
log-slave-updates
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync_master_info = 10000
slave_sql_verify_checksum=1
skip-slave-start
init-connect='SET NAMES utf8'
character-set-server=utf8
skip-character-set-client-handshake
bind-address=0.0.0.0
skip-external-locking
slave-parallel-workers=6

[mysql5.6]
myisam_recover                 = FORCE,BACKUP

数据库安装路线:

3.2.4.创建授权目录
# mkdir -p /data1/db3389
# mkdir -p /data1/tmp
# chown -R mysql:mysql /data1/db3389
# chown -R mysql:mysql /data1/tmp

/storage/fioa/mysql3306:

3.2.5.初始化MySQL实例
# mysqld --defaults-file=/etc/mysql/my3389.cnf --initialize --user=mysql
# mysql_ssl_rsa_setup 

binlog

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=''; #重置密码为空

data

3.3.部署MySQL复制

mysql-error.log

3.3.1.主库创立复制客商
mysql> grant replication slave, replication client on *.* to replica@'192.168.217.%' identified by 'mycatDBA';

mysql-tmpdir

3.3.2.主库成立mha客户
mysql> grant all privileges on *.* to mha@'192.168.217.132' identified by 'mysqlDBA';

/storage/fioa/mysql3307:

3.3.3.主库备份数据库
# mysqldump -S /data1/db3389/my3389.sock --single-transaction --master-data=2 --opt -A | gzip >  /data1/tmp/full_3389.tar.gz

binlog

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

data

3.3.5.从库复苏数据库
# gunzip < /data1/tmp/full_3389.tar.gz | mysql -S /data1/db3389/my3389.sock

注意:苏醒数据库前,从库最棒reset master;,不然将面世转手不当:
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

mysql-error.log

3.3.6.从库发轫化同步数据
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
...... 省略 ......

mysql-tmpdir

3.4.部署MHA软件

/storage/fioa/mysql3308:

3.4.1.装置软件
  • epel yum源安装格局
# yum -y install perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
# #根据MHA角色安装对应的软件包即可
# yum -y --nogpgcheck install mha4mysql-node-0.57-0.el7.noarch.rpm
# yum -y install --nogpgcheck mha4mysql-manager-0.57-0.el7.noarch.rpm
  • 本土安装情势
# yum -y --nogpgcheck install perl-DBD-MySQL*
# yum -y --nogpgcheck install perl-Config-Tiny*
# yum -y --nogpgcheck install perl-Parallel-ForkManager*
# yum -y --nogpgcheck install  perl-MailTools*
# yum -y --nogpgcheck install perl-Email-Date-Format*
# yum -y --nogpgcheck install perl-Mail-Sender*
# yum -y --nogpgcheck install perl-MIME-Types*
# yum -y --nogpgcheck install perl-MIME-Lite*
# yum -y --nogpgcheck install perl-Mail-Sendmail*
# yum -y --nogpgcheck install perl-Log-Dispatch*
# #根据MHA角色安装对应的软件包即可 
# yum -y --nogpgcheck install mha4mysql-node-0.57-0.el7.noarch.rpm
# yum -y install --nogpgcheck mha4mysql-manager-0.57-0.el7.noarch.rpm

binlog

3.4.2.挂在VIP
  • master
# /sbin/ifconfig eth0:1 192.168.217.201 broadcast 192.168.217.255 netmask 255.255.255.0
# /sbin/arping -f -q -c 5 -w 5 -I eth0 -s 192.168.217.201 -U 192.168.217.2

data

3.4.3.配置SSH互信

在现网情况中大概都是明确命令禁止root远程登入服务器得,所以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-error.log

3.4.4.配置mysql用户sudo权限
  • 加多普通客户登入tty终端权限
# vim /etc/sudoers

#将以下的参数注释,意思就是sudo默认需要tty终端。注释掉就可以在后台执行了。
#Defaults    requiretty
  • 开放普通顾客推行sudo命令权限
# cd /etc/sudoers.d/
# vim mysql

User_Alias  MYSQL_USERS = ALL
Runas_Alias MYSQL_RUNAS = root
Cmnd_Alias  MYSQL_CMNDS = ALL
MYSQL_USERS ALL = (MYSQL_RUNAS) NOPASSWD: MYSQL_CMNDS

mysql-tmpdir

3.4.5.创立MHA配置文件
  • 创造布局文件目录
# mkdir /etc/mha
  • 创办MHA配置文件
# cat app3389.cnf 
[server default]
user=mha
password=mysqlDBA
manager_workdir=/data1/mha/masterha/app3389
manager_log=/data1/mha/masterha/app3389/app3389.log
remote_workdir=/data1/mha/masterha/app3389
ssh_user=mysql
repl_user=replica    
repl_password=mycatDBA
ping_interval=3         

secondary_check_script="masterha_secondary_check -s 192.168.1.122 -s 192.168.1.122"
master_ip_failover_script="/etc/mha/master_ip_failover.sh 192.168.1.201 1"
master_ip_online_change_script="/etc/mha/master_ip_online_change.sh 192.168.1.201 1"
shutdown_script="/etc/mha/power_manager"
#report_script="/etc/mha/end_report"

[server1]
hostname=192.168.1.120
port=3389
master_binlog_dir=/data1/db3389
candidate_master=1   
master_pid_file=/data1/db3389/mysql.pid               

[server2]
hostname=192.168.1.121
port=3389
master_binlog_dir=/data1/db3389
candidate_master=1
master_pid_file=/data1/db3389/mysql.pid    

[binlog1]
hostname=192.168.1.122
master_binlog_dir=/data1/mha/binlog/3389
no_master=1
ignore_fail=1

如此那般布署的数据库到达了准星的水准,所以大家DBA只要知道IP和端口,就足以很轻巧地领悟那些实例的具有新闻,无疑是自动化的美丽基础。

3.4.6.上传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

二、自动化职务平台营造

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

有了好的准则基础,大家就起来动手营造平台了。

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

既是作为平台,那么WEB管理分界面、职分调治、API服务多少个基本部分是不得以少的。上边展示二个建设初期的三个基础架构:

3.4.9.验证并运转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

图片 6

3.5.故障自动切换与在线切换

如上海体育地方所示,自上而下,系统主旨部分由3层架构重组:

3.5.1.故障切换
  • 主库down也许主机down,然后测验切换是还是不是成功。
  • 首先层为WEB调整层;
  • 其次层为天职管理层和数码搜罗层,用于别的调整管理和多少的相互管理;
  • 其三层为办事模块层,用于落到实处各职能的功效,举个例子设置实例、配置Replication、配置MHA、创造数据库、授权等等,那些都以由不一样的平底模块来实现,平日由一多级脚本组成。
3.5.2.在线切换

在线切换(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达成,然后开展三遍主备切换操作,再在本来的主库上进行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.

围观下方二维码关怀自己微复信号!接待我们沟通学习!

图片 7

Bruce.Liu





再正是系统将提供Restful API用于内部数据更新,提供HTTP API用于外界系统接入,举个例子和CMDB、发表平台等平日完结数量分享和天职交接,提供音讯通告功用用于发送各种报告警察方和服务类的文告作用,提供职务上报效用用于各工作模块和WEB层的消息联网。

本来,早先时期我们数据库平台和中间件团队、SA共青团和少先队、配置基本组织做到了过多多少和法力的接入,塑造了数据库管理的闭环,比如CDMD创造好DB的能源后会通过我们的API将机械音讯推送到元数据焦点,我们也会调用DNS平台的服务接口来改造DNS,或许大家的阳台自动化安排完数据库后会将域名、端口、授权顾客密码自动推送到发表平台达成数据库自动配置,开垦在布置基本报名git库时就足以联手申请数据库等等。

通过DB平台和市廛任何单位的平台相互打通,减弱了非常多人造操作环节,完成了数据库管理闭环。

如下图所示为大家平台进一步详细的框架结构图:

图片 8

系统的着力是任务调解处理层,大家职分管理的分界面如下所示,能够观望各种任务都有八个职责模块名称,并实时记录义务履市价况和实行日志:

图片 9

三、关于模块化设计构建

在地点我们大致介绍了系统的基础架构,里面涉及了底部职分模块,比如设置实例、成立主从模块等等,那么这么些模块底层如何优雅地设计啊?

大家平台从起头规划时后端代码层就依据高内聚、低耦合的规划观念进了模块化开垦,那是大家后端设计的核情感想。

许两人在想,代码完毕效果与利益不就好了吗?还索要哪些规划理念?那可能也等于开拓与运营同学的观念差距。

咱俩精晓运行同学时一时无暇比很多零碎的作业,效能优先,也习贯于脚本化开荒,恐怕分分钟就写叁个剧本实现有个别成效。但是在凉台建设中,这种艺术是不可取的。要是代码未有正规的记挂教导,当多少人同台开拓的进度中,很难展开项目标保管和跟进。

大家在规划时,在坚守模块化开垦合计的还要,依照任务意况,设计出了职务三层调整情势,类似聚成堆木格局,能够飞速地做到不相同须要的尾部职务模块,同一时间可维护性可极高。别的正是复用和平化解耦,模块不容许同级模块相互调用和依附,只允许高级模块调用低端模块。

如上边所示:

图片 10

上面那幅图能够很好的疏解底层的三级模块调用流程:

图片 11

  • Level 1为底层扶助模块:比方SSH操作模块、MySQL连接和操作模块、音讯模块(短信,邮件,内部音讯)、日志模块、外界接口模块(DNS更动,CDMD同步等)、元数据珍重模块(meatdata)等。
  • Level 2为根基单元模块:譬喻设置MySQL节点、配置基本、配置MHA、成立数据库、DB授权等等,那些都是二级模块,基本正是完成某四个一定作用。注意Level 2里代码除了专门的学业逻辑部分,其他只必要调用Level 1的模块就可以。比如下边是一个安装MySQL实例的截图,属于二级模块:
  • Level 3则为服务模块:当真平时利用的模块,都以调用Level 2模块来拓宽打包的。举例在一般业务方使用数据库中,DBA至少必要设置2个实例,配置个主从复制,也亟需配备MHA,当然备份和监督配置也不能够少。那个干活儿三个DBA来产生平日大半天日子过去了。那么一旦供给配备10套呢?会开支更加多的光阴。所以这种意况下就须要一键布署,一键通通解决。谈起此处,还会有二个主题材料——我们大概也细心到了安装实例、创设数据库等这一个纯粹模块在Level 2模块都有,那么Level 3干嘛呢?其实便是调用Level 2就足以了。如下是一键陈设页面截图,DBA填写好交给职责就能够,剩下的时候就能够管理任何干活了:

图片 12

下一场大家监察和控制上报的职务日志能够观望底层奉行进度,大家能够见到义务会创制2个实例,然后配置了骨干,最终布置了MHA,当然这里面还可能有局地元数据爱护,备份和监督检查按键设置等等,其实在后台已经做到了。差不离6秒钟,完毕了贰个DBA半天的职业,而且保险了安插的数据库都是标准化的,分裂DBA计划未有别的异样。

图片 13

再举别的三个气象例子,平时集团对基本大工作会做TDDL分库分表,比方十库百表、百库千表,必要配备在不一样的物理机,那时候大家就付出了TDDL批量安插模块,基本正是包装并行职分调用Level 2模块的逐个模块,比方成立玖18个数据库sharding的TDDL集群,无非就是并行调用200次安装MySQL实例的模块,然后调用玖19回配置主旨,调用玖拾叁回配置MHA,最终发个音讯通告。一般手工业操作供给1-2天时间的天职几十一分钟就马到功成了。

图片 14

有了上述自动化职务调整平台和设计标准作为基础,大家DBA基本都连忙参加举行了举办模块开荒。模块开辟的功利正是大家很轻易上手开荒,以致以前有不会Python的同学,在简约学习了Python之后也能一无所成反类犬异常快完结一个模块。

在豪门的共同努力下,MySQL以及Redis平日安顿和护卫专业都达成了职务调节化管理。常常必要大家登陆服务器的操作未来着力都在WEB分界面端就完毕了。一般除了须要登服务器定位难点和管理线上故障,基本就白屏化了数据库管理。

这般下来,对于任何集团来讲功用高了,DBA不必要那么多了,数据库人为故障也少了;但对个体来讲,职业工作就相当受了挑衅,时机也少了,所以个人的进化只可以说根本是看本人,靠本人。

末段讲一点题外话,平日看到某些篇章在讲数据库自动化、未来AI智能化,预测现在DBA或然会下岗。那么些思想小编是二分之一确定的:随着比比较多商城的自动化更加的健全,或许供给的DBA会更少,但本人认为DBA这一个职责在别的时候都不会被淘汰。

即便数据库完全自动化后,难免对DBA的工作发展产生影响,但换个角度来看,留给DBA思虑立异、升高本身价值的日子也更加多了。其实从数据库在店堂的严重性和敏感性来看,从作业向手艺转移进度中,DBA作为数据库的专门的职业评定核查员,发挥的功能是另外职责所不能代替的。而以后DBA应该做的,是试着转换观念去接受一些新东西,比方可以品味开垦,参预到平台支付中,或然学习有些大数额、机器学习有关的技巧,又大概更深远钻研数据库。小编信任,只要本人拼命,是白银总会发光的。回去天涯论坛,查看更加多

主编:

本文由云顶娱乐发布于互联网科技,转载请注明出处:MySQL基于MHA高可用理论篇

关键词: 云顶娱乐

上一篇:Magic Leap成立瑞士洛桑团队,专注于光学和光电子

下一篇:没有了