MHA 配置文件样本描述

        与绝大多数Linux应用程序类似,MHA的正确使用依赖于合理的配置文件。MHA的配置文件与mysql的my.cnf文件配置相似,采取的是分模块,param=value的方式来配置,配置文件位于管理节点,通常包括每一个mysql server的主机名,mysql用户名,密码,工作目录等等。本文列出了单套MHA以及采用全局配置来管理多套MHA配置文件的一些样例,供大家参考。

 

1、单套MHA配置样本
manager_host$ cat /etc/app1.cnf

[server default]
# 登陆mysql数据库账户及密码,缺省为root,因为需要STOP SLAVE, CHANGE MASTER, RESET SLAVE等。
user=root
password=mysqlpass

# working directory on the manager  #位于管理节点工作目录
manager_workdir=/var/log/masterha/app1

# manager log file #位于管理节点工作日志文件
manager_log=/var/log/masterha/app1/app1.log

# working directory on MySQL servers
# node 上用于产生日志的工作目录,如果不存在,MHA node会自动创建,前提需要有相应的权限,否则node会终止。
# 缺省目录为 "/var/tmp".
remote_workdir=/var/log/masterha/app1

#[serverN] 部分,为各节点配置信息,作用域为各单独节点,各节点书写顺序影响成为新master的顺序
#也可以通过配置candidate_master参数来影响哪个节点具有优先级成为新master
[server1]
hostname=host1

[server2]
hostname=host2

[server3]
hostname=host3

 

2、多套MHA配置样本
如果生产环境中基于单个管理节点部署了多套MHA,可以通过使用全局配置文件来配置相同或共有部分以达到简化配置,易于管理的目的。
假定我们创建了/etc/masterha_default.cnf,则MHA Manager脚本会首先都读取该文件然后再读取指定的配置文件。
这个功能类似于/etc/profile,然后再读取~/.bash_profile
如果在未配置全局的配置文件的情形下,会收到以下提示:
[warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.

a、全局配置文件样本
如:/etc/masterha_default.cnf
[server default]
user=root
password=rootpass
ssh_user=root

#mysql 数据库master节点binlog的位置,该参数用于当master节点死掉后通过ssh方式顺序读取binlog event
#该参数需要配置,因为master节点死掉后无法通过replication机制来自动获取binlog日志位置
#以下为rpm安装方式缺省binlog位置,应根据情形做相应调整
master_binlog_dir= /var/lib/mysql
remote_workdir=/data/log/masterha

#用于检测各节点间的连接性,此处详细可参考MHA parameters描述部分
secondary_check_script= masterha_secondary_check -s remote_host1 -s remote_host2
ping_interval=3

#定义用于实现VIP漂移的脚本,后面的是shutdown以及report脚本
master_ip_failover_script=/script/masterha/master_ip_failover
shutdown_script= /script/masterha/power_manager
report_script= /script/masterha/send_master_failover_mail

b、各MHA单独配置样本
以下为2套不同应用对应的MHA配置文件,如下
app1:
  manager_host$ cat /etc/app1.cnf

  [server default]
  manager_workdir=/var/log/masterha/app1       #工作目录      Author:Leshami
  manager_log=/var/log/masterha/app1/app1.log  #日志文件 Blog   :http://blog.csdn.net/leshami
 
  [server1]
  hostname=host1
  candidate_master=1
 
  [server2]
  hostname=host2
  candidate_master=1
 
  [server3]
  hostname=host3
 
  [server4]
  hostname=host4
  no_master=1

app2:
  manager_host$ cat /etc/app2.cnf

  [server default]
  manager_workdir=/var/log/masterha/app2
  manager_log=/var/log/masterha/app2/app2.log
 
  [server1]
  hostname=host11
  candidate_master=1
 
  [server2]
  hostname=host12
  candidate_master=1
 
  [server3]
  hostname=host13
 
  [server4]
  hostname=host14
  no_master=1

注:对于上述配置,如果各应用配置与全局配置不同,应用配置具有最高优先级,即相同的项,应用配置的值会替换掉全局配置的值

 

3、Binlog server
该功能自被MHA 0.56版支持。即可以定义[binlogN]选项。在这个部分,可以定义mysqlbinlog streaming servers.
如果开启了GTID,则MHA会检查binlog服务器,且binlog服务器日志在其他从节点日志之前,则MHA会在恢复之前从binlog服务器apply差量日志
如果未开启GTID,则MHA 忽略 binlog servers。如下样本:

manager_host$ cat /etc/app1.cnf
 
  [server default]
  # mysql user and password
  user=root
  password=mysqlpass
 
  # working directory on the manager
  manager_workdir=/var/log/masterha/app1
 
  # manager log file
  manager_log=/var/log/masterha/app1/app1.log
  # working directory on MySQL servers
  remote_workdir=/var/log/masterha/app1
 
  [server1]
  hostname=host1
 
  [server2]
  hostname=host2
 
  [server3]
  hostname=host3

  [binlog1]
  hostname=binlog_host1

  [binlog2]
  hostname=binlog_host2
 
参考:Writing an application configuration file

时间: 2024-09-15 02:26:53

MHA 配置文件样本描述的相关文章

MHA 切换的2个异常(masterha_master_switch line 53)

        MHA 在测试手动故障转移和在线切换的过程中,碰到了2个比较诡异的问题,在使用IP地址调用的时候均无法测试成功,出现了Detected dead master xxx does not match with specified dead master以及xxx is not alive.下面是这2个错误问题的描述及解决方案.   1.MHA配置文件[root@vdbsrv4 ~]# more /etc/masterha/app1.cnf [server default]manag

用定制标签库和配置文件实现对JSP页面元素的访问控制

js|访问|控制|页面        控制客户端访问是开发一个基于B/S的架构的系统的开发者必须考虑的问题.JSP或SERVLET规范的基于配置文件的安全策略对资源的控制是以文件为单位的,即只可以定义某个视图全部可以或全部不能被访问.一个比较复杂的系统往往要要求对视图的一部分(如JSP页面里的一个按钮)提供访问控制,只允许被某种角色的用户访问.如果采用可编程的安全策略,因为对用户角色和操作的定义在开发时不能定义,而且这种策略加大了程序员的工作量,它可能不是一种好的办法.        我采用定制

MySQL MHA配置常见问题

    MHA在MySQL数据库中被广泛使用,它小巧易用,功能强大,实现了基于MySQL replication架构的自手动主从故障转移,从库重定向到主库并自动同步.尽管如此,在部署配置的过程中,由于疏忽总难以避免这样或那样的错误.本文是对MHA配置中常见问题的一个汇总,供大家参考.   1.非root用户等效性环境等效性配置  a.添加所有节点(含管理节点)主机名及IP到host文件,所有节点操作  b.生成基于非root用户(如使用mysql账户)的对称密钥,使用ssh-keygen  c.

MHA实施

1.关于MHA MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:MHA Manager

如何为代码编写基本的文档

事先声明一下,这篇文章是为完全没有任何文档编写经验,并且正在使用Visual Studio的同学们准备的,不一定适用于老鸟以及其他IDE爱好者 :-) Ok, alpha版本的一个严重的问题便是,我们没有任何的文档积累;所以在Beta版本的开发中,PM准备彻底消灭这种无文档的编码风格. 既然要让大家写文档,那么总该有个文档规范吧!理论性的东西我就不多讲了,这里我就讲一个"南七规范"--简单实用,不用费脑子. 南七规范 v1.0 不知道提到"文档",同学们首先会想到什

