如上面所示:

叁.二.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

MHA职业流程

下图展现了什么通过MHA
Manager管理多组主从复制,能够将MHA职业规律计算为如下:

图片 1

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

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

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

要是中间有任何三个slave挂了,脚本立时退出,停止监察和控制。

假若有部分必不可缺的本子未有在MHA
Node节点安装,那么MHA在这些等第终止,且甘休监察和控制。

1.2 监控master

监控master,直到master挂了。

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

一.3 检查测试master是还是不是败北

假诺MHA Manger一次间隔时间都不能够连接master server,就会进来这几个品级。

固然你设置了secondary_check_script
,那么MHA会调用脚本做二回检查评定来判断master是还是不是是真的挂了。

接下去的步调,正是masterha_master_switch的办事流程了。

一.4 重新验证slave的布署

若是发掘别的不合规的复制配置(有个别slave的master不是同三个),那么MHA会截至监察和控制,且报错。能够安装ignore_fail忽略。

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

检查最后2遍failover(故障转移)的情状

假诺上三遍的failover报错,或许上2次的failover结束的太近(默许3天),MHA甘休监察和控制,甘休failover,那么在masterha_manager命令中安装ignore_last_failover,wait_on_failover_error来改造那1检查实验。这么做,也是出于安全思索。频仍的failover,检查下是还是不是网络出标题,只怕其余错误吗?

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

只要在布局文件中定义了master_ip_failover_script and/or
shutdown_script ,MHA会调用这个的剧本。

关闭dead master,幸免脑裂(值得一说道)。

1.陆 恢复生机一台新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=一;确认最新的slave
(那台slave具有新型的relay-log)。

复原和进级新master

依靠老master binlog生成差距日志,应用日志到new
master,假如这一步产生错误(如:duplicate key
error),MHA截止苏醒,并且别的的slave也停下复苏。

二)MHA怎么着在线飞快切换master?

下边包车型客车步骤,正是masterha_master_switch—master_state=alive做的作业。

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

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

实施 flush tables 命令在master上(可选). 那样能够减少FLUSH TABLES WITH
READ LOCK的年月。

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

检查下边包车型客车标准是不是满意。

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

B. SQL线程是或不是在具备slave上都以running。

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

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

2.2 确认新master

新master要求安装: –new_master_host参数。

本来的master和新的master必须求有一致的复制过滤条件(binlog-do-db and
binlog-ignore-db)。

2.3 当前master停写

借使您在配备中定义了master_ip_online_change_script,MHA会调用它。能够透过安装SET
GLOBAL read_only=一来宏观的阻碍写入。

在老master上实行FLUSH TABLES WITH READ
LOCK来堵住全部的写(–skip_lock_all_tables能够忽略这一步)。

2.四 等候其余slave追上近来master,同步无延迟

调用这么些函数MASTEMurano_LOG_POS()。

2.5 确保新master可写

试行SHOW MASTEKuga STATUS来明确新master的binary log文件名和position。

要是设置了master_ip_online_change_script,会调用它。能够创立写权限的用户,SET
GLOBAL read_only=0。

2.6 让其他slave指向新master

并行实施CHANGE MASTE安德拉, START SLAVE。

数据库安装路线:

三.5.一.故障切换
  • 主库down只怕主机down,然后测试切换是还是不是成功。

MySQL高可用系统

MySQL高可用,顾名思义便是当MySQL主机或服务发生任何故障时亦可即时有别的主机顶替其职业,并且最低须要是要保障数据1致性。因而,对于一个MySQL高可用系统要求实现的靶子有以下几点:

(一)、数据一致性保险那一个是最核心的还要也是前提,假诺主备的多少不平等,那么切换就不可能展开,当然那里的一致性也是多少个周旋的,不过要形成最终1致性。

(二)、故障快捷切换,当master故障时那里能够是机器故障只怕是实例故障,要力保业务能在最长时间切换来备用节点,使得业务受影响时间最短。

(3)、简化平日维护,通过高可用平台来机关实现高可用的陈设、维护、监察和控制等任务,能够最大程度的解放DBA手动操作,进步普通运转作效果用。

(4)、统壹管理,当复制集众多的景观下,能够合并保管高可用实例音信、监察和控制音讯、切换消息等。

