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

1、Db31003服务角色及其描述描述172.32.1.211Writer应用程序连接该IP对主库进行写请求172.32.1.212Reader应用程序连接到该IP处理读请求172.32.1.213应用程序连接到该IP处理处理读请求具体配置步骤如下：1. 主机准备与配置准备三个虚拟机，并配置 /etc/hosts ，在其中添加所有的主机信息：# cat /etc/hosts172.32.1.201 db1172.32.1.202 db2172.32.1.203 db32. MySQL安装和配置在三台主机上安装MySQL数据库，创建各自的配置文件f，三个服务器的server_id不能一致3. 安装m

2、syql-mmm的Perl模块和软件在三台服务器上安装MMM所需的Perl模块，可以讲命令封装成脚本进行安装下载mysql-mmm软件，并在所有机器上安装mysql-mmm软件# weget http:/mysql-mm.org/_media/:mmm2:mysql-mmm-2.2.1.tar.gz# mv :mysql-mmm-2.2.1.tar.gz mysql-mmm-2.2.1.tar.gz# tar zxvf mysql-mmm-2.2.1.tar.gz# cd mysql-mmm-2.2.1# make installMysql-mmm软件安装后的主要结构为：介绍/usr/lib/

3、perl5/vendor_perl/5.8.8/MMMMMM使用的主要perl模块/usr/lib/mysql-mmmMMM使用的主要脚本/usr/sbinMMM使用的主要命令/etc/init.d/MMM的agent和monitor启动的服务位置/etc/mysql-mmmMMM配置文件的路径，默认所有的配置文件都位于该目录下/var/log/mysql-mmm默认MMM保存日志文件的位置4. 配置MMM配置文件在MMM配置文件中 mmm_common.conf,mmm_agent.conf为agent端的配置文件，mmm_mon.conf为monitor端的配置文件。在db1 主机上配置a

4、gent配置文件：# cd /etc/mysql-mmm# vim mmm_common.conf在配置文件中按照规划写入各个主机的IP，类型，以及数据库访问用户名和密码接下来配置db2,db3上的agent文件，可以拷贝db1上的配置文件，然后进行单独修改即可：Scp /etc/mysql-mmm/mmm_common.conf db2:/etc/mysql-mmm/Scp /etc/mysql-mmm/mmm_common.conf db3:然后配置db1,db2,db3上的mmm_agent文件，三台服务器中this 字段跟各自的主机名，如在db1上：# vim /etc/mysql-m

5、mm/mmm_agent.confInclude mmm_common.confThis db1在db2,db3上进行类似配置接下来在db2上配置monitor的配置文件：# vim /etc/mysql-mmm/mmm_mon.conf在配置文件中添加整个架构被监控主机的IP地址，在中配置用于监控的用户。5. 创建监控用户需要在MySQL数据库中创建3个监控用户：用户名权限Monitor userMMM的monitor端监控所有的MySQL数据库Replication clientAgent user主要是MMM客户端用于改变master 的read_only状态用户Super,replic

6、ation client,processReplication user用于复制的用户Replication slave6. 启动MMM服务并确认状态启动agent服务在db1,db2,db3上启动agent，命令如下：# /etc/init.d/mysql-mmm-agent start在db2上启动monitor：# /etc/init.d/mysql-mmm-monitor start服务启动后，可以再/var/log/mysql-mmm/目录中查看启动日志，确认启动是否正常，或者出现什么问题在monitor主机db2上见集群主机的状态：# mmm_control checks all如

7、果所有服务状态均为OK，则正常在monitor主机db2上检查集群环境在线状态：# mmm_control show如果显示三台master和slave主机则正常在monitor主机db2上分别online上线所有主机db1,db2和db3：# mmm_control set_online db1# mmm_control set_online db2# mmm_control set_online db3再次确认集群状态：至此整个集群配置完成。三个应用访问的读写IP地址也分别被配置到三台master和slave主机上。7. MMM高可用环境测试配置好高可用环境，就可以做MMM的HA测试。首先

8、检查整个集群状态，确认集群状态正常：默认停掉db2,观察monitor的日志:Db2# service mysql stopDb2# tail f /var/log/msyql-mmm/mmm_mond.log从日志中可以看出，把db2的状态由online转为admin_offline，把db2的读角色移除掉，把读请求转移到db3的salve db3.再次查看集群状态：db2# mmm_control show 重启db2，可以看到db2的HERD_OFFLINE转到AWAITING_RECOvERY角色，但db2并没有再接管读请求：Db2# service msyql start观察日志：#

9、 tail f /var/log/msyql-mmm/mmm_mond.log要让db2接管读请求，就必须把db2设置为在线：观察日志:查看集群状态：默认db1主库宕机：Db1# service mysql stop查看相关MMM日志：# tail f /var/log/mysql-mmm/mmm_mond.log在日志中可以看到db1由以前的online转换为HARD_OFFLINE，已出了写角色，因为db2是备选主，所以接管了相关写角色，db3指向新的主库db2；即db3实际找到了db2的sql现成应用到的位置，即db2 show master 的返回值，然后直接在db3上change m

