MHA构建MySQL高可用平台最佳实践,白屏化背后

日期:2019-11-01编辑作者:精彩专题

原标题:白屏化背后,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(现就职于推特(Twitter)企业)开辟,是生龙活虎套精美的作为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

作业与才干往往是协作前行的,2014年,小编进入平安好先生,在事情迅猛上扬的还要,我们的数据库自动化平台也获得了急速的建设和升华。

文/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,同步无延迟

调用那么些函数MASTEPRADO_LOG_POS()。

2.5 确保新master可写

施行SHOW MASTE奇骏 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)用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(数据节点)。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这种基础服务的可用性也就更是高,在HUAWEI业务对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在超越150个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模块的逐个模块,比如创造玖20个数据库sharding的TDDL集群,无非正是并行调用200次安装MySQL实例的模块,然后调用玖18次配置中央,调用九17次配置MHA,最后发个音信公告。平日手工业操作必要1-2天时间的职务几十分钟就完了了。

图片 14

有了上述自动化任务调治平台和设计标准作为基础,大家DBA基本都麻利参预实行了开展模块开辟。模块开垦的实惠正是咱们比较轻便上手开荒,以致此前有不会Python的同学,在简单学习了Python之后也能一成不改变非常的慢成功二个模块。

在豪门的合营努力下,MySQL以至Redis平日计划和有限支撑职业都落到实处了任务调治化管理。平日须要大家登陆服务器的操作现在为主都在WEB分界面端就做到了。平常除了供给登服务器定位问题和管理线上故障,基本就白屏化了数据库管理。

如此下去,对于任何集团来说功能高了,DBA无需那么多了,数据库人为故障也少了;但对私有来讲,专门的学问专门的学业就深受了挑战,时机也少了,所以个人的进步只可以说根本是看本身,靠自个儿。

最后讲一点题外话,日常见到一些稿子在讲数据库自动化、现在AI智能化,预测今后DBA恐怕会无业。那几个意见小编是二分之黄金年代确认的:随着超多供销合作社的自动化越来越康健,大概必要的DBA会越来越少,但自己感到DBA这一个任务在任曾几何时候都不会被淘汰。

虽说数据库完全自动化后,难免对DBA的事情发展导致影响,但换个角度来看,留给DBA思量修改、提高自己价值的年月也越多了。其实从数据库在市廛的首要和过敏性来看,从作业向本领转变进程中,DBA作为数据库的行业内部评定调查员,发挥的功力是其余职责所不能替代的。近日后DBA应该做的,是试着调换观念去接纳一些新东西,举例能够尝试开垦,插足到阳台支付中,只怕学习一些大数据、机器学习有关的本领,又大概更浓重钻研数据库。笔者相信,只要自个儿拼命,是纯金总会发光的。回来博客园,查看越多

责编:

本文由澳门新葡亰手机版发布于精彩专题,转载请注明出处:MHA构建MySQL高可用平台最佳实践,白屏化背后

关键词:

在自动化的未来,人工智能时代下的仓库镇守者

原标题:Washington邮报:人工智能时期下的仓库镇守者 美利坚合众国新泽西州南部,有一家亚马逊(Amazon)的大宾馆...

详细>>

专注于光学和光电子研究,腾讯与印钞造币总公

原标题:Magic Leap成立瑞士洛桑团队,专注于光学和光电子研究 原标题:腾讯与印钞造币总公司合作推出“人民币防伪...

详细>>

腾讯与印钞造币总公司合作推出,作者尼尔

原标题:《雪崩》我尼尔·Stephenson领导着Magic Leap金奈团队 原标题:Magic Leap创造Switzerland加纳阿克拉共青团和少先队,...

详细>>

嵌入式招聘岗位,搞机器学习没前途

原标题:“搞机械学习没前程” iOS是眼下最棒流行、最吃香的操作系统之生机勃勃,在国内外全体不行替代的地位,...

详细>>