fatihbm edited a comment on issue #6530:
URL: https://github.com/apache/apisix/issues/6530#issuecomment-1069120417
> We don't use iptables. Also, as far as I know, using iptables would not be
an obstacle for tcpdump. I have done all the tests I have done so far on docker
images or VMs. I'm thinking of retrying everything from scratch with VMs set up
specifically for each role here. I'll let you know if I find anything new.
I repeated my tests by setting up a different environment than usual.
First of all, I couldn't use this plugin in the scenarios below,
more than one redis instance running on a single VM or,
Redis cluster docker image.
I don't want to spend any more time getting down to the root cause as the
production environment won't look like this.
Instead, I used a new Redis cluster with six virtual servers. Three masters
and three slaves nodes. You can see the results below.
``If the Redis master node goes down, the slave node does not activate for
20 seconds ("allow_degradation: true" should be used to avoid interruptions)``
``The plugin cannot use other Redis nodes if the Redis master and slave
nodes are unreachable. ("allow_degradation: true" should be used to avoid
interruptions)``
``When the Redis master node comes back, the plugin takes 20 seconds to
rerun.``
``The plugin only tries just one server in the list as the Redis. If it is
not reachable, it does not try the others. ("allow_degradation: true" should be
used to avoid interruptions)``
`"allow_degradation: true" `should be used to continue traffic flow when
Redis goes to unreachable states. I strongly recommend using this parameter for
a production environment for everyone.
In short, the redundancy here is limited to the master-slave only. It
doesn't support a multi-master redis cluster. If you don't have any other
suggestions, I will close this issue. I plan to continue my tests using keydb,
which I think is more reliable instead of redis.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
