nickva commented on PR #5603: URL: https://github.com/apache/couchdb/pull/5603#issuecomment-3180641561
> > > What is your vision to handle a case when timestamps become inconsistent with each other on different nodes (for one reason or another)? > > > > > > There is some discussion about in first and second commit comments. There is the `_time_seq` endpoint to make the structure visible and it returns results from all shards, so users could detect if something is off. The structure can always be reset safely, without affecting the main data. The condition with it being out of sync is similar to a rewind which is expected sometimes and document it. In this case we also default to sending more data rather than less, that is if a shard copy is blown away and rebuilt, it's update will appear in the changes feed as it was created at the time when they replicated in. It's like a shard range get a rewind back to 0. So users should be prepared to reprocess the same rows like with regular sequences. If anyone needs to rely on strict timestamp it's up to them to insert explicit timestamp in the documents and index on them. > > Can we recreate _time_seq from the _time_seq of another node? We don't need to be exact, approximation of an age would do (correct up to the bin placement). We probably could easier if we rebuilt nodes while there is no interactive traffic going to it (we'd "lock it" so to speak, which is exactly what we do for shard splits). Then, each document in the rebuild replication request could include a times bin in the `#doc.meta` fields, and then we could associate those timestamp with the sequences on the shard. It would be neat to have a fast-forward rebuild like that, it would be like rsync-in the shard over and then renaming but all in Erlang. Or another way to think about it, it's like what we'd so for shard splitting but allow the target to be 1 instead of 2+ and make the calls go to another node not only the local one. -- 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]
