codis常用操作测试

TimiZheng

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

文章来源：沧海大声啸的博客         作者：Kervin（博为峰网校讲师）

讲师作品： MySQL实战校园业务数据库：http://www.atstudy.com/course/2001