priyath opened a new issue #2040: [Sporadic] Views returning stale data URL: https://github.com/apache/couchdb/issues/2040 [NOTE]: We have observed views in some of our production couch databases returning stale data. ## Description As per the title, views in some of our production couch databases return stale data. This is sporadic but when it does happen, the solution we follow is to do a complete re-index of the database by deleting the index files found in /var/lib/couchdb/.db_design/mrview/*.view which is a costly operation. Our databases also go through a daily purge during a scheduled window using the **_purge** endpoint to permanently delete expired documents, which is followed by compaction to reclaim the purged disk space. We then access all the design documents which I believe is sufficient to perform a re-indexing of the purged data. (?) On observed issues, the stale data corresponds to a purged document. ## Steps to Reproduce I have not been able to successfully reproduce this problem. We sporadically observe this in production and I urgently need to get to the bottom of this to sort things out. ## Expected Behaviour The expected behavior is for the views to return up to date data, and not stale data. ## Your Environment * CouchDB Version used: CouchDB 1.6.1 * Browser name and version: Chrome * Operating System and version: Ubuntu ## Additional context Some questions that I have not found satisfactory answers: 1. Is touching the design documents after the purge sufficient to perform a re-indexing of the views? Is there a better approach here? 2. I performed a purge of a single document in a local couch database and when I accessed a related view, this change was immediately reflected. Does this mean the purged document got reindexed during the view access? 3. > When the indexer identifies that the purge sequence on a database has changed, it compares the purge sequence of the database with that stored in the view index. If the difference between the stored sequence and database is sequence is only 1, then the indexer uses a cached list of the most recently purged documents, and then removes these documents from the index individually. This prevents completely rebuilding the index from scratch. a. Is the purge sequence of the view index the same one that is returned by the /_design/dd/_info endpoint? b. Could an anomaly in the purge sequences between the database and the view index be a cause for purged documents to not get indexed?
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
