Details
-
Bug
-
Resolution: Fixed
-
Major
-
6.0.3
-
Untriaged
-
Unknown
Description
The analytics team have a backup which was created using ForestDB as the storage format; some of the documents are corrupt (ForestDB can't read them). The issue is that ForestDB is logging that it can't read the documents but it isn't returning the error to backup, it's simply continuing to read the next valid document. This isn't ideal since we are unable to inform users that the data is corrupt.
Expected results:
When iterating through all the documents in the ForestDB file we should receive an error if ForestDB is unable to read a document.
Actual results:
ForestDB continues returning documents ignoring (but logging) the documents it failed to read; this puts cbbackupmgr in a position where it is unable to inform users of the corruption.
Attachments:
I've attached a cbbackupmgr log which contains a restore (to blackhole i.e. we read the data from disk, then send it to /dev/null) we can see that there are some cases where ForestDB has failed to read the documents. For this run I built a one of version of cbbackupmgr which would log (with the prefix "TEMP") any errors returned by the ForestDB iterator (as we can see, it didn't return any).
Attachments
Issue Links
- relates to
-
MB-37869 weekly performance tests (analytics) stuck when restoring data
- Closed