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 @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?
sequential advancement can cause doc_del_count to increase
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.