sandbox和MHA快速测试(r12笔记第32天)

昨天写了一篇使用脚本搭建一主多从的脚本之后，奇龙兄建议我看看sandbox的功能，可以秒级搭建主从环境，简单试了下，确实很好很强大。

   环境部署其实很简单，如果有网络环境，直接cpan一个命令即可。或者使用wget的方式来安装也可以。

安装sandbox

使用cpan来安装，非常简单，就是下面的命令：

cpan MySQL::Sandbox

一些日志的输出之后就提示你安装成功，在/usr/local/bin下面就会多几个make_sandbox相关的命令。

[root@grtest bin]# ll make*
-r-xr-xr-x 1 root root  8681 Apr 12 16:16 make_multiple_custom_sandbox
-r-xr-xr-x 1 root root 13862 Apr 12 16:16 make_multiple_sandbox
-r-xr-xr-x 1 root root 22260 Apr 12 16:16 make_replication_sandbox
-r-xr-xr-x 1 root root 11454 Apr 12 16:16 make_sandbox
-r-xr-xr-x 1 root root  4970 Apr 12 16:16 make_sandbox_from_installed
-r-xr-xr-x 1 root root  7643 Apr 12 16:16 make_sandbox_from_source
-r-xr-xr-x 1 root root  5772 Apr 12 16:16 make_sandbox_from_url

另外一种方式是通过安装包的方式，可以通过编译安装完成。

可以使用wget下载安装包：

# wget https://launchpad.net/mysql-sandbox/mysql-sandbox-3/mysql-sandbox-3/+download/MySQL-Sandbox-3.0.25.tar.gz然后使用make,make install的方式即可安装。

比如我要部署一个MySQL数据库环境，我们给定一个二进制安装包，直接make_sandbox即可。

# make_sandbox mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz这个命令有一点需要说明，就是考虑到安全，默认使用root是敏感的,会抛出下面的警告。主要就是向你确认是否确实要这儿做，如果是一个线上环境，操作的风险很高，所以就特别提示，需要你设定一个变量值，确认之后才可以。

# make_sandbox percona-server-5.6.25-73.1.tar.gz
MySQL Sandbox should not run as root

If you know what you are doing and want to
 run as root nonetheless, please set the environment
variable 'SANDBOX_AS_ROOT' to a nonzero value我们就给这个变量给一个值，比如go

export SANDBOX_AS_ROOT=go一套数据库环境就自动部署出来了，难得的是会自动生成对应的快捷脚本，如果下个做一些批量管理类的任务，就非常快捷方便，这里的数据库安装目录是msb_5_7_17,数据文件都在这个目录下面。

[root@grtest sandboxes]# ll
total 48
-rwxr-xr-x 1 root root   54 Apr 12 16:35 clear_all
drwxr-xr-x 4 root root 4096 Apr 12 16:35 msb_5_7_17
-rw-r--r-- 1 root root 3621 Apr 12 16:35 plugin.conf
-rwxr-xr-x 1 root root   56 Apr 12 16:35 restart_all
-rwxr-xr-x 1 root root 2145 Apr 12 16:35 sandbox_action
-rwxr-xr-x 1 root root   58 Apr 12 16:35 send_kill_all
-rwxr-xr-x 1 root root   54 Apr 12 16:35 start_all
-rwxr-xr-x 1 root root   55 Apr 12 16:35 status_all
-rwxr-xr-x 1 root root   53 Apr 12 16:35 stop_all
-rwxr-xr-x 1 root root 4514 Apr 12 16:35 test_replication
-rwxr-xr-x 1 root root   52 Apr 12 16:35 use_all连接数据库，只需要一个use命令即可。

 ./use
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.17 MySQL Community Server (GPL)
Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql [localhost] {msandbox} ((none)) >其它的启停命令也是如此,非常快捷方便。

而要搭建主从环境，操作步骤简单,输出日志也很简单,比如我指定一个已经解压的二进制目录5.7.17,就会默认创建一主两从的环境。

# export SANDBOX_AS_ROOT=go
# make_replication_sandbox 5.7.17
installing and starting master
installing slave 1
installing slave 2
starting slave 1
.. sandbox server started
starting slave 2
. sandbox server started
initializing slave 1
initializing slave 2
replication directory installed in $HOME/sandboxes/rsandbox_5_7_17查看主从的状态，使用status_all即可。

# ./status_all
REPLICATION rsandbox_5_7_17
master on
port: 20192
node1 on
port: 20193
node2 on
port: 20194

MHA快速测试

   当然上面的工作可以使用sandbox来做，也可以使用自定义脚本来做，各有好处，相对来说，手工脚本的方式最起码自己更清楚一些。

   动态搭建一主多从，我的一个设想就是快速模拟MHA的环境。

我们先创建一个数据库用户mha_test，作为配置中的连接用户

GRANT ALL PRIVILEGES ON *.* TO 'mha_test'@'%' identified by 'mha_test' ;然后指定一个配置文件，内容如下：

# cat /home/mha/conf/app1.cnf
[server default]
manager_workdir=/home/mha/manager
manager_log=/home/mha/manager/app1/manager.log
port=24801
user=mha_test
password=mha_test
repl_user=rpl_user
repl_password=rpl_pass

[server1]
hostname=127.0.0.1
port=24801
candidate_master=1

[server2]
hostname=127.0.0.1
candidate_master=1
port=24802

[server3]
hostname=127.0.0.1
candidate_master=1
port=24803因为是同一台服务器，所以能够快速模拟MHA的容灾切换和快速恢复。

使用如下的脚本来检测SSH的情况。

#  masterha_check_ssh --conf=/home/mha/conf/app1.cnf基本就是如下的ssh连接请检查。

Wed Apr 12 18:35:52 2017 - [debug]  Connecting via SSH from root@127.0.0.1(127.0.0.1:22) to root@127.0.0.1(127.0.0.1:22)..
Wed Apr 12 18:35:52 2017 - [debug]   ok.
Wed Apr 12 18:35:52 2017 - [debug]  Connecting via SSH from root@127.0.0.1(127.0.0.1:22) to root@127.0.0.1(127.0.0.1:22)..
Wed Apr 12 18:35:52 2017 - [debug]   ok.
Wed Apr 12 18:35:52 2017 - [info] All SSH connection tests passed successfully.检查主从的复制情况，可以使用如下的命令

masterha_check_repl --conf=/home/mha/conf/app1.cnf

输出日志部分如下，可以看到主从关系和复制检测都可以清晰看到。

Wed Apr 12 18:35:29 2017 - [info]
127.0.0.1(127.0.0.1:24801) (current master)
 +--127.0.0.1(127.0.0.1:24802)
 +--127.0.0.1(127.0.0.1:24803)

Wed Apr 12 18:35:29 2017 - [info] Checking replication health on 127.0.0.1..
Wed Apr 12 18:35:29 2017 - [info]  ok.
Wed Apr 12 18:35:29 2017 - [info] Checking replication health on 127.0.0.1..
Wed Apr 12 18:35:29 2017 - [info]  ok.
Wed Apr 12 18:35:29 2017 - [warning] master_ip_failover_script is not defined.
Wed Apr 12 18:35:29 2017 - [warning] shutdown_script is not defined.
Wed Apr 12 18:35:29 2017 - [info] Got exit code 0 (Not master dead).

MySQL Replication Health is OK.接着我们启动MHA-manager

 nohup masterha_manager --conf=/home/mha/conf/app1.cnf  > /tmp/mha_manager.log 2>&1 &如果检查目前 MHA的状态，可以使用如下的命令：

# masterha_check_status --conf=/home/mha/conf/app1.cnf
app1 (pid:11701) is running(0:PING_OK), master:127.0.0.1这个时候我们来破坏一下，可以手工Kill掉24081端口的mysqld_safe和mysqld服务。

这个就会从日志中发现MHA开始工作了。

tail -f /home/mha/manager/app1/manager.log
Wed Apr 12 22:54:53 2017 - [info] Resetting slave info on the new master..
Wed Apr 12 22:54:53 2017 - [info]  127.0.0.1: Resetting slave info succeeded.
Wed Apr 12 22:54:53 2017 - [info] Master failover to 127.0.0.1(127.0.0.1:24802) completed successfully.
Wed Apr 12 22:54:53 2017 - [info]
----- Failover Report -----
app1: MySQL Master failover 127.0.0.1(127.0.0.1:24801) to 127.0.0.1(127.0.0.1:24802) succeeded
Master 127.0.0.1(127.0.0.1:24801) is down!
Check MHA Manager logs at grtest:/home/mha/manager/app1/manager.log for details.
Started automated(non-interactive) failover.
Selected 127.0.0.1(127.0.0.1:24802) as a new master.
127.0.0.1(127.0.0.1:24802): OK: Applying all logs succeeded
127.0.0.1(127.0.0.1:24803): OK: Slave started, replicating from 127.0.0.1(127.0.0.1:24802)
127.0.0.1(127.0.0.1:24802): Resetting slave info succeeded.
Master failover to 127.0.0.1(127.0.0.1:24802) completed successfully.这样一来24802端口的mysql服务会自动接管，由从库变为主库。而24803端口的从库会自动从24802端口的服务接受数据变更。

整个过程有条不紊，会分为5个阶段来做。

时间： 2024-07-30 17:12:29

sandbox和MHA快速测试(r12笔记第32天)的相关文章

MySQL自增列主从不一致的测试(r12笔记第37天)

    MySQL里面有一个问题尤其值得注意,那就是自增列的重复值问题,之前也简单分析过一篇,但是在后续我想了下,还有很多地方需要解释,一个就是从库的自增列是如何维护的,是否重启从库,自增列会受到影响.    我们继续来测试一下.首先复现这个问题.    创建表t1,插入3行数据. use test; [test]> drop table if exists t1; Query OK, 0 rows affected, 1 warning (0.01 sec) > create table t