(伍)、高可用的安插要对现存的数据库架构无影响,要是因为计划高可用,需求改变恐怕调解数据库架构则会导致费用扩张。

时下MySQL高可用方案得以肯定水准上贯彻数据库的高可用,比方MMM,heartbeat+drbd,NDB
Cluster等。还有玛丽亚DB的Galera Cluster,以及MySQL 伍.7.1七 Group
Replication等。这几个高可用软件各有上下。在举办高可用方案选拔时,重借使看业务对数据一致性方面包车型大巴供给。最终由于对数据库的高可用和高可相信的渴求,近期推荐应用MHA架构,因为MySQL
GP还无法在生产应用,可是相信之后渐次就会被用到生育情形的。

/storage/fioa/mysql3306:

3.四.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

MHA组件介绍

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

Manager工具包重要包涵以下多少个工具:

(1)masterha_check_ssh    #自己争辨MHA的SSH配置处境;

(2)masterha_check_repl    #反省MySQL复制场景;

(3)masterha_manger    #启动MHA;

(4)masterha_check_status  #检查实验当前MHA运维情况;

(5)masterha_master_monitor  #检查测试master是或不是宕机;

(6)masterha_master_switch    #决定故障转移(自动可能手动);

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

Node工具包(这个工具常常由MHA
Manager的本子触发,无需人工操作)首要不外乎以下多少个工具:

(1)save_binary_logs      #封存和复制master的2进制日志;

(2)apply_diff_relay_logs 
#辨认差别的连通日志事件并将其距离的轩然大波选择于任何的slave;

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

注意:为了尽可能的削减主库硬件损坏宕机形成的多寡丢失,由此在配备MHA的还要建议配置成MySQL半共同复制。关于半协同复制原理各位自身举行查看(不是必须)。

转自:

虽说数据库完全自动化后,难免对DBA的事情发展导致影响,但换个角度来看,留给DBA思量立异、进步自笔者价值的小运也越来越多了。其实从数据库在合营社的要害和过敏性来看,从作业向技能转变进程中,DBA作为数据库的行业内部评定审查员,发挥的成效是任何义务所不可能取代的。而现在DBA应该做的,是试着调换观念去接受一些新东西,比方能够尝试开拓,到场到阳台支付中,可能学习一些大数据、机器学习有关的本领,又只怕更彻底钻研数据库。笔者相信,只要自个儿拼命,是黄金总会发光的。再次来到博客园,查看越多

3.2.1.安装mysql数据库
  • 创建mysql用户

# useradd mysql
# passwd mysql
  • 安装软件

# yum -y install mysql-community-server.x86_64

MHA才具介绍

MHA(Master High
Availability)目前在MySQL高可用方面是贰个对峙成熟的缓和方案,它由东瀛DeNA集团youshimaton(现就职于Instagram公司)开采,是壹套精美的当作MySQL高可用性景况下故障切换和宗旨进步的高可用软件。在MySQL故障切换进程中,MHA能成就在0~30秒之内自动落成数据库的故障切换操作,并且在拓展故障切换的进度中,MHA能在最大程度上保障数据的一致性,以高达真正含义上的高可用。除了failover之外,MHA还扶助在线master切换,万分安全和赶快,大致只需求(0.伍
~ 二秒)的围堵写时间。

该软件由两有的构成:MHA Manager(管理节点)和MHA Node(数据节点)。MHA
Manager能够独立陈设在1台独立的机器上管理多少个master-slave集群,也得以布署在1台slave节点上。MHA
Node运转在每台MySQL服务器上,MHA
Manager会定时探测集群中的master节点,当master出现故障时,它能够活动将新型数据的slave升高为新的master,然后将具备别的的slave重新指向新的master。整个故障转移进度对应用程序完全透明。

日前MHA重要支撑1主多从的架构,要搭建MHA,供给多个复制集群中务必至少有三台数据库服务器,壹主贰从,即一台充当master,1台充当备用master,其余一台充当slave。当然,要是您处于资金思考,也能够利用两个节点的MHA,壹主1从(实地测量过的)。

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

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

(二)MHA能够在三个复制组中监察和控制master的状态,假诺挂了,就可以活动的做failover。

(三)MHA通过全部slave的差距relay-log来保障数据的壹致性。

