MySQL基于MHA高可用理论篇,DBA应有的数据库自动化建设思路

图片 14

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

图片 1

MySQL高可用系统

MySQL高可用,望文生义正是当MySQL主机或劳务发生任何故障时能够即时有其余主机顶替其行事,何况最低供给是要保险数据生龙活虎致性。由此,对于二个MySQL高可用系统供给高达的靶子有以下几点:

(1卡塔 尔(英语:State of Qatar)、数据后生可畏致性保险这一个是最大旨的同一时间也是前提,假若主备的数据不近似,那么切换就无法進展,当然这里的大器晚成致性也是三个争持的,可是要做到最后生龙活虎致性。

(2卡塔 尔(英语:State of Qatar)、故障飞速切换,当master故障时这里能够是机器故障或许是实例故障,要承保工作能在最长期切换成备用节点,使得业务受影响时间最短。

(3卡塔尔国、简化平时维护,通过高可用平台来机关达成高可用的安插、维护、监察和控制等职务,能够最大程度的解放DBA手动操作,升高普通运转成效。

(4卡塔尔、统大器晚成保管,当复制集众多的气象下,能够归并保管高可用实例新闻、监察和控制讯息、切换音信等。

(5卡塔尔国、高可用的配置要对现成的数据库架构无影响,尽管因为安插高可用,要求订正恐怕调治数据库架构则会导致资金扩展。

一时一刻MySQL高可用方案得以不容争辩水平上完结数据库的高可用,比如MMM,heartbeat+drbd,NDB
Cluster等。还恐怕有玛丽亚DB的Galera Cluster,以至MySQL 5.7.17 Group
Replication等。那个高可用软件各有高低。在进展高可用方案选用时,首假使看事情对数码豆蔻梢头致性方面包车型地铁须求。最后由于对数据库的高可用和高可信的供给,最近推荐应用MHA架构,因为MySQL
GP还不可能在分娩应用,可是相信之后渐次就能够被用到生育境况的。

作者介绍茹作军,曾供职笔者查看运营程序员、1号店MySQL
DBA,现就职于平安好先生。Lepus开源数据库监察和控制系统小编(www.lepus.cc卡塔 尔(英语:State of Qatar)。

图表来源于网络

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,风华正茂主风度翩翩从(实地度量过的卡塔 尔(英语:State of Qatar)。

小结一下,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

业务与技艺往往是协同前行的,二〇一六年,作者走入平安好先生,在事情迅猛升高的同期,大家的数据库自动化平台也赢得了高速的建设和发展。

文/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不是同三个卡塔 尔(英语:State of Qatar),那么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,同步无延迟

调用那些函数MASTELAND_LOG_POS()。

2.5 确保新master可写

实行SHOW MASTE3 Wheeler STATUS来规定新master的binary log文件名和position。

借使设置了master_ip_online_change_script,会调用它。能够制造写权限的客商,SET
GLOBAL read_only=0。

2.6 让其他slave指向新master

并行实行CHANGE MASTE牧马人, 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卡塔 尔(英语:State of Qatar)用Perl写的后生可畏套Mysql故障切换方案,来维全面据库的高可用性,它的作用是能在0-30s之内达成主Mysql故障转移(failover卡塔尔,MHA故障转移可以很好的帮我们肃清从库数据的意气风发致性难点,同期最大化挽救故障产生后数据的风姿浪漫致性。
官方网站:https://code.google.com/p/mysql-master-ha/

MHA(Master High
Availability卡塔尔国近年来在MySQL高可用方面是叁个针锋相投成熟的解决方案,它由东瀛DeNA公司youshimaton(现就职于推特公司卡塔尔开拓,是生龙活虎套精美的当做MySQL高可用性格形下故障切换和骨干升高的高可用软件。在MySQL故障切换进程中,MHA能做到在0~30秒之内自动完结数据库的故障切换操作,而且在拓宽故障切换的长河中,MHA能在十分大程度上保险数据的风度翩翩致性,以高达真正含义上的高可用。

该软件由两片段组成:MHA Manager(管理节点卡塔尔和MHA Node(数据节点卡塔 尔(英语:State of Qatar)。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维护了约1000+的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卡塔 尔(英语:State of Qatar),如若得以访谈(不是硬件故障,比方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五贰11个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台卡塔 尔(英语:State of Qatar),然则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.

极目远望下方二维码关注小编Wechat号!招待大家交换学习!

图片 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连接和操作模块、新闻模块(短信,邮件,内部音讯卡塔 尔(英语:State of Qatar)、日志模块、外界接口模块(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实例的模块,然后调用九十六次配置中心,调用玖十五遍配置MHA,最后发个消息文告。平常手工业操作需求1-2天时间的天职几十分钟就形成了。

图片 14

有了上述自动化职分调整平台和设计标准作为底工,大家DBA基本都非常快加入进行了进行模块开垦。模块开荒的好处便是大家十分轻易上手开采,甚至在此以前有不会Python的同班,在简易学习了Python之后也能依样画葫芦超快完毕二个模块。

在大家的同盟努力下,MySQL甚至Redis平常安顿和掩护工作都达成了职分调治化管理。经常须要我们登陆服务器的操作今后主导都在WEB分界面端就产生了。平日除了供给登服务器定位问题和管理线上故障,基本就白屏化了数据库管理。

那般下去,对于整个公司来讲效能高了,DBA无需那么多了,数据库人为故障也少了;但对个体来说,专业专门的学问就遭逢了挑衅,机遇也少了,所以个人的前行只能说注重是看本人,靠自身。

聊到底讲一点题外话,平时见到有的作品在讲数据库自动化、今后AI智能化,预测以后DBA只怕会下岗。这几个视角笔者是二分之大器晚成承认的:随着非常多合营社的自动化越来越周密,也许必要的DBA会更加少,但本身感到DBA这几个职分在其他时候都不会被淘汰。

虽说数据库完全自动化后,难免对DBA的职业发展引致影响,但换个角度来看,留给DBA思谋立异、提高自身价值的小运也愈来愈多了。其实从数据库在铺子的第大器晚成和过敏性来看,从业务向技巧调换进度中,DBA作为数据库的行业内部评定核实员,发挥的信守是任何职位所不大概替代的。而以往DBA应该做的,是试着调换理念去接纳一些新东西,比方能够尝试开荒,参与到平台开辟中,恐怕学习有些大数量、机器学习相关的本领,又也许更通透到底研究数据库。小编言从计听,只要本人努力,是金子总会发光的。回来乐乎,查看越多

小编:

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图