From dda5c3da8863c9bcdbbe783ea324be5c99fd3d5b Mon Sep 17 00:00:00 2001 From: Simon Date: Mon, 29 Apr 2019 17:02:20 +0200 Subject: [PATCH] Update Durability.md (#8862) --- .../Books/Manual/Transactions/Durability.md | 35 ++++++++++++------- 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/Documentation/Books/Manual/Transactions/Durability.md b/Documentation/Books/Manual/Transactions/Durability.md index fb064f8506..1463a43b9d 100644 --- a/Documentation/Books/Manual/Transactions/Durability.md +++ b/Documentation/Books/Manual/Transactions/Durability.md @@ -1,9 +1,8 @@ Durability ========== -Transactions are executed in main memory first until there is either a rollback -or a commit. On rollback, no data will be written to disk, but the operations -from the transaction will be reversed in memory. +Transactions are executed until there is either a rollback +or a commit. On rollback the operations from the transaction will be reversed. On commit, all modifications done in the transaction will be written to the collection datafiles. These writes will be synchronized to disk if any of the @@ -54,21 +53,33 @@ full durability for single collection transactions. Using the delayed synchroniz and performance of transactions, but will introduce the risk of losing the last committed transactions in the case of a crash. -In contrast, transactions that modify data in more than one collection are -automatically synchronized to disk. This comes at the cost of several disk sync. -For a multi-collection transaction, the call to the *_executeTransaction* function +The call to the *_executeTransaction* function will only return after the data of all modified collections has been synchronized to disk and the transaction has been made fully durable. This not only reduces the risk of losing data in case of a crash but also ensures consistency after a restart. +MMFiles Storage Engine +---------------------- + +The MMFiles storage engine continuously writes the transaction operation into +a journal file on the disk (Journal is sometimes also referred to as write-ahead-log). + +This means that the commit operation can be very fast because the engine only needs +to write the *commit* marker into the journal (and perform a disk-sync if +*waitForSync* was set to *true*). This also means that failed or aborted +transactions need to be rolled back by reversing every single operation. + In case of a server crash, any multi-collection transactions that were not yet committed or in preparation to be committed will be rolled back on server restart. -For multi-collection transactions, there will be at least one disk sync operation -per modified collection. Multi-collection transactions thus have a potentially higher -cost than single collection transactions. There is no configuration to turn off disk -synchronization for multi-collection transactions in ArangoDB. -The disk sync speed of the system will thus be the most important factor for the -performance of multi-collection transactions. +RocksDB Storage Engine +---------------------- +The RocksDB Storage Engine applies operations in a transaction only in main memory +until they are committed. In case of an a rollback the entire transaction is just +cleared, no extra rollback steps are required. + +In the event of a server-crash the storage engine will scan the write-ahead log +to restore certain meta-data like the number of documents in collection +or the selectivity estimates of secondary indexes.