The errors are coming from the 7.0.0 node in the mixed-mode cluster. When DCP attempts to start, it sends HELO collections to its local memcached, but memcached responds saying that collection is not supported.
2021-04-23T14:57:21.095-07:00 INFO GOXDCR.DcpNozzle: Successfully sent HELO command with userAgent=Goxdcr Dcp SourceBucket:travel-sample TargetBucket:travel-sample. attributes={false 2 false false}
|
With the last attribute being "collections".
Jim Walker, is it true that in a mixed-mode cluster, for a 7.0 node to send HELO collection, that the response will not include an acknowledgement that collection is supported?
According to the KV doc:
Changing: HELLO
|
A new capability flag will be available for clients to indicate that they are collection aware and thus can access documents in collections and understand new error codes. The setting of this flag changes the interpretation of data access commands and enables new error codes.
|
|
The new flag is defined as:
|
PROTOCOL_BINARY_FEATURE_COLLECTIONS = 0x12
|
When implementing per the spec doc, my understanding was that in a mixed-mode cluster, clients can connect to a 7.0 node with collections enabled. All documents are sitting in the default collection anyway. In a mixed-mode cluster, it's probably impossible to create scopes/collections either. Then only once all nodes are upgraded, can scopes/collections be created, and all the associated system events will then be able to come down to all those pre-existing DCP connections by then.
Otherwise, it would mean that XDCR on a 7.0 node in a mixed-mode cluster would then need temporarily connect without HELO'ing collections... and then keep track of all nodes of a cluster until they all have been upgraded to 7.0, and then reconnect with HELO collections. I see no harm just letting the client in this case connect with HELO collections... all the mutations would be in default collection anyway.
The errors are coming from the 7.0.0 node in the mixed-mode cluster. When DCP attempts to start, it sends HELO collections to its local memcached, but memcached responds saying that collection is not supported.
2021-04-23T14:57:21.095-07:00 INFO GOXDCR.DcpNozzle: Successfully sent HELO command with userAgent=Goxdcr Dcp SourceBucket:travel-sample TargetBucket:travel-sample. attributes={false 2 false false}
With the last attribute being "collections".
Jim Walker, is it true that in a mixed-mode cluster, for a 7.0 node to send HELO collection, that the response will not include an acknowledgement that collection is supported?
According to the KV doc:
Changing: HELLO
A new capability flag will be available for clients to indicate that they are collection aware and thus can access documents in collections and understand new error codes. The setting of this flag changes the interpretation of data access commands and enables new error codes.
The new flag is defined as:
PROTOCOL_BINARY_FEATURE_COLLECTIONS = 0x12
When implementing per the spec doc, my understanding was that in a mixed-mode cluster, clients can connect to a 7.0 node with collections enabled. All documents are sitting in the default collection anyway. In a mixed-mode cluster, it's probably impossible to create scopes/collections either. Then only once all nodes are upgraded, can scopes/collections be created, and all the associated system events will then be able to come down to all those pre-existing DCP connections by then.
Otherwise, it would mean that XDCR on a 7.0 node in a mixed-mode cluster would then need temporarily connect without HELO'ing collections... and then keep track of all nodes of a cluster until they all have been upgraded to 7.0, and then reconnect with HELO collections. I see no harm just letting the client in this case connect with HELO collections... all the mutations would be in default collection anyway.