调度器之单体调度器

本文讲的是调度器之单体调度器,[编者的话]本文描述了几个简单的单体调度器,基本的配置以及如何在Deis切换调度后端. 调度是一种向处理资源分配工作载荷的方式.在分布式环境中,调度器格外为大家需要,尤其是那些提供扩展性,资源意识以及高效能特性的调度器. 单体调度器是单个进程实体,进行调度决策并完成需要被调度的任务的部署.这些任务可以是长期运行的服务器程序,短期存在的批处理命令,MapReduce查询等等. 为了调度任务的决策,单体调度器需要:观察集群中资源的可用性(例如CPU.内存等),锁住资源,

JBuilder2005 Struts深度体验之新增

新增一个Struts配置文件 考虑到图书模块是一个比较独立的模块,为了避免对Struts配置文件的资源争用导致团队工程的覆盖或冲突,我们为这个模块单独提供一个新的Struts配置文件,用这个配置文件配置图书模块所有Struts关联的信息. 我们按照如下的方式为webModule模块添加一个名为book-struts-config.xml的配置文件. 首先到<工程目录>/webModule/WEB-INF拷贝一个原有的struts-config.xml文件,更名为book-struts-conf

Structs深入研究(一)-----Struts framework的工作原理和组件

Struts framework的工作原理和组件 对于Struts 如何控制.处理客户请求,让我们通过对struts的四个核心组件介绍来具体说明.这几个组件就是:ActionServlet.Action Classes,Action Mapping(此处包括ActionForward),ActionFrom Bean. Struts ActionServlet控制器对象        ActionServlet继承自javax.servlet.http.HttpServlet类,其在Struts

PHP基础

    PHP 的基本功能就是解释一个脚本,来生成发送到客户机的Web 页面.具有代表性的是,脚本包括逐字发送到客户机的HTML 和作为程序执行的PHP 代码的混合编码.无论代码生成什么样的输出,都会发送到客户机,因此客户机永远不会看到代码,它只能看结果的输出.    当PHP 开始读取文件时,假设文件内容表示文字的H T M L,则它仅仅拷贝在那里找到的输出内容.当PHP 解释程序遇到一个特殊的打开标记时,就从HTML 模式切换到PHP 代码模式,而作为要执行的PHP 代码也开始解释文件.代码