(四)MHA在做故障转移,日志补偿那些动作的时候,常常只须求十~30秒。

(5)经常状态下,MHA会选拔新型的slave作为new
master,然则你也得以钦定哪些是候选maser,那么新master公投的时候,就从这么些host里面挑。

(陆)导致复制境遇中断的1致性难题,在MHA中是不会发出的,请放心使用。

在MHA自动故障切换进程中,MHA试图从宕机的主服务器上保留2进制日志,最大程度的保险数据的不丢掉,但那并不几次三番实惠的。比方,即使主服务器硬件故障或不可能透过ssh访问,MHA无法保存二进制日志,只实行故障转移而丢掉了新型的数码。使用MySQL
伍.伍及以上版本的半齐声复制,能够大大下落数据丢失的高危机。MHA能够与半同步复制结合起来。假诺唯有多个slave已经收到了最新的2进制日志,MHA能够将风尚的贰进制日志应用于其余具有的slave服务器上,由此得以确定保证全数节点的数目1致性。

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

MHA能够布署成手工业-交互式方式开始展览故障转移,不协助监督master的动静。

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

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

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

如果您有更加快,越来越好的master,布置要将老master替换到新的master,那么那个职能特别吻合那样的光景。

那不是master真的挂掉了,只是我们有为数不少必要要实行master例行维护。

MHA的优点

  1. master failover和slave promotion万分急迅。

二. 电动探测,多种检查评定,切换进度中补助调用其余脚本的接口。

  1. master crash不会促成数据不平等,自动补齐数据,维护数据一致性。

  2. 不需求修改复制的其余设置,轻易易安排,对现有架构无影响。

  3. 不供给追加诸多外加的机械来安排MHA,帮助多实例集中管理。

  4. 从不别的性质影响。

  5. 支撑在线切换。

  6. 跨存款和储蓄引擎,扶助任何引擎。

官方介绍:https://code.google.com/p/mysql-master-ha

自动化成立的实例遵照端口实行规范部署,如下所示,某台服务器安装了330陆、330柒、330八八个端口,则配备目录如下所示:

1.1.mha零件介绍

  • MHA Manager
    运作一些工具,比方masterha_manager工具落成自动监察和控制MySQL
    Master和兑现master故障切换,其余工具实现手动达成master故障切换、在线mater转移、连接检查等等。一个Manager能够管理四个master-slave集群

  • MHA Node
    布署在具有运转MySQL的服务器上,无论是master依旧slave。主要职能有四个。
    一.保存2进制日志
    假诺能够访问故障master,会拷贝master的2进制日志
    二.用到差异中继日志
    从具备新型数据的slave上转移差异中继日志,然后选取差别日志。
    3.革除中继日志
    在不停歇SQL线程的事态下删除中继日志

本条是规则,规范化是自动化的重大前提。那年,大家那边标准化是做得相比好的,从OS的准绳到DB层的准绳都具有统一的正儿⑧经。举例OS的操作系统版本、文件系统格式、磁盘挂载点、预装软件、内核参数等等,我们具有MySQL服务器基本都是1模同样的。

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

一、背景

叁.三.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.

binlog

三.3.二.主库创设mha用户
mysql> grant all privileges on *.* to mha@'192.168.217.132' identified by 'mysqlDBA';

咱俩在设计时,在安分守己模块化开荒思虑的还要,根据职分状态,设计出了职分三层调解方式,类似聚积木情势,能够比十分的快地做到不相同要求的平底职责模块,同时可维护性可更高。此外就是复用和平化解耦,模块区别意同级模块相互调用和依赖性,只允许高等模块调用低等模块。

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

binlog

二.壹.MHA办事原理

图片 2

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和半2头复制一齐行使会大大下降数据丢失的险恶。流程如下:

  • 从宕机崩溃的master保存2进制日志事件(binlog events)。
  • 分辨含有最新更新的slave。
  • 利用差别的衔接日志(relay log)到任何slave。
  • 运用从master保存的二进制日志事件(binlog events)。
  • 进级八个slave为新master并记录binlog file和position。
  • 使其它的slave连接新的master进行复制。
  • 完了切换manager主进度OFFLINE

