Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update Durability.md (#8862)

This commit is contained in:
Simon 2019-04-29 17:02:20 +02:00 committed by Jan
parent 885c473ad7
commit dda5c3da88
1 changed files with 23 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
Documentation/Books/Manual/Transactions/Durability.md
View File

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