Open jcoglan opened 1 year ago
decoded the last three;
[{couchdb@localhost,[0,536870911], {4,<<"ebc4fe9">>,couchdb@localhost}}, {couchdb@localhost,[536870912,1073741823],
{4,{split,<<"5cb6670">>},couchdb@localhost}},
{couchdb@localhost,[1073741824,1610612735],
{0,<<"09a8278">>,couchdb@localhost}},
{couchdb@localhost,[1610612736,2147483647],
{3,<<"a9557bb">>,couchdb@localhost}},
{couchdb@localhost,[2147483648,2684354559],
{4,<<"66b10a8">>,couchdb@localhost}},
{couchdb@localhost,[2684354560,3221225471],
{0,<<"23a7175">>,couchdb@localhost}},
{couchdb@localhost,[3221225472,3758096383],
{6,{split,<<"65e487d">>},couchdb@localhost}},
{couchdb@localhost,[3758096384,4294967295],
{6,{split,<<"65e487d">>},couchdb@localhost}}],
{couchdb@localhost,[0,536870911],
{4,<<"ebc4fe9">>,couchdb@localhost}},
{couchdb@localhost,[536870912,1073741823],
{4,{split,<<"5cb6670">>},couchdb@localhost}},
{couchdb@localhost,[1073741824,1610612735],
{0,<<"09a8278">>,couchdb@localhost}},
{couchdb@localhost,[1610612736,2147483647],
{3,<<"a9557bb">>,couchdb@localhost}},
{couchdb@localhost,[2147483648,2684354559],
{4,<<"66b10a8">>,couchdb@localhost}},
{couchdb@localhost,[2684354560,3221225471],
{0,<<"23a7175">>,couchdb@localhost}},
{couchdb@localhost,[3221225472,3758096383],
{6,<<"c1fac62">>,couchdb@localhost}},
{couchdb@localhost,[3758096384,4294967295],
{6,{split,<<"65e487d">>},couchdb@localhost}}],
{couchdb@localhost,[0,536870911],
{4,<<"ebc4fe9">>,couchdb@localhost}},
{couchdb@localhost,[536870912,1073741823],
{4,{split,<<"5cb6670">>},couchdb@localhost}},
{couchdb@localhost,[1073741824,1610612735],
{0,<<"09a8278">>,couchdb@localhost}},
{couchdb@localhost,[1610612736,2147483647],
{3,<<"a9557bb">>,couchdb@localhost}},
{couchdb@localhost,[2147483648,2684354559],
{4,<<"66b10a8">>,couchdb@localhost}},
{couchdb@localhost,[2684354560,3221225471],
{0,<<"23a7175">>,couchdb@localhost}},
{couchdb@localhost,[3221225472,3758096383],
{6,<<"c1fac62">>,couchdb@localhost}},
{couchdb@localhost,[3758096384,4294967295],
{1,<<"8321e28">>,couchdb@localhost}}]
Thanks for creating the issue @jcoglan !
to the captured seq value returns results out of order
How did we determine they are out of order? Is that based on the N-...
first part of the sequence number?
The descending value of the numeric part of the seq value looked curious to me so I ran these values through a parser tool and obtained:
original: '30-g1AAAAKVeJzLYWBg4MhgTmEQTM4vTc5ISXLIyU9OzMnILy7JAUoxJTIkyf___z8rgzmRJRcowJ6alGySlmqJTQMeY5IUgGSSPcykDKYUBtbigpzMErCZpslJZmbmBqSa6QAyMx5qJgPYJAPLRAsjcwtSTUoAmVRPVdflsQBJhgYgBTR2PshcNjRzzUxTTSzMU8gydwHE3P0InxsZJ5obmpuSZdoBiGn3qe3KBxBz_5NobhYAREXOrQ', parsed: [ [ 'couchdb@localhost-00000000-1fffffff', 4 ], [ 'couchdb@localhost-20000000-3fffffff', 4 ], [ 'couchdb@localhost-40000000-5fffffff', 0 ], [ 'couchdb@localhost-60000000-7fffffff', 4 ], [ 'couchdb@localhost-80000000-9fffffff', 6 ], [ 'couchdb@localhost-a0000000-bfffffff', 0 ], [ 'couchdb@localhost-c0000000-dfffffff', 6 ], [ 'couchdb@localhost-e0000000-ffffffff', 6 ] ]
original: '23-g1AAAAKBeJzLYWBg4MhgTmEQTM4vTc5ISXLIyU9OzMnILy7JAUoxJTIkyf___z8rgzmRJRcowJ6alGySlmqJTQMeY5IUgGSSPdQkBohJQGMMTA1INckBZFI8ikkGlokWRuYWpJqUADKpHmoSI9ikREtTU_OkJBJNymMBkgwNQApo2HyQaWwZTCkMrMUFOZklYHPNTFNNLMxTyDJ3AcTc_Qj_Ghknmhuam5Jl2gGIafep7coHEHP_k2huFgBjZMkL', parsed: [ [ 'couchdb@localhost-00000000-1fffffff', 4 ], [ 'couchdb@localhost-20000000-3fffffff', 0 ], [ 'couchdb@localhost-40000000-5fffffff', 0 ], [ 'couchdb@localhost-60000000-7fffffff', 1 ], [ 'couchdb@localhost-80000000-9fffffff', 6 ], [ 'couchdb@localhost-a0000000-bfffffff', 0 ], [ 'couchdb@localhost-c0000000-dfffffff', 6 ], [ 'couchdb@localhost-e0000000-ffffffff', 6 ] ]
I think the parser tool is ignoring an important split
marker and just shows the sequence number. Let's see what it's hiding:
fabric_view_changes:decode_seq(<<"30-g1AAAAKVeJzLYWBg4MhgTmEQTM4vTc5ISXLIyU9OzMnILy7JAUoxJTIkyf___z8rgzmRJRcowJ6alGySlmqJTQMeY5IUgGSSPcykDKYUBtbigpzMErCZpslJZmbmBqSa6QAyMx5qJgPYJAPLRAsjcwtSTUoAmVRPVdflsQBJhgYgBTR2PshcNjRzzUxTTSzMU8gydwHE3P0InxsZJ5obmpuSZdoBiGn3qe3KBxBz_5NobhYAREXOrQ">>).
[{couchdb@localhost,[0,536870911],
{4,<<"ebc4fe9">>,couchdb@localhost}},
{couchdb@localhost,[536870912,1073741823],
{4,{split,<<"5cb6670">>},couchdb@localhost}},
{couchdb@localhost,[1073741824,1610612735],
{0,<<"09a8278">>,couchdb@localhost}},
{couchdb@localhost,[1610612736,2147483647],
{4,{split,<<"5cb6670">>},couchdb@localhost}},
{couchdb@localhost,[2147483648,2684354559],
{6,{split,<<"65e487d">>},couchdb@localhost}},
{couchdb@localhost,[2684354560,3221225471],
{0,<<"23a7175">>,couchdb@localhost}},
{couchdb@localhost,[3221225472,3758096383],
{6,{split,<<"65e487d">>},couchdb@localhost}},
{couchdb@localhost,[3758096384,4294967295],
{6,{split,<<"65e487d">>},couchdb@localhost}}]
We notice how {4,{split,<<"5cb6670">>},couchdb@localhost}}
looks a bit different than {0,<<"09a8278">>,couchdb@localhost}}
. Specifically the {split,<<"5cb6670">>}
part. That part shows a split "marker", that it looks that particular range was likely the result of a split from the original sequence with (Q=2) with original since seq node uuid for the now missing (split) range. The 4
part shows the original sequence from the Q=2 sequence.
In general looking at the N-....
is not too helpful. To make the sequences look "nicer" we could avoid adding the sequence to the total sum when computing N
if the sequence is a split marker. That would make the N-
value increment "nicer". But that value is effectively meaningless and it is thrown away when we parse the sequence.
It would still be a nice minor ergonomic fix but so far nothing here violates correctness, we're not throwing changes away or returning them out of order.
The first two _changes requests return an empty results array as expected, showing that a seq value continues to work after one round of splitting.
Ah, that's good to know that it works after one round of splitting.
The final one, where a seq captured while q=2 is used when q=8 returns the entire history, with events out of order.
So rewinding after two rounds of splitting is a more interesting issue. We may want make two separate issues: 1) make the N-...
look a prettier after a split 2) "try to avoid rewinds after two rounds of splitting". The second one seems more pressing and harder solve.
This should fix the apparent incorrect order https://github.com/apache/couchdb/pull/4643
Description
We have observed that if we capture a
seq
value from a_changes
response, and then perform two rounds of shard splitting on a database, requesting_changes?since=X
withX
set to the capturedseq
value returns results out of order; events from the same shard are not presented in ascending order. This might affect the behaviour of replicators/indexers relying onseq
values for checkpointing.Steps to Reproduce
The following script reproduces the behaviour on my machine:
The first two
_changes
requests return an emptyresults
array as expected, showing that aseq
value continues to work after one round of splitting. The final one, where aseq
captured whileq=2
is used whenq=8
returns the entire history, with events out of order.For example, on one run of this script the
_changes
response contained:The descending value of the numeric part of the
seq
value looked curious to me so I ran these values through a parser tool and obtained:The second event has a lower sequence number for shards
20-3f
and60-7f
, showing events from some shards are being returned out of order.Using the
seq
values in this response also returned events out of order, for example requesting/test-db/_changes?since=30-g1AAAAKVeJzLYWBg4MhgTmEQTM4vTc5ISXLIyU9OzMnILy7JAUoxJTIkyf___z8rgzmRJRcowJ6alGySlmqJTQMeY5IUgGSSPcykDKYUBtbigpzMErCZpslJZmbmBqSa6QAyMx5qJgPYJAPLRAsjcwtSTUoAmVRPVdflsQBJhgYgBTR2PshcNjRzzUxTTSzMU8gydwHE3P0InxsZJ5obmpuSZdoBiGn3qe3KBxBz_5NobhYAREXOrQ
returns some out of order events:Expected Behaviour
Results in the
_changes
response should be ordered such that events from the same shard are presented in ascending order. Ideally, thesince
value would continue to limit the results returned, instead of returning the entire history.Your Environment
CouchDB info: