undefined | Better HN

0 pointsloeg8mo ago0 comments

No, we saw this scheme, it just doesn't work. Either of the async writes can fail after ack'ing the logical write to the client as successful (e.g., kernel crash or power failure) and then you have lost data.

0 comments

cyanydeez8mo 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

loegOP8mo ago

> I dont know if OP achieved this,

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.)

j / k navigate · click thread line to collapse