51Testing软件测试论坛

标题: codis常用操作测试 [打印本页]
作者: TimiZheng    时间: 2019-10-17 14:01
标题: codis常用操作测试
--zookeeper查看配置
  1. cd /usr/local/zookeeper
  2. ./bin/zkCli.sh -server
  3. 127.0.0.1:3181
复制代码

在提示符下使用 :
  1. [zk: 127.0.0.1:3181(CONNECTED) 7] ls /
  2. [zk,
  3. codis3, zookeeper]
复制代码

删除配置目录（谨慎）
  1. [zk: 127.0.0.1:3181(CONNECTED) 13] rmr
  2. /codis3
复制代码


连接codis-proxy
redis-cli -h 192.168.0.4 -p 19000
输入验证密码
输入info
发现看到的是其中一台主库的信息，并不是所有的信息。
set a 1
set b 2
set c 3
......
get a
get b
......
del a
del b



监控页面会比较清楚的展现各个redis中的key数量等信息，可以作为参考




2.6.1 codis-dashboard 异常退出的修复

当 codis-dashboard 启动时，会在外部存储上存放一条数据，用于存储 dashboard 信息，同时作为 LOCK 存在。当 codis-dashboard 安全退出时，会主动删除该数据。当 codis-dashboard 异常退出时，由于之前 LOCK 未安全删除，重启往往会失败。因此 codis-admin 提供了强制删除工具：



确认 codis-dashboard 进程已经退出（很重要）；
当启动时报错
  1. 2016/07/29 10:17:14
  2. topom.go:121: [ERROR] store: acquire lock of codis-test
  3. failed
复制代码

说明已经是被锁住了
运行 codis-admin 删除 LOCK：
  1. $/codisapp/svr/codis/bin/codis-admin --remove-lock --product=codis-test
  2. --zookeeper=127.0.0.1:3181
复制代码



2.6.2 codis-proxy 异常退出的修复

通常 codis-proxy 都是通过 codis-dashboard 进行移除，移除过程中 codis-dashboard 为了安全会向 codis-proxy 发送 offline 指令，成功后才会将 proxy 信息从外部存储中移除。如果 codis-proxy 异常退出，该操作会失败。此时可以使用 codis-admin 工具进行移除：

确认 codis-proxy 进程已经退出（很重要）；
运行 codis-admin 删除 proxy：
  1. /codisapp/svr/codis/bin/codis-admin --dashboard=192.168.0.3:18080
  2. --remove-proxy --addr=192.168.0.3:11080
  3. --force
复制代码
在重启proxy的时候，发现老的并没有被删除，重启的新的又会开一个token，建议把老的删除掉
  1. /codisapp/svr/codis/bin/codis-admin
  2. --dashboard=192.168.0.4:18080 --remove-proxy
  3. --token=167b460fae4d83f0db75f962<wbr>6df008e1 --force
复制代码

从测试结果上看，新版本的codis不需要主动设置主从关系，即使你设置了也会被修改
原来设置的主从结构，再往集群中添加之后，整个关系就变掉了，所以即使你设置了 slaveof ，也是没有什么作用的：



  1. /codisapp/svr/codis/bin/codis-admin --dashboard=192.168.0.3:18080
  2. --group-del --gid=1
  3. --addr=192.168.0.5:7380
  4. /codisapp/svr/codis/bin/codis-admin
  5. --dashboard=192.168.0.3:18080 --group-del --gid=2
  6. --addr=192.168.0.4:7380
  7. /codisapp/svr/codis/bin/codis-admin
  8. --dashboard=192.168.0.3:18080 --group-del --gid=3
  9. --addr=192.168.0.3:7380
复制代码
从集群删除后，进入redis查看，他们的主从关系还在。
再换个顺序再添加进去，将2个一起添加到1组中
  1. /codisapp/svr/codis/bin/codis-admin
  2. --dashboard=192.168.0.3:18080 --group-add --gid=1
  3. --addr=192.168.0.4:7380
  4. /codisapp/svr/codis/bin/codis-admin
  5. --dashboard=192.168.0.3:18080 --group-add --gid=1
  6. --addr=192.168.0.3:7380
  7. /codisapp/svr/codis/bin/codis-admin
  8. --dashboard=192.168.0.3:18080 --group-add --gid=2
  9. --addr=192.168.0.5:7380
复制代码

测试发现，集群关系中显示第一组有两个从库，集群2中一个从库
实际去看redis中，他们的主库还都不是集群中显示的那样。界面上看到是显示为红色，大概就是还没有正式同步的意思吧。

试着同步一次
  1. /codisapp/svr/codis/bin/codis-admin
  2. --dashboard=192.168.0.3:18080 --sync-action --create
  3. --addr=192.168.0.4:7380
复制代码
同步完成后，进入redis就看到真的已经变成相应组的从库了，界面上的红色消失了，后面的key的数量和主库也一致 。



停掉一个redis试试：界面上出现停掉的redis显示为error

手工提升一个redis作为主库
  1. /codisapp/svr/codis/bin/codis-admin
  2. --dashboard=192.168.0.3:18080 --promote-server --gid=1
  3. --addr=192.168.0.4:7380
复制代码
提升后，另一个从库仍然是显示为原来主库，还需要同步一次
  1. /codisapp/svr/codis/bin/codis-admin
  2. --dashboard=192.168.0.3:18080 --sync-action --create
  3. --addr=192.168.0.3:7380
复制代码


把关掉那个再开起来
service redis7379 start
发现先开的这个已经从原来的组里被移走，不会再自动添加到原来的组，并进行同步。
  1. /codisapp/svr/codis/bin/codis-admin
  2. --dashboard=192.168.0.3:18080 --group-add --gid=3
  3. --addr=192.168.0.3:7379
  4. /codisapp/svr/codis/bin/codis-admin
  5. --dashboard=192.168.0.3:18080 --sync-action --create
  6. --addr=192.168.0.3:7379
复制代码



启动codis-ha，测试高可用是否可以自动启动
./start_codis_ha.sh



先停一个从库试下，显示组里的从库。从库再从新开启，仍然在组里，但是同步状态已经没有了，需要手工同步



测试停止主库
系统能够自动的将从库设置为主库，停止前

停止145:7379




发现从库已经自动提升为主库




注意：1、当我们测试的时候，关掉一个proxy，然后再关一个redis主库，这时从库并不能自动转为主库，说明他的状态是需要每个proxy进行报告的。
r2、edis从库不需要设置slaveof
[attach]126841[/attach]
文章来源：沧海大声啸的博客         作者：Kervin（博为峰网校讲师）
讲师作品： MySQL实战校园业务数据库：http://www.atstudy.com/course/2001





欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2