codis常用操作测试
--zookeeper查看配置cd /usr/local/zookeeper
./bin/zkCli.sh -server
127.0.0.1:3181
在提示符下使用 :
ls /
[zk,
codis3, zookeeper]
删除配置目录（谨慎）
rmr
/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 进程已经退出（很重要）；
当启动时报错
2016/07/29 10:17:14
topom.go:121: store: acquire lock of codis-test
failed
说明已经是被锁住了
运行 codis-admin 删除 LOCK：
$/codisapp/svr/codis/bin/codis-admin --remove-lock --product=codis-test
--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：
/codisapp/svr/codis/bin/codis-admin --dashboard=192.168.0.3:18080
--remove-proxy --addr=192.168.0.3:11080
--force在重启proxy的时候，发现老的并没有被删除，重启的新的又会开一个token，建议把老的删除掉
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.4:18080 --remove-proxy
--token=167b460fae4d83f0db75f962<wbr>6df008e1 --force
从测试结果上看，新版本的codis不需要主动设置主从关系，即使你设置了也会被修改
原来设置的主从结构，再往集群中添加之后，整个关系就变掉了，所以即使你设置了 slaveof ，也是没有什么作用的：
/codisapp/svr/codis/bin/codis-admin --dashboard=192.168.0.3:18080
--group-del --gid=1
--addr=192.168.0.5:7380
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --group-del --gid=2
--addr=192.168.0.4:7380
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --group-del --gid=3
--addr=192.168.0.3:7380从集群删除后，进入redis查看，他们的主从关系还在。
再换个顺序再添加进去，将2个一起添加到1组中
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --group-add --gid=1
--addr=192.168.0.4:7380
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --group-add --gid=1
--addr=192.168.0.3:7380
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --group-add --gid=2
--addr=192.168.0.5:7380
测试发现，集群关系中显示第一组有两个从库，集群2中一个从库
实际去看redis中，他们的主库还都不是集群中显示的那样。界面上看到是显示为红色，大概就是还没有正式同步的意思吧。
试着同步一次
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --sync-action --create
--addr=192.168.0.4:7380同步完成后，进入redis就看到真的已经变成相应组的从库了，界面上的红色消失了，后面的key的数量和主库也一致 。
停掉一个redis试试：界面上出现停掉的redis显示为error
手工提升一个redis作为主库
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --promote-server --gid=1
--addr=192.168.0.4:7380提升后，另一个从库仍然是显示为原来主库，还需要同步一次
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --sync-action --create
--addr=192.168.0.3:7380
把关掉那个再开起来
service redis7379 start
发现先开的这个已经从原来的组里被移走，不会再自动添加到原来的组，并进行同步。
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --group-add --gid=3
--addr=192.168.0.3:7379
/codisapp/svr/codis/bin/codis-admin
--dashboard=192.168.0.3:18080 --sync-action --create
--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
页:
[1]
