MySQL运维第12周书面作业.docx

MySQL运维第12周书面作业.docx

《MySQL运维第12周书面作业.docx》由会员分享，可在线阅读，更多相关《MySQL运维第12周书面作业.docx（10页珍藏版）》请在冰豆网上搜索。

MySQL运维第12周书面作业

作业3：

测试一下MHA/MMM，总结设计中的不足和改进的点

MHA和MMM的整体总结

经过对MMM和MHA的环境测试，感觉MMM架构在控制管理上相对优越，只需要启动服务和online操作即可，但由于双主结构，当一个主宕机时，两一个主可以读写，中间数据没有完全同步，就会发生数据一致性问题；目前我所在的公司，使用MySQL做联机交易系统，对数据一致性要求非常高，所以不能使用MMM架构；

对于MHA，由于一主多从，只有一个读其他均为写，所以解决了数据一致性问题，但主从的切换都存在着一定的问题，因为HA的切换有多种情况，且没有情况的设置都有不同，也各有优缺点，所以在控制管理上稍微复杂一些，但对于OLTP业务老说，数据一致性应该具有更高的优先级，且相比而言MHA是更加成熟的一种架构，可以考虑将公司的单mysql-slave迁移为MHA架构。

对于MMM的大致测试步骤：

MMM的部署架构图为

配置角色的信息：

角色

IP地址

主机名称

Serverid

Monitoringhost

172.32.1.202

Db2

部署在db2上

Master1

172.32.1.201

Db1

1001

Master2

172.32.1.202

Db2

1002

Slave1

172.32.1.203

Db3

1003

服务角色及其描述

IP地址

角色

描述

172.32.1.211

Writer

应用程序连接该IP对主库进行写请求

172.32.1.212

Reader

应用程序连接到该IP处理读请求

172.32.1.213

Reader

应用程序连接到该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:

mmm2:

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:

/etc/mysql-mmm/

然后配置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地址，在中配置用于监控的用户。

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

再次确认集群状态：

#mmm_controlshow

至此整个集群配置完成。

三个应用访问的读写IP地址也分别被配置到三台master和slave主机上。

7.MMM高可用环境测试

配置好高可用环境，就可以做MMM的HA测试。

首先检查整个集群状态，确认集群状态正常：

#mmm_controlshow

默认停掉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设置为在线：

#mmm_controlset_onlinedb2

观察日志:

#tail–f/var/log/msyql-mmm/mmm_mond.log

查看集群状态：

#mmm_controlshow

默认db1主库宕机：

Db1#servicemysqlstop

查看集群状态：

#mmm_controlshow

查看相关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的搭建环境如下：

角色

IP地址

主机

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;”

从库指对外提供读操作

5.创建监控用户

整复制集群已经搭建完毕，还需要创建监控所需的用户，在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上执行命令：

Mysql>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/masterha/app1/manager.log2>&1&

再次检查MHAManager的状态：

#masterha_check_status–conf=/etc/masterha/f

查看启动过程日志输出信息：

#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。