codis功能性和可用性测试

1.将proxy1 offline后，验证通过proxy2的19000端口访问redis

[root@mvxl2531 ~]# redis-cli -h 10.16.2.139 -p 19000

10.16.2.139:19000> auth 123456

OK

10.16.2.139:19000> mset key1 v1 key2 v2 key3 v3

OK

10.16.2.139:19000>

访问和执行mset命令正常

2.将proxy1 offline后，且将codis server1的6379和6380关掉，验证通过proxy2的19000端口访问redis

mvxl2530主机上将6379对应的进程kill：

[root@mvxl2530 codis]# ps -ef|grep codis

root 7177 1 0 17:01 ? 00:00:21 ./bin/codis-config -c ./config_138.ini dashboard

root 8898 1 0 20:59 ? 00:00:01 codis-server *:6379

root 8919 1 0 20:59 ? 00:00:01 codis-server *:6380

root 9234 8054 0 21:30 pts/2 00:00:00 grep codis

[root@mvxl2530 codis]# kill -9 8919

[root@mvxl2530 codis]# ps -ef|grep codis

root 7177 1 0 17:01 ? 00:00:21 ./bin/codis-config -c ./config_138.ini dashboard

root 8898 1 0 20:59 ? 00:00:01 codis-server *:6379

root 9285 8054 0 21:31 pts/2 00:00:00 grep codis

mvxl2531访问验证，访问和执行正常

[root@mvxl2531 ~]# redis-cli -h 10.16.2.139 -p 19000

10.16.2.139:19000> auth 123456

OK

10.16.2.139:19000> mset key1 v1 key2 v2 key3 v3

OK

3.将proxy1 offline后，且将codis server1的6379和6380关掉，验证通过proxy2的19000端口访问redis

mvxl2530主机上将6380对应的进程kill：

[root@mvxl2530 codis]# ps -ef|grep codis

root 7177 1 0 17:01 ? 00:00:21 ./bin/codis-config -c ./config_138.ini dashboard

root 8898 1 0 20:59 ? 00:00:01 codis-server *:6379

root 9285 8054 0 21:31 pts/2 00:00:00 grep codis

[root@mvxl2530 codis]# kill -9 8898

[root@mvxl2530 codis]# ps -ef|grep codis

root 7177 1 0 17:01 ? 00:00:21 ./bin/codis-config -c ./config_138.ini dashboard

root 9326 8054 0 21:34 pts/2 00:00:00 grep codis

mvxl2531访问验证：

[root@mvxl2531 ~]# redis-cli -h 10.16.2.139 -p 19000

10.16.2.139:19000> auth 123456

OK

10.16.2.139:19000> mset key1 v1 key2 v2 key3 v3

(error) NOAUTH Authentication required.

10.16.2.139:19000> auth 123456

OK

10.16.2.139:19000> mset key1 v1 key2 v2 key3 v3

(error) NOAUTH Authentication required.

10.16.2.139:19000> set name zengxuewen

(error) NOAUTH Authentication required.

发现所有命令执行都提示需要认证，实际上认证后，问题同样出现。

在面板图形界面上手工操将10.16.2.139:6380提升为master后，验证命令执行正常。

[root@mvxl2531 ~]# redis-cli -h 10.16.2.139 -p 19000

10.16.2.139:19000> auth 123456

OK

10.16.2.139:19000> mset key1 v1 key2 v2 key3 v3

OK

10.16.2.139:19000> set name zengxuewen

OK

4.将slave提升为master后，原master变成offline下线，需要先从server
group中移除offline的server，再重新增加到group中成为slave。

5.通过redis客户端向codis proxy 2写数据，从codis proxy 1读取数据，验证同组之间数据是否同步正常

Proxy2上写入数据：

10.16.2.139:19000> set zxw zengxuewen

OK

10.16.2.139:19000> set pxy pengxiaoyang

OK

10.16.2.139:19000>

Proxy1上读数据：

10.16.2.138:19000> get zxw

"zengxuewen"

10.16.2.138:19000> get pxy

"pengxiaoyang"

6.
测试大数据量同步

插入20W个key(每次测试运行前，需要更改INSTANCE_NAME)

vim redis-key.sh

#!/bin/bash

REDISCLI="redis-cli -h 10.16.2.138 -p 19000 -a 123456 -n 0 set"

ID=1

while [ $ID -le 50000 ]

do

INSTANCE_NAME="i-2-$ID-VM"

UUID=`cat /proc/sys/kernel/random/uuid`

CREATED=`date "+%Y-%m-%d %H:%M:%S"`

$REDISCLT vm_instance:$ID:instance_name "$INSTANCE_NAME"

$REDISCLT vm_instance:$ID:uuid "$UUID"

$REDISCLT vm_instance:$ID:created "$CREATED"

$REDISCLT vm_instance:$INSTANCE_NAME:id "$ID"

ID=`expr $ID + 1`

Done

查看面板，各组主从数据同步正常，显示如下：



