(2)、故障快速切换,图片来自网络

2019-11-11 17:20 来源:未知

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

www.129028.com 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(现就职于Facebook公司)开发,是一套优秀的作为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

业务与技术往往是共同前进的,2016年,我加入平安好医生,在业务快速发展的同时,我们的数据库自动化平台也得到了快速的建设和发展。

文/Bruce.Liu1

MHA工作流程

下图展示了如何通过MHA Manager管理多组主从复制,可以将MHA工作原理总结为如下:

www.129028.com 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)位置开始拷贝。

www.129028.com,选举新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,同步无延迟

调用这个函数MASTER_LOG_POS()。

2.5 确保新master可写

执行SHOW MASTER STATUS来确定新master的binary log文件名和position。

如果设置了master_ip_online_change_script,会调用它。可以创建写权限的用户,SET GLOBAL read_only=0。

2.6 让其他slave指向新master

并行执行CHANGE MASTER, 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(现就职于Facebook公司)开发,是一套优秀的作为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基本不需要登录服务器去部署和操作数据。从2016年到现在,我们管理的数据库实例大概翻了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原理

2016年,当我入职公司时,大概经过了两周的熟悉,俨然发现公司数据库自动化的影子。

2.1.MHA工作原理

www.129028.com 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最佳实践

www.129028.com 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.系统环境介绍

www.129028.com 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复制

TAG标签:
版权声明:本文由www.129028.com-澳门金沙唯一官网www129028com发布于互联网资讯,转载请注明出处:(2)、故障快速切换,图片来自网络