Hi Community,
I am trying to figure out what is the meaning of doc_del_count field on couchdb databases when you browse /api/v2/monitoring endpoint and how it differs with tombstone records. My initial assumption was count of tombstone records and doc_del_countwould be same. But, there is huge different in this. What other records cause doc_del_count to be higher than tombstone records?
Based on Couchdb API and cht-core code, it looks like it’s the straight mapping from what couchdb provides and not something calculated by CHT-Core. Would somebody mind sharing why doc_del_count could be higher than tombstone records count ?
Hi @yuv
This is a great question. In general, I would believe that the numbers would be close, but there might be some explanations about why they are not.
But, there is huge different in this.
Can you share what “huge” means? Do you see this in more instances?
Hi @diana ,
One of our instance (ohw-dhading) has 161,530 doc_del_count. But if you query tombstone records on this, it returns only 8,187 records. That’s almost 20 times different.
Is it an old data set? Do you know if there was some occurence where the sentinel seq was advanced specifically because of deletion of training data, for example?
Hi @diana , yes, it’s an old data set, more than 7 years. I do not remember of the changes you outlined, but can’t rule out that either. I queried another instance and surprisingly, tombstone records are 726 and doc_del_count is 718. Can you explain how sequential advancement can cause doc_del_count to increase?
Hi @yuv
sequential advancement can cause
doc_del_countto increase
It doesn’t.
If it’s an old data set, tombstones are not created for old deletes that have happened since the instance was created, rather from the point of upgrade after tombstones were introduced (in 3.0.0).
Advancing the sentinel seq would just make it skip processing those changes, as in not creating tombstones for a subset of deletes - as they get skipped.