3 ms·
I never said that bugs are "OK", but yeah... Some bugs are acceptable and some are not. Data loss is never acceptable, especially not with databases. And yes,
by piotrSikora 16y ago
I never said that bugs are "OK", but yeah... Some bugs are acceptable and some are not. Data loss is never acceptable, especially not with databases.
And yes, I did my share of software development...
- cheald 16y agoExcept in this case, it's not a bug, it's a design limitation. The MongoDB folks make no bones about it - the software is very limited on 32-bit systems. It warns you about it. It tells you to use 64-bit servers. If you insist on using the tool beyond the bounds for which it was designed to be used, that's your problem, as the developer. Is it a "bug" if you redline your car's engine and cause it to throw a rod? Or is that simply you pushing the machine past its design limits, despite the warnings not to do so?
- piotrSikora 16y agoData loss / corruption is design limitation?
- cheald 16y agoYes. MongoDB doesn't ensure a write to disk before returning on an insert operation (it is what is called "eventually consistent") in order to maintain high write throughput. Because it uses memory-mapped files, it can't address anything larger than a 32-bit pointer on a 32-bit system, and so you would execute an insert, and when the DB eventually tries to write it to disk, it would fail due to lack of resources. Because the write is asynchronous, the client doesn't realize that the data has not been serialized to disk, and you end up with effective data loss. Fixing this would require either a) not using memory-mapped files, or b) ensuring full durability on writes, both of which would massively slow down the data store as a whole.