MHA实现mariadb的高可用的详细步骤及配置参数详解

MHA实现mariadb的高可用的详细步骤及配置参数详解

 

A. 实验环境说明

 

a) 4台centos7主机

 

b) 角色说明:

    a、  MHA:192.168.36.35
    b、  Master_mariadb:192.168.36.121
    c、  Slave_mariadb:192.168.36.120
    d、  Slave_mariadb:192.168.36.27

 

B. 安装程序包

 

a) mariadb上安装:

    mariadb-server   版本:5.5.60
    mha4mysql-node -0.56-0.el6.noarch.rpm

 

b) MHA上安装:

    mha4mysql-manager -0.56-0.el6.noarch.rpm
    mha4mysql-node -0.56-0.el6.noarch.rpm

 

C. 配置数据库主从同步功能

 

a) Master节点

    [mysqld]
    server_id=121
    binlog_format=row
    log_bin
    innodb_file_per_table
    skip_name_resolve   #禁止反向解析

 

b) Slave节点

    [mysqld]
    server_id=120  #必须唯一
    read_only
    log_bin  #要想提升为主节点,必须开启二进制日志功能
    binlog_format=row
    relay_log_purge=0  #关闭中继日志
    skip_name_resolve
    innodb_file_per_table

 

c) Master节点创建复制和MHA管理帐户:

        grant replication slave on *.* to repluser@'192.168.8.%' identified by ‘centos';
        grant all on *.* to mhauser@'192.168.8.%’identified by‘centos';

 

d) 启动主从同步功能并测试是否成功

    CHANGE MASTER TO 
        MASTER_HOST='192.168.36.121',
        MASTER_USER='repluser', 
        MASTER_PASSWORD='centos',
        MASTER_LOG_FILE='mariadb-bin.000001',       #根据show master logs的结果填写
        MASTER_LOG_POS=245;    #根据show master logs的结果填写

 

D. MHA上配置KEY验证功能

 

a) 创建key:

    ssh-keygen

 

b) 先给自己分发key:

    ssh-copy-id 192.168.36.35

 

c) 把.ssh目录复制到各被管理节点,实现各主机之间免密码管理

    scp -rp .ssh 192.168.36.121:/root/
    scp -rp .ssh 192.168.36.120:/root/
    scp -rp .ssh 192.168.36.27:/root/

 

E. MHA上建立配置文件

    vim /etc/mha/app1.conf  #路径和文件名无要求
    [server default]
    user=mhauser  #同授权的用户
    password=centos  #同授权的密码
    #ssh_port=9527  根据需要设置,默认22
    manager_workdir=/data/mastermha/app1/
    manager_log=/data/mastermha/app1/manager.log
    remote_workdir=/data/mastermha/app1/
    ssh_user=root
    repl_user=repluser  #同授权的复制用户
    repl_password=centos  #同授权的复制密码
    ping_interval=1  #MHA与被管理节点的心跳间隔时间,单位秒
    [server1]
    hostname=192.168.36.121
    candidate_master=1  #是否可提升为主节点
    [server2]
    hostname=192.168.36.120
    candidate_master=1
    [server3]
    hostname=192.168.36.27
    candidate_master=1

 

F. MHA验证和启动

    a)  masterha_check_ssh --conf=/etc/mastermha/app1.cnf  #检查SSH通讯
    b)  masterha_check_repl --conf=/etc/mastermha/app1.cnf  #检查主从复制
    c)  masterha_manager --conf=/etc/mastermha/app1.cnf  #检查管理功能且只能提升一次

 

G. 排错日志:

    /data/mastermha/app1/manager.log

 

