search

shinberg / cpp-hiredis-cluster

c++ cluster wrapper for hiredis with async and unix sockets features
BSD 3-Clause "New" or "Revised" License
65 stars 26 forks source link

Question about the library reaction/and usage following servers disconnection. #9

Closed vin-d closed 7 years ago

vin-d commented 7 years ago

Hi, I'm using the synchronous part of the library and I have issues to understand what I should do when the cluster is in degraded state (when one server of the cluster is gone (disconnceted/crashed,etc... but the slots served by that server are still available through a replica server).

exemple : my redis cluster has 6 servers with replication to 1 A1 : 127.0.0.1:10001 B1 : 127.0.0.1:10002 C1 : 127.0.0.1:10003 A2 : 127.0.0.1:10011 B2 : 127.0.0.1:10012 C2 : 127.0.0.1:10013 A1 and A2 are replicates, and so on (B1-B2, C1-C2).

In my code I create my cluster like that as in exemple.cpp : cluster_p = HiredisCommand<>::createCluster( "127.0.01", 10001 );

Then server on 127.0.0.1:10001 goes down Then send my command : auto reply = HiredisCommand<>::AltCommand( cluster_p, "FOO", "SET %s %s", "FOO", "BAR1" );

which throws. what's the next step ? is it my duty to redo cluster_p = HiredisCommand<>::createCluster( ) using the ip:port of one the 5 other clusters ? until I find one that creates the cluster object successfully ? and only then I resend my auto reply = HiredisCommand<>::AltCommand( cluster_p, "FOO", "SET %s %s", "FOO", "BAR1" ); command ?

Thank you for the help.

shinberg commented 7 years ago

There one way is to write your own ConnectionContainer class. Look at include/container.h to see default connection container (that is not suitable to handling multiple connections per slot range since they are stored at std::map, not even multimap) and in example of writing your own connection container at src/examples/threadpool.cpp. The other way is may be recreating the cluster, but I need to know the result of "cluster slots" command. Can you give me the result of execution "cluster slots" command from redis-cli util in case of one cluster node is down and replication cluster node is up?

vin-d commented 7 years ago

Thank you for the explanation.

Recreating the cluster would be a good solution. it would let all the connection business be handle by the library, and clients using the library would just need to care about their data to redis.

the result of cluster slots commands is here : it's a scenario with 6 servers and the slots being distributed on 3 servers using "replicas" at 1 (6666+6676), (6667+6677), (6668+6678) http://pastebin.com/t0S8KL5c

shinberg commented 7 years ago

Thank you very much for your feedback. As I can see from source code and from output on cluster slots command - reconnection will work fine.