Redis CLUSTER NODES format change in 4.0

[Salvatore Sanfilippo]

Hi list,

Marc Gravell noticed and kindly reported that in the 4.0 release notes
I forgot to mention that CLUSTER NODES output changed a bit in the new
release. Now node addresses are like this:

470b4028aba5f2cde905a2cb327e15390c86c45c 127.0.0.1:7003@17003 slave

As you can see what was before 127.0.0.1:7003 is now 127.0.0.1:7003@17003.
The change was needed in order to have a well-specified cluster bus
port for each node, now it is no longer needed for the port to be at
+10000 offset. However this required a format change.

The change was needed in order to support containers / NAT-ted
environments in general.
This is also the reason why the Redis Cluster bus binary protocol is
not compatible between 3.2 and 4.0.

Client libraries should use CLUSTER SLOTS
(https://redis.io/commands/cluster-slots) in order to fetch the list
of nodes to interact with Redis Cluster, however if client libraries
are still using the CLUSTER NODES interface, please make sure to
upgrade your client code in order to ignore the "@<bus-port>" part.

I'm upgrading the 4.0 Change Log file to add a note about this change.
Thanks to Marc for pinging me about this.

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - Redis Labs https://redislabs.com

"If a system is to have conceptual integrity, someone must control the
concepts."
— Fred Brooks, "The Mythical Man-Month", 1975.

[Davide Ferrari]

Hello Salvatore

On Wednesday, August 2, 2017 at 12:39:31 PM UTC+2, Salvatore Sanfilippo wrote:

This is also the reason why the Redis Cluster bus binary protocol is
not compatible between 3.2 and 4.0.

so, what's the update plan for 3.2 -> 4.0 in a production environment?

Thanks

[Salvatore Sanfilippo]

On Wed, Aug 2, 2017 at 1:26 PM, Davide Ferrari <dav...@billymob.com> wrote:

> so, what's the update plan for 3.2 -> 4.0 in a production environment?

Hello Davide,

unfortunately the current option is to mass restart the cluster with
4.0, I tried hard but it was impossible to make the change in a way
that was backward compatible,
however recently I tried to find a solution to avoid the mass restart
without having double-code everywhere with the two versions of the
message headers. What could be a possibility is to put some
translation code in clusterReadHandler(), before calling
clusterPorcessPacket(), so I would release:

1) A version of 4.0.x that is able to turn protocol v0 into v1 before
processing the packet.
2) A version of 3.2.x that is able to turn protocol v1 into v0 before
processing the packet.

So the 3.2 Cluster users could rolling-upgrade to 3.2.x, and then to 4.0.x.

--