H. MHA配置参数详解:

    hostname:目标实例的主机名或者IP地址,这个参数是强制的,只能配置在app配置文件的[server_xxx]段落标记下
    ip:目标实例的ip地址,默认从hostname获取,MHA内部管理节点与数据节点之间的mysql和ssh通过这个IP连接,正常情况下你不需要配置这个参数,因为MHA会自动解析Hostname获得
    port:目标实例的端口,默认是3306,MHA使用mysql server的IP和port连接
    ssh_host:从0.53版本开始支持,默认情况下和hostname参数相同,当你使用了VLAN隔离的时候,比如为了安全,把ssh网段和访问数据库实例的网段分开使用两个不同的IP,那么就需要单独配置这个参数
    ssh_ip:从0.53版本开始支持,默认情况下与ssh_host相同
    ssh_port:从0.53版本开始支持,目标数据库的ssh端口,默认是22
    ssh_connection_timeout:从0.54版本开始支持,默认是5秒,增加这个参数之前这个超时时间是写死在代码里的
    ssh_options:从0.53版本开始支持,额外的ssh命令行选项
    candidate_master:从不同的从库服务器中,提升一个可靠的机器为新主库,(比如:RAID 10比RAID0的从库更可靠),可以通过在配置文件中对应的从库服务器的配置段下添加candidate_master=1来提升这个从库被提升为新主库的优先级(这个从库要开始binlog,以及没有显著的复制延迟,如果不满足这两个条件,也并不会在主库挂掉的时候成为新主库,所以,这个参数只是提升了优先级,并不是说指定了这个参数就一定会成为新主库)
    no_master:通过在目标服务器的配置段落设置no_master=1,它永远也不会变为新主库,用于配置在不想用于接管主库故障的从库上,如:只是一个binlog server,或者硬件配置比较差的从库上,或者这个从库只是一个远程灾备的从库,但是,要注意,不能把所有的从库都配置这个参数,这样MHA检测到没有可用备主的时候,会中断故障转移操作
    ignore_fail:默认情况下,MHA在做故障转移的时候,会去检测所有的server,如果发现有任何的从库有问题(比如不能通过SSH检测主机或者mysql的存活,或者说有SQL线程复制错误等)就不会进行故障转移操作,但是,有时候可能需要在特定从库有故障的情况下,仍然继续进行故障转移,就可以使用这个参数指定它。默认是0,需要设置时在对应服务器的配置段下添加ignore_fail=1
    skip_init_ssh_check:监控程序启动的时候,跳过SSH连接检测
    skip_reset_slave:0.56开始支持,master故障转移之后,跳过执行reset slave all语句
    user:目标mysql实例的管理帐号,尽量是root用户,因为运行所有的管理命令(如:stop slave,change master,reset slave)需要使用,默认是root
    password:user参数指定的用户的密码,默认为空
    repl_user:在所有slave上执行change master的复制用户名,这个用户最好是在主库上拥有replication slave权限
    repl_password:repl_user参数指定的用户的密码,默认情况下,是当前复制帐号的密码,如果你运行了online master switch脚本且使用了–orig_master_is_new_slave做在线切换,当前主库作为了从库加入新主库,此时,如果你没有设置repl_password来指定复制帐号的密码,当前主库作为从库加入新主库的时候会在change master的时候失败,因为默认情况下这个密码是空的,MHA做切换的时候,其他所有作为从库加入新主库时,都需要使用这个密码
    disable_log_bin:如果设置这个参数,当应用差异日志到从库时,slave不生成binlog写入,内部通过mysqlbinlog命令的–disable-log-bin选项实现
    master_pid_file:设置master的pid,在运行多实例的环境下,你可能需要用到这个参数来指定master的pid,参考shutdown_script参数详解
    ssh_user:访问MHA manger和MHA mysql节点的OS系统帐号,需要使用它来远程执行各种各样的管理mysql节点的命令(从manager到mysql),从latest slave拷贝差异日志到其他从库上(从mysql到mysql),该用户必须要能够没有任何交互地连接到服务器,通常使用ssh key认证,默认情况下,这个用户是manager所在的OS系统用户。
    remote_workdir:每一个MHA node(指的是mysql server节点)生成日志文件的工作路径,这个路径是绝对路径,如果该路径目录不存在,则会自动创建,如果没有权限访问这个路径,那么MHA将终止后续过程,另外,你需要关心一下这个路径下的文件系统是否有足够的磁盘空间,默认值是/var/tmp
    master_binlog_dir:在master上生成binlog的绝对路径,这个参数用在master挂了,但是ssh还可达的时候,从主库的这个路径下读取和复制必须的binlog events,这个参数是必须的,因为master的mysqld挂掉之后,没有办法自动识别master的binlog存放目录。默认情况下,master_binlog_dir的值是/var/lib/mysql,/var/log/mysql,/var/lib/mysql目录是大多数mysql分支默认的binlog输出目录,而 /var/log/mysql是ubuntu包的默认binlog输出目录,这个参数可以设置多个值,用逗号隔开
    log_level:manager记录日志的等级,默认以及大多数场景下都是info级别,可以设置的值为debug/info/warning/error
    manager_workdir:mha manager生成的相关状态文件的绝对路径,如果没有设置,则默认使用/var/tmp
    client_bindir: 如果mysql命令工具是安装在非标准路径下,那么使用这个参数指定绝对路径
    client_libdir:如果mysql的库文件是安装在非标准路径下,那么使用这个参数指定据对路径
    manager_log:mha manager生成的日志据对路径,如果没有设置,mha manager将打印在标准输出,标准错误输出上,如:当mha manager执行故障转移的时候,这些信息就会打印
    check_repl_delay:默认情况下,如果从库落后主库100M的relay logs,MHA不会选择这个从库作为新主库,因为它会增加恢复的时间,设置这个参数为0,MHA在选择新主库的时候,则忽略复制延迟,这个选项用在你使用candidate_master=1 明确指定需要哪个从库作为新主库的时候使用。
    check_repl_filter:默认情况下,如果master和slave相互之间有任何不同的binlog复制过滤规则,MHA将打印错误日志并拒绝启动监控程序或者拒绝故障转移操作,这是为了避免意外出现类似Table not exists这样的错误,如果你100%确定不同的复制过滤规则不会出现恢复问题,那么就设置check_repl_filter = 0,此时MHA在应用差异日志的时候就不会去检测复制过滤规则,但是你可能会碰到Table not exists这样的错误,使用这个参数要非常小心
    latest_priority:默认情况下,latest slave(收到最新的binlog的slave),优先作为新主库,如果你想控制这个优先级顺序,可以通过 latest_priority=0,此时,就会按照配置文件中配置的顺序来选择新主库(如 host2->host3->host4)。
    multi_tier_slave:从0.52版本开始,支持多个主库的复制架构,默认情况下,在配置文件中不支持三个或更多层级的复制架构,例如:host2从host1复制,host3从host2复制,默认情况下,是不允许host1,2,3同时可写的。因为这个是一个三层复制,MHA manager会报错并停止,设置这个参数之后,MHA manager不会中断三层复制架构的监控,只是忽略了第三层,即host3,如果host1挂了,host2将接管host1,被选择为新主库,host3继续从host3复制。
    ping_interval:这个参数表示mha manager多久ping(执行select ping sql语句)一次master,连续三个丢失ping连接,mha master就判定mater死了,因此,通过4次ping间隔的最大时间的机制来发现故障,默认是3,表示间隔是3秒
    ping_type:从0.53版本开始支持,默认情况下,mha master基于一个到master的已经存在的连接执行select 1(ping_type=select)语句来检查master的可用性,但是在有些场景下,最好是每次通过新建/断开连接的方式来检测,因为这能够更严格以及更快速地发现TCP连接级别的故障,把ping_type设置为connect就可以实现。从0.56开始新增了ping_type=INSERT类型。
    secondary_check_script:通常,推荐通过两个或者更多的网络路径来检测master的可用性,默认情况下,MHA只是通过单个网络路径来检测,即从mha master到master的路线,但是不推荐这么做,mha可以通过secondary_check_script 参数来调用一个外部的脚本来实现两个或更多个网络路径来检测master的可用性 
    master_ip_failover_script:通常在MHA环境下,通常需要分配一个VIP供master用于对外提供读写服务,如果master挂了,HA软件指引备用服务器接管VIP,另外一个通用的方法,是在数据库中创建一个全局的应用程序名称与读写IP地址之间的全局类目映射( {app1_master1, 192.168.0.1}, {app_master2, 192.168.0.2}, …)来代替VIP地址的使用,在这种情况下,如果你的master挂了,你需要更新这个数据库中的全局类目映射。第二种方法这里个人觉得跟智能DNS解析类似。 
    master_ip_online_change_script:这是一个与master_ip_failover_script 参数很接近的参数,但是这个参数不使用故障转移命令,而是master的在线change命令(masterha_master_switch –master_state=alive)
    shutdown_script:你可能想要强制关闭master节点来避免master节点重新启动服务,这对于避免脑裂来说是很重要的
    report_script:在故障转移完成或者说因为错误而终止的时候,你可能希望发送一个报告出来,这就是使用report_script 参数的目的
    init_conf_load_script:这个脚本在你不想在配置文件中设置纯文本的信息的时候使用(比如:password和repl_password),从这个脚本返回name=value的键值对,它可以作为全局配置文件参数,示例脚本内容如下:
             #!/usr/bin/perl
            print "password=$ROOT_PASS\n";
            print "repl_password=$REPL_PASS\n";
                    这个参数默认为空,所以mha manager不会调用这个参数做任何事情
上一篇:mha高可用 数据库


下一篇:Mysql实现高可用架构之MHA