7．codis下删除一个server组和slot迁移

先将该组中的slot迁移到其他的组，然后删除掉该组！否则会提示组在占用slot，而不能将组删除，而且一个机器处于master状态，是无法将其删除的
将第二个组的slave移除后，再将master移除报错如下：



将server组2的slot迁移到组1：



点”slots status”查看迁移进度,下面显示已迁移完718 slot，如下：



等迁移完后，面板可看到如下：



不可以直接移除master，但可以删除整个server group 2，如下：


刷新面板网页后，查看如下所示，server group 2不见了。



进入到zookeeper中查看，也只有一个group 1了。
[root@mvxl2530 zookeeper]# cd /usr/local/zookeeper
[root@mvxl2530 zookeeper]# ./bin/zkCli.sh -server 127.0.0.1:2181
[zk: 127.0.0.1:2181(CONNECTED) 6] ls /zk/codis/db_gls/servers
[group_1]
8．codis下增加一个server组：
在面板上点“New Server Group”:


依次增加server group到group 2中：



将512到1023 slot迁移到group 2上：


通过面板可以查看迁移进度，点”slots status”，也可通过命令去查看未完成的迁移任务：

[root@mvxl2530 zookeeper]# cd /usr/local/zookeeper
[root@mvxl2530 zookeeper]# ./bin/zkCli.sh -server 127.0.0.1:2181
[zk: 127.0.0.1:2181(CONNECTED) 0] ls /zk/codis/db_gls/migrate_tasks

9.直接用redis来测试各组间的同步

[root@mvxl2530 script]# redis-cli -h 10.16.2.138 -p 6379 -a 123456

10.16.2.138:6379> set four 4

OK

10.16.2.138:6379> get four

"4"

10.16.2.138:6379> quit

[root@mvxl2530 script]# redis-cli -h 10.16.2.139 -p 6380 -a 123456

10.16.2.139:6380> get four

"4"

10.16.2.139:6380> quit

[root@mvxl2530 script]# redis-cli -h 10.16.2.139 -p 6379 -a 123456

10.16.2.139:6379> set five 5

OK

10.16.2.139:6379> quit

[root@mvxl2530 script]# redis-cli -h 10.16.2.138 -p 6380 -a 123456

10.16.2.138:6380> get five

若上面主从之间不同步的话，将从库移除，再增加后就可同步了。

10.测试ha下挂掉master后，slave是否自动提升为主库

Kill掉10.16.2.138上的主库6379：

[root@mvxl2530 bin]# ps -ef|grep codis

root 31160 1 0 23:02 pts/2 00:00:07 ./bin/codis-config -c ./config_138.ini dashboard

root 31205 1 0 23:03 ? 00:00:01 codis-server *:6379

root 31206 1 0 23:03 ? 00:00:01 codis-server *:6380

root 31222 1 0 23:03 pts/2 00:00:03 ./bin/codis-proxy -c ./config_138.ini -L ./log/proxy.log --cpu=4 --addr=0.0.0.0:19000 --http-addr=0.0.0.0:11000

root 31356 1 0 23:05 pts/2 00:00:00 ./codis-ha --codis-config=10.16.2.138:18087 --productName=gls

root 31967 30558 0 23:29 pts/2 00:00:00 grep codis

[root@mvxl2530 bin]# kill -9 31205

再查看面板显示，发现从库已自动提升为主库，原主库已offline下线。

11.安装完ha后，面板显示所有slave都为offline，但slave都是正常活动的.

出现的问题具体为：master是正常，slave是offline的，然后，我重新增加处于offline状态的slave库到组中，面板上显示slave库变成了真正的slave，估计过了几秒，自动将slave变成了master，然后原master就变成了offline两个组的主从都是这问题，我再重复上面操作，问题这样一直出现。
经查明：redis配置文件中有设置requirepass 123456，ha组件在当前版本不支持密码验证。去掉codis config.ini及redis 配置文件中的密码后，重启服务，面板显示正常。
官网：https://github.com/CodisLabs/codis

12.测试将proxy 2挂掉后，停掉一个主库，看是否自动主从切换

查看各组状态，面板显示正常。

先关闭proxy2，再kill 10.16.2.139的6379，检查是否有自动切换：

[root@mvxl2531 ~]# ps -ef|grep codis

root 6622 1 0 May15 ? 00:00:43 codis-server *:6380

root 6623 1 0 May15 ? 00:00:36 codis-server *:6379

root 6641 1 0 May15 ? 00:01:19 ./bin/codis-proxy -c ./config_139.ini -L ./log/proxy.log --cpu=4 --addr=0.0.0.0:19000 --http-addr=0.0.0.0:11000

root 8601 8541 0 10:54 pts/0 00:00:00 grep codis

[root@mvxl2531 ~]# kill -9 6641

[root@mvxl2531 ~]# kill -9 6623

[root@mvxl2531 ~]#

查看server
组状态，说明能正常实现主从切换。