MySQL运维第12周书面作业Word文件下载.docx

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。