|
|
|
|
|
by cyanydeez
337 days ago
|
|
You can always have data loss. The intent is that when the client is told the data is saved, it doesnt happen before the garuntee. I dont know if OP achieved this, but the client isnt told "we have your data" until both of the WALs are agreeing. If the system goes down those WALs are used to rebuild data in flight. The speed up allows for decoupling synchronous disk writes that are now parallel. You are not conceptualizing what data loss means in the ACID contract between DB and Client. But you |
|
They did not.
> but the client isnt told "we have your data" until both of the WALs are agreeing.
Wrong. In the proposed scheme, the client writes are ack'd before the WAL writes are flushed. Their contents may or may not agree after subsequent power loss or kernel crash.
(It is generally considered unacceptable for network databases/filers to be lossier than the underlying media. Sometimes stronger guarantees are required/provided, but that is usually the minimum.)