10、aster to db2.从实验结果可以看出：对于MMM架构db1,db2,db3为一主两从的复制关系，一旦发生db2,db3延时于db1时，这个时刻db1 Mysql宕机，db3将会等待数据追上db1后，在重新指向新的主db2，进行change master to db2操作，在db1宕机过程中，一旦db2落后于db1，此时发生切换,db2变成了可写状态，数据的一致性就无法保证。所以说MMM不适合对于数据的一致性要求很高的场景。MHA的大致测试步骤如下MHA的整体架构为：在MHA中使用一主两从的结构，平时读写在master节点上进行，两个salve同步master上的数据；如果master发

11、生宕机，则lateset slave提升为新的master服务器，其他slave节点连接新的master进行复制。MHA有MHA Manager管理节点和MHA Node数据节点组成。MHA Manager可以单独部署在一台服务器上管理多个master-slave集群，也可以部署在一台salve上；MHA Node运行在每台MySQL服务器上，会定时探测集群中的master节点，当master出现故障时，可以自动将最新的salve提升为新的master，然后将其他slave指向新的master，这个过程对应用程序是完全透明的。MHA的搭建环境如下：主机Server ID类型Master172.

12、32.1.111Ip111111写入Candicate Master172.32.1.112Ip112112读Slave172.32.1.113Ip113113Monitor host172.32.1.120Ip120监控集群组其中Master对外提供写服务，备选master提供读服务，salve也提供相关的读服务，一旦master宕机，将会把备选master提升为新的master，salve指向新的master。1. 安装MHA Node（在所有的MySQL服务器上安装）在MySQL服务器 172.32.1.111,172.32.1.112,172.32.1.113服务器上进行下面的操作：在

13、MySQL服务器上安装MHA Node所需的Perl模块（DBD：mysql）可以用命令安装，也可以编写脚本安装在所有的节点上安装mha node:使用wget下载软件，解压缩，执行Makefile.PL文件，然后make和make install安装。2. 安装MHA Manager在MHA Manager服务器 172.32.1.120 服务器上进行下面的操作：在MHA Manager主机上，安装MHA Manager中包括了几个管理员命令行工具，例如masterha_manager,masterha_master_switch等。在MHA Manager主机上安装MHA Node需要的软

14、件包。安装MHA Node软件包安装MHA Manager 软件所需要的Perl模块安装MHA Manager软件包3. 配置SSH登陆无密码验证在Manager和MHA Node 服务器上执行ssh-keygen t rsa 和 ssh-copy-id 命令机械能无密码验证配置4. 搭建主从复制环境在master服务器 ip111上进行备份在master 服务器 ip111上创建复制用户查看主库上备份时刻的binlog的名称和位置：master_log_file 和 master_log_pos将备份复制到Candicate Master的 ip112上，进行数据库恢复，然后搭建从库，确认复

15、制状态正常；将备份复制到slaver的 ip113上，进行数据库恢复，然后搭建从库，确认复制状态正常；将salve服务器设置为read only：Mysql mysql e “set global read_only=1;”从库指对外提供读操作整复制集群已经搭建完毕，还需要创建监控所需的用户，在master的ip111上执行即可：Msyql grant all priveleges on *.* to root172.32.1.* identified by 123456;至此，MHA软件基本安装完毕，下面配置MHA软件。6. 配置MHA创建MHA工作目录，并创建相关配置文件：# mkdir

16、p /etc/masterha/# vim /etc/masterha/f设置relay log清除方式在两个slave服务器 ip112 ,ip113上执行命令： msyql e “set global relay_log_purge=0;编写pure_relay_logs脚本，并设置定时清理relay_logs的脚本的定时任务在每个salve节点上，在/etc/bashrc文件添加mysqlbinlog的命令路径检查ssh的配置检查MHA Manager到所有MHA Node的SSH连接状态：# master_check_ssh conf=/etc/masterha/app1.conf如果

17、输出结果中ip120到ip111,ip112,ip113的SSH 都是OK状态，则正常。7. 检查MHA复制状态和启停命令检查整个复制环境的状态通过master_check_repl脚本查看整个集群的状态：# mashter_check_repl conf=/etc/masterha/f检查MHA Manager的状态：# masterha_check_status conf=/etc/masterha/f开启MHA Manager监控：# nohup masterha_manager conf=/etc/masterha/f remove_dead_conf ignore_failoever

18、 /masterha/app1/manager.log 2&1 &再次检查MHA Manager的状态：查看启动过程日志输出信息：# tail f /masterha/app1/app1.log关闭MHA Manager监控# masterha_stop conf=/etc/masterha/f8. VIP 配置VIP的配置可以采用两种方式：通过keepalived 的方式管理虚拟IP的佛懂，或者通过脚本方式手动修改IP地址。9. 自动Failover使用sysbench生成测试数据；停到salve SQL现成，默认知错能改亚哈斯默认sysbench压力测试开启slave的IO线程，追赶落后于

19、master的binlog；杀掉主库MySQL进程，默认主库故障，进行自动failover操作；查看MHA切换日志，确认整个切换过程。网络问题触发的Failover操作在网络中断的情况下，MHA Manager无法连接到主库，候选主也无法连接到主库，此时MHA的切换情况。10. 手动Failover这个场景意味着在业务上没有启用MHA自动切换功能，当主服务器故障时人工调用MHA来进行故障切换操作；11. 在线进行切换日常工作下，需要将现有的主服务器迁移到另外一个服务器上。例如主库需要升级时使用12. 修复宕机的Master当原来的Master宕掉后，主机修复后，还可以进行Master恢复，先提取日志信息，然后使用change master to命令吸怪Master。