MySQL运维第12周书面作业Word文件下载.docx
《MySQL运维第12周书面作业Word文件下载.docx》由会员分享,可在线阅读,更多相关《MySQL运维第12周书面作业Word文件下载.docx(10页珍藏版)》请在冰豆网上搜索。
Db3
1003
服务角色及其描述
描述
172.32.1.211
Writer
应用程序连接该IP对主库进行写请求
172.32.1.212
Reader
应用程序连接到该IP处理读请求
172.32.1.213
应用程序连接到该IP处理处理读请求
具体配置步骤如下:
1.主机准备与配置
准备三个虚拟机,并配置/etc/hosts,在其中添加所有的主机信息:
#cat/etc/hosts
172.32.1.201db1
172.32.1.202db2
172.32.1.203db3
2.MySQL安装和配置
在三台主机上安装MySQL数据库,创建各自的配置文件f,三个服务器的server_id不能一致
3.安装msyql-mmm的Perl模块和软件
在三台服务器上安装MMM所需的Perl模块,可以讲命令封装成脚本进行安装
下载mysql-mmm软件,并在所有机器上安装mysql-mmm软件
#wegethttp:
//mysql-mm.org/_media/:
mmm2:
mysql-mmm-2.2.1.tar.gz
#mv:
mysql-mmm-2.2.1.tar.gzmysql-mmm-2.2.1.tar.gz
#tar–zxvfmysql-mmm-2.2.1.tar.gz
#cdmysql-mmm-2.2.1
#makeinstall
Mysql-mmm软件安装后的主要结构为:
介绍
/usr/lib/perl5/vendor_perl/5.8.8/MMM
MMM使用的主要perl模块
/usr/lib/mysql-mmm
MMM使用的主要脚本
/usr/sbin
MMM使用的主要命令
/etc/init.d/
MMM的agent和monitor启动的服务位置
/etc/mysql-mmm
MMM配置文件的路径,默认所有的配置文件都位于该目录下
/var/log/mysql-mmm
默认MMM保存日志文件的位置
4.配置MMM配置文件
在MMM配置文件中mmm_common.conf,mmm_agent.conf为agent端的配置文件,mmm_mon.conf为monitor端的配置文件。
在db1主机上配置agent配置文件:
#cd/etc/mysql-mmm
#vimmmm_common.conf
在配置文件中按照规划写入各个主机的IP,类型,以及数据库访问用户名和密码
接下来配置db2,db3上的agent文件,可以拷贝db1上的配置文件,然后进行单独修改即可:
Scp/etc/mysql-mmm/mmm_common.confdb2:
/etc/mysql-mmm/
Scp/etc/mysql-mmm/mmm_common.confdb3:
然后配置db1,db2,db3上的mmm_agent文件,三台服务器中this字段跟各自的主机名,如
在db1上:
#vim/etc/mysql-mmm/mmm_agent.conf
Includemmm_common.conf
Thisdb1
在db2,db3上进行类似配置
接下来在db2上配置monitor的配置文件:
#vim/etc/mysql-mmm/mmm_mon.conf
在配置文件中添加整个架构被监控主机的IP地址,在<
hostdefault>
中配置用于监控的用户。
5.创建监控用户
需要在MySQL数据库中创建3个监控用户:
用户名
权限
Monitoruser
MMM的monitor端监控所有的MySQL数据库
Replicationclient
Agentuser
主要是MMM客户端用于改变master的read_only状态用户
Super,replicationclient,process
Replicationuser
用于复制的用户
Replicationslave
6.启动MMM服务并确认状态
启动agent服务
在db1,db2,db3上启动agent,命令如下:
#/etc/init.d/mysql-mmm-agentstart
在db2上启动monitor:
#/etc/init.d/mysql-mmm-monitorstart
服务启动后,可以再/var/log/mysql-mmm/目录中查看启动日志,确认启动是否正常,或者出现什么问题
在monitor主机db2上见集群主机的状态:
#mmm_controlchecksall
如果所有服务状态均为OK,则正常
在monitor主机db2上检查集群环境在线状态:
#mmm_controlshow
如果显示三台master和slave主机则正常
在monitor主机db2上分别online上线所有主机db1,db2和db3:
#mmm_controlset_onlinedb1
#mmm_controlset_onlinedb2
#mmm_controlset_onlinedb3
再次确认集群状态:
至此整个集群配置完成。
三个应用访问的读写IP地址也分别被配置到三台master和slave主机上。
7.MMM高可用环境测试
配置好高可用环境,就可以做MMM的HA测试。
首先检查整个集群状态,确认集群状态正常:
默认停掉db2,观察monitor的日志:
Db2#servicemysqlstop
Db2#tail–f/var/log/msyql-mmm/mmm_mond.log
从日志中可以看出,把db2的状态由online转为admin_offline,把db2的读角色移除掉,把读请求转移到db3的salvedb3.
再次查看集群状态:
db2#mmm_controlshow
重启db2,可以看到db2的HERD_OFFLINE转到AWAITING_RECOvERY角色,但db2并没有再接管读请求:
Db2#servicemsyqlstart
观察日志:
#tail–f/var/log/msyql-mmm/mmm_mond.log
要让db2接管读请求,就必须把db2设置为在线:
观察日志:
查看集群状态:
默认db1主库宕机:
Db1#servicemysqlstop
查看相关MMM日志:
#tail–f/var/log/mysql-mmm/mmm_mond.log
在日志中可以看到db1由以前的online转换为HARD_OFFLINE,已出了写角色,因为db2是备选主,所以接管了相关写角色,db3指向新的主库db2;
即db3实际找到了db2的sql现成应用到的位置,即db2showmaster的返回值,然后直接在db3上changemastertodb2.
从实验结果可以看出:
对于MMM架构db1,db2,db3为一主两从的复制关系,一旦发生db2,db3延时于db1时,这个时刻db1Mysql宕机,db3将会等待数据追上db1后,在重新指向新的主db2,进行changemastertodb2操作,在db1宕机过程中,一旦db2落后于db1,此时发生切换,db2变成了可写状态,数据的一致性就无法保证。
所以说MMM不适合对于数据的一致性要求很高的场景。
MHA的大致测试步骤如下
MHA的整体架构为:
在MHA中使用一主两从的结构,平时读写在master节点上进行,两个salve同步master上的数据;
如果master发生宕机,则latesetslave提升为新的master服务器,其他slave节点连接新的master进行复制。
MHA有MHAManager管理节点和MHANode数据节点组成。
MHAManager可以单独部署在一台服务器上管理多个master-slave集群,也可以部署在一台salve上;
MHANode运行在每台MySQL服务器上,会定时探测集群中的master节点,当master出现故障时,可以自动将最新的salve提升为新的master,然后将其他slave指向新的master,这个过程对应用程序是完全透明的。
MHA的搭建环境如下:
主机
ServerID
类型
Master
172.32.1.111
Ip111
111
写入
CandicateMaster
172.32.1.112
Ip112
112
读
Slave
172.32.1.113
Ip113
113
Monitorhost
172.32.1.120
Ip120
监控集群组
其中Master对外提供写服务,备选master提供读服务,salve也提供相关的读服务,一旦master宕机,将会把备选master提升为新的master,salve指向新的master。
1.安装MHANode(在所有的MySQL服务器上安装)
在MySQL服务器172.32.1.111,172.32.1.112,172.32.1.113服务器上进行下面的操作:
在MySQL服务器上安装MHANode所需的Perl模块(DBD:
mysql)
可以用命令安装,也可以编写脚本安装
在所有的节点上安装mhanode:
使用wget下载软件,解压缩,执行Makefile.PL文件,然后make和makeinstall安装。
2.安装MHAManager
在MHAManager服务器172.32.1.120服务器上进行下面的操作:
在MHAManager主机上,安装MHAManager中包括了几个管理员命令行工具,例如masterha_manager,masterha_master_switch等。
在MHAManager主机上安装MHANode需要的软件包。
安装MHANode软件包
安装MHAManager软件所需要的Perl模块
安装MHAManager软件包
3.配置SSH登陆无密码验证
在Manager和MHANode服务器上执行ssh-keygen–trsa和ssh-copy-id命令机械能无密码验证配置
4.搭建主从复制环境
在master服务器ip111上进行备份
在master服务器ip111上创建复制用户
查看主库上备份时刻的binlog的名称和位置:
master_log_file和master_log_pos
将备份复制到CandicateMaster的ip112上,进行数据库恢复,然后搭建从库,确认复制状态正常;
将备份复制到slaver的ip113上,进行数据库恢复,然后搭建从库,确认复制状态正常;
将salve服务器设置为readonly:
Mysql>
mysql–e“setglobalread_only=1;
”
从库指对外提供读操作
整复制集群已经搭建完毕,还需要创建监控所需的用户,在master的ip111上执行即可:
Msyql>
grantallprivelegeson*.*to‘root’@’172.32.1.*’identifiedby‘123456’;
至此,MHA软件基本安装完毕,下面配置MHA软件。
6.配置MHA
创建MHA工作目录,并创建相关配置文件:
#mkdir–p/etc/masterha/
#vim/etc/masterha/f
设置relaylog清除方式
在两个slave服务器ip112,ip113上执行命令:
msyql–e“setglobalrelay_log_purge=0;
编写pure_relay_logs脚本,并设置定时清理relay_logs的脚本的定时任务
在每个salve节点上,在/etc/bashrc文件添加mysqlbinlog的命令路径
检查ssh的配置
检查MHAManager到所有MHANode的SSH连接状态:
#master_check_ssh–conf=/etc/masterha/app1.conf
如果输出结果中ip120到ip111,ip112,ip113的SSH都是OK状态,则正常。
7.检查MHA复制状态和启停命令
检查整个复制环境的状态
通过master_check_repl脚本查看整个集群的状态:
#mashter_check_repl–conf=/etc/masterha/f
检查MHAManager的状态:
#masterha_check_status–conf=/etc/masterha/f
开启MHAManager监控:
#nohupmasterha_manager–conf=/etc/masterha/f–remove_dead_conf–ignore_failoever<
/dev/mull>
/masterha/app1/manager.log2>
&
1&
再次检查MHAManager的状态:
查看启动过程日志输出信息:
#tail–f/masterha/app1/app1.log
关闭MHAManager监控
#masterha_stop–conf=/etc/masterha/f
8.VIP配置
VIP的配置可以采用两种方式:
通过keepalived的方式管理虚拟IP的佛懂,或者通过脚本方式手动修改IP地址。
9.自动Failover
使用sysbench生成测试数据;
停到salveSQL现成,默认知错能改亚哈斯
默认sysbench压力测试
开启slave的IO线程,追赶落后于master的binlog;
杀掉主库MySQL进程,默认主库故障,进行自动failover操作;
查看MHA切换日志,确认整个切换过程。
网络问题触发的Failover操作
在网络中断的情况下,MHAManager无法连接到主库,候选主也无法连接到主库,此时MHA的切换情况。
10.手动Failover
这个场景意味着在业务上没有启用MHA自动切换功能,当主服务器故障时人工调用MHA来进行故障切换操作;
11.在线进行切换
日常工作下,需要将现有的主服务器迁移到另外一个服务器上。
例如主库需要升级时使用
12.修复宕机的Master
当原来的Master宕掉后,主机修复后,还可以进行Master恢复,先提取日志信息,然后使用changemasterto命令吸怪Master。