Open StrathCole opened 3 years ago
@StrathCole thank you for the issue. You are the master branch, correct? Can you please look at this branch where I've made a fix and confirm it eliminates the issue? Can you share more details about your topology? Can you send me the steps to reproduce?
@StrathCole Do you have expiration or eviction policies for the indexes?
Hello, thanks for looking into this. I don't think there are special policies set, it is a "default" redis cluster.
I will have to set up a new "dummy cluster" for re-testing this because I cannot risk crashing the live-system currently. Sorry for the delay because of that.
Okay, I have tried to reproduce the behaviour. To send the commands I have used the RedisCluster class from phpredis with "rawCommand" method.
First I made a test with module-oss.so from the RSCoordinator github repository. It worked without problems. Then I tried using redisearch.so from the RediSearch github repository.
The 6 nodes all additionally listen on a unix socket (because we had some problems with tcp states on the live server lately, but as said it works correcly with the RSCoordinator branch).
$redis = new RedisCluster(null, ['127.0.0.1:7001', '127.0.0.1:7000', '127.0.0.1:7002', '127.0.0.1:7003', '127.0.0.1:7004', '127.0.0.1:7005']);
$redis->setOption(RedisCluster::OPT_SLAVE_FAILOVER, RedisCluster::FAILOVER_ERROR);
var_dump($redis->rawCommand('unix:///opt/redis/redis-7000.sock', 'FT.CREATE', 'testindex', 'ON', 'HASH', 'PREFIX', '1', 'xa_', 'STOPWORDS', '0', 'SCHEMA', 'n_id', 'TEXT', 'SORTABLE', 'n_name', 'TEXT', 'WEIGHT', '5.0', 'SORTABLE'));
This results in "true" so the command succeeded. But now there comes the strange part. Although the script connected to the node 7000, the index was only(!) created on node 7002 and its replication node:
root@redistest:/opt/redis# redis-cli -c -p 7000 FT._LIST
(empty array)
root@redistest:/opt/redis# redis-cli -c -p 7001 FT._LIST
(empty array)
root@redistest:/opt/redis# redis-cli -c -p 7002 FT._LIST
1) "testindex"
root@redistest:/opt/redis# redis-cli -c -p 7003 FT._LIST
1) "testindex"
root@redistest:/opt/redis# redis-cli -c -p 7004 FT._LIST
(empty array)
root@redistest:/opt/redis# redis-cli -c -p 7005 FT._LIST
(empty array)
When now using module-oss.so instead, the FT.CREATE creates the index on all nodes.
But in the test I could not reproduce the dying redis instance, the FT. functions just only worked on some targets and not on all. I then switched to module-oss.so and none* of the nodes showed the created index. But again, I could no longer make the instances crash.
My guess now is that there was a very uncommon situation on the live system that we first used redisearch.so and created indexes that did not work. When we switched to module-oss.so after it, the nodes crashed on FT.DROP. There was some notes in the log saying "missing index but key information exists" or similar. So I can only guess that I missed a step while trying to reproduce it on a fresh server now. :cry: Sorry.
While using https://github.com/redis/redis-py it turned out that .dropindex()
uses FT.DROP
which is not present in the documentation. Why does this command still work if there is FT.DROPINDEX
?
Furthermore, the two commands have different behaviors, in fact, FT.DROP
still crashes the server but FT.DROPINDEX
does not. Is there a motivation behind this behavior?
Redis: redis_version:6.2.6
RediSearch module: 20406
When sending an FT.DROP to a master node that might not have this index yes, the node crashes. The log was done with module-oss.so (RSCoordinator) but I tried the redisearch.so, too. The messages remain the same, no matter if using redis 6.0 or 6.2.5.