MySQL 5.6, 5.7并行复制测试(r12笔记第9天)

   对于主从延迟,其实一直以来就是一个颇有争议的话题,在MySQL阵营中,如果容忍一定的延迟的场景,通过主从来达到读写分离是个很不错的方案,但是延迟率到底有多高可以接受,新版本中的并行复制效果怎么样,在不同的版本中是否有改变,我们能否找到一些参考的数据来佐证,这一点上我们可以通过一些小测试来说明.    首先来为了基本按照同一个参考标准,我们就在同一台服务器上安装了5.6,5.7的MySQL服务,另外一台服务器上搭建了从库.    数据库版本为5.6.23 Percona分支, 5.7.17

MySQL中GTID和自增列的数据测试(r12笔记第38天)

  昨天的一篇文章,今天有不少网友向我确认一些细节,我想最近正好在看GTID的东西,可以揉在一起来说说.    GTID这个概念看似简单,实际上还是有不少的门道. 我们来从架构的设计角度来看看存在哪些场景需要考虑GTID的变化.   一主两从的架构模式下GTID的变化   我们就以一主两从的架构为基准进行阐述.在这个架构模式下我们会用到MHA的方案.    如果这个时候Master节点宕机了,MHA就会开启检查机制. 这个时候Slave 1节点就会变为新的Master,Slave 2会从Slav

kali linux web渗透测试学习笔记

    kali linux web渗透测试学习笔记 metasploit使用方法: 启动: 第一步:启用Postgresql服务.service postgresql start 第二步:启用metasploit服务.service matasploit start 第三步:启动框架.msfconsole 一个ASP站点的sql注入 测试数字型注入点 1.网址:asp?ID+13,后面加',看看是什么数据库,然后输入1=1,1=2,得到数据库是microsoft acess 2.转用sqlma

探索性测试（四）：探索性测试并不是快速测试

快速测试也是一种测试的方法,它既可以照本宣科的进行,亦可以探索的方式进行.尽管一个使用高度探索性方法进行测试的测试员可能会执行很多快速测试,而快速测试也通常是运用探索性测试方法时的重要因素.但是,快速测试和探索性测试并不是一样的. 快速测试是需要少量时间或一点精力去准备和执行的廉价测试.这类测试甚至不需要具备与待测试的应用程序相关的大量知识或相关的业务领域知识,但它们有助于快速地获取新的信息.快速测试不是强调广泛和完整,它的目的是用最低的成本快速揭示信息. 快速测试是了解产品.识别区域风险及薄弱

《笑傲测试》笔记（第八式：春寒锦袍）

<笑傲测试>笔记(第八式:春寒锦袍) 主题:如何管理团队以及激励团队 测试是为了先于客户发现问题,这是测试的核心使命. 建立良好的团队氛围,需要考虑这四大要素: (1)管理者的威信 (2)团队的目标和发展方向 (3)团队优先,个人次之 (4)科学的绩效评估和奖励体系 一.管理者的威信 "治军之道,严令为先"统帅要通过严格的法令和纪律树立自己的威信. 威:指权力和能力,其实做一个项目,最考验管理者能力的地方无非是工作任务的分派和人员绩效的评定.对任务的分派,能不能做到人尽其才

总结一下这一百天来的收获(r12笔记第100天)

   1200多天,听起来是一个蛮吉利的数字,也伴随了我1200多个日日夜夜,无论是出差还是节假日,我都尽量腾出时间来写一些东西,就这样不光有技术博客,还有了游记,生活感悟和日常琐事的思考.    当然,维护这么一个自媒体的号对我来说,有得有失,是得到的多还是失去的多,我觉得是一个平衡.就如同工作和生活的平衡一样.    有很多朋友会问我r12笔记里的r是什么意思,每次有朋友问我,我都会解释给他,就是round,一轮的意思,一轮100天,仅此而已.    而这100天对我来说意味着什么呢.我简单

你的网站有多快? 快速测试网站载入速度

对于一个站长而言,网站的速度甚至比内容还要重要.就算网站的内容很优秀,但访问速度很慢,相信没有多少人会耐心地等待.但网站速度慢,是有多方面原因的,要知道什么地方导致速度慢,才能http://www.aliyun.com/zixun/aggregation/7432.html">解决问题.手工对网站进行测速,效率低不说,而且还不准确.这里推荐一个Loadimpact网站,可以快速测试网站载入速度. 借助工具测试网站速度 先登录Loadimpact网站(网址:http://loadimpact

MySQL 5.6, 5.7并行复制测试（二）(r12笔记第10天)

  昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试,当然只是一个开始,因为里面还有不少需要完善的部分,总体的感觉来看MySQL 5.7里的并行复制改进很大,能够极大提高效率,充分利用资源.   那我们来简单回顾一下MySQL的复制里的一些事情,然后继续展开测试.    首先借丁奇大师总结的一个经典的主从复制的流程图来展开. 整个复制的流程中,看似存在多个节点会存在延迟的可能,而如果把这些工作都细化,那么就会有一个很本质的原因,那就是在主库端的更新是多线程,而从库端更新是单线程.