mysql导入codis_codis常用操作测试

--zookeeper查看配置

cd /usr/local/zookeeper

./bin/zkCli.sh -server 127.0.0.1:3181

在提示符下使用 :

[zk: 127.0.0.1:3181(CONNECTED) 7] ls /

[zk, codis3, zookeeper]

删除配置目录(谨慎)

[zk: 127.0.0.1:3181(CONNECTED) 13] 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: [ERROR] 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=167b460fae4d83f0db75f9626df008e1

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