在那中间,除了偶尔故障和特有扶助之外,DBA基本不要求报到服务器去安顿和操作数据。从2016年到现行,大家管理的数据库实例大约翻了三倍,不过DBA人数基本未有转换,近日是四个DBA维护了约一千+的MySQL实例、1500+Redis实例,别的还维护着几多PostgreSQL
/ Oracle / MongoDB / Hbase集群。

三.四.玖.验证并运行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

上边那幅图能够很好的讲明底层的三级模块调用流程:

3.3.部署MySQL复制

/storage/fioa/mysql3307:

三.一.背景介绍

诸如此类安插的数据库到达了条件的水平,所以我们DBA只要精通IP和端口,就能够很轻松地领略那一个实例的保有音信,无疑是自动化的卓绝基础。

3.四.七.创设MHA、BINLOG专门的工作目录
# mkdir -p /data1/mha/masterha/app3389
# mkdir -p /data1/mha/binlog/3389
# chown -R mysql:mysql /data1/mha/binlog/3389

data

2.MHA原理

业务与手艺往往是共同前进的,2016年,小编参预平安好先生,在作业高速发展的同时,大家的数据库自动化平台也获得了长足的建设和升华。

图片 3

mysql-error.log

三.三.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
...... 省略 ......

小编们清楚运转同学时不时无暇多数零星的业务,成效优先,也习贯于脚本化开辟,恐怕分分钟就写2个本子达成某些意义。可是在平台建设中,那种艺术是不可取的。假诺代码未有正儿八经的思辨教导,当几个人共同开拓的进程中,很难张开项目标管理和跟进。

叁.贰.四.开立授权目录
# mkdir -p /data1/db3389
# mkdir -p /data1/tmp
# chown -R mysql:mysql /data1/db3389
# chown -R mysql:mysql /data1/tmp

图片 4

贰.3.当下高可用方案

  • keepalived+mysql复制
    该协会与MHA类似,但keepalived的优势在于无状态组件的故障切换,常用来web前端的故障转移,应用于数据库场景中,最致命的标题就是脑裂以后数据乱写的危机,为集团推动巨大麻烦。

  • MySQL Cluster
    MySQL
    Cluster真正达成了高可用,不过使用的是NDB存储引擎,并且SQL节点有单点故障难点。

  • 半同台复制(五.5+)
    半协同复制大大收缩了“binlog
    events只设有故障master上”的难题。在付出时,保障最少2个slave(并不是兼具的)接收到binlog,因而有个别slave大概未有接收到binlog。

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

一般来讲图所示为大家平台进一步详细的架构图:

3.3.一.主库成立复制用户
mysql> grant replication slave, replication client on *.* to replica@'192.168.217.%' identified by 'mycatDBA';
  • Level
    1为底层扶助模块:
    比方说SSH操作模块、MySQL连接和操作模块、音讯模块(短信,邮件,内部消息)、日志模块、外部接口模块(DNS退换,CDMD同步等)、元数据爱抚模块(meatdata)等。
  • Level
    贰为底蕴单元模块:
    譬如设置MySQL节点、配置宗旨、配置MHA、创立数据库、DB授权等等,那个都以二级模块,基本正是产生某1个特定功用。注意Level
    二里代码除了职业逻辑部分,其他只供给调用Level
    1的模块就可以。比方下边是二个装置MySQL实例的截图,属于二级模块:
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严苛要产生标准化,在未形成自动化陈设在此以前,是相比较辛勤的,困难的不是布置才具,而是规则意识。经常2个商厦都有好五个DBA共同管理数据库,由于事先的行事习于旧贯大家喜爱按部就班自身的法门来布局数据库,大概没有专门的职业配备规则、有规则不过并未有严厉服从,都以心有余而力不足产生标准的。大家是从一方始就做了规范规则和自动化陈设脚本,所以大家近期线上全数数据库的安顿都以规则的,为承接自动化平台建设打下了十二分好的底子。

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

图片 5

三.MHA顶级级奉行

图片 6

图形源于互连网

并且系统将提供Restful API用于内部数据更新,提供HTTP
API用于外部系统接入,举个例子和CMDB、发表平台等日常落成数量共享和天职交接,提供新闻文告功用用于发送各种报警和服务类的布告功效,提供职责上报作用用于各工作模块和WEB层的音信联网。

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

#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

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的脚本触发,无需人手操作。

发表评论

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

网站地图xml地图