3 ms·
Isn't this is a rather common configuration for a distributed DB? Given one node dies before flush, you trust that the remaining nodes in the system will not di
by Too 5y ago
Isn't this is a rather common configuration for a distributed DB? Given one node dies before flush, you trust that the remaining nodes in the system will not die at the same time and live long enough to flush to their respective disks. It's a gamble yes, but depending on your environment the risk can be smaller than the benefits. For a blockchain ledger, you might want to choose the safer corner of CAP in that equation.
- zbentley 5y ago> Isn't this is a rather common configuration for a distributed DB? In my experience it is not. Rather, aggressive fsyncing/O_DIRECT usage are common. The rationale for this is usually partition risk: better to durably log a write before propagating it than to potentially fail in propagating it and then be left in a position of having to either reactively fsync or hope that automatic flush-to-disk will persist your unexpectedly-sole possession of that update.