Introduction: Introducing MongoDB's two engines and Wal technology
One MMAPV1 engine:
Previous note: The MMAPV1 engine is also evolving with the version, so it only covers the general
1 default version engine: MongoDB <3.2
2 Lock Level: 1 Version < 2.2: Supports only process level lock, one Mongod instance one lock.
2 2.2≤version < 3.0: Supports library level lock, one db one lock
3 Version> 3..0 Collection level
3 MVCC: Multi-version concurrency control not supported
Two Wiredtiger engines
1 default version engine: MongoDB >= 3.2
2 Lock Level: Document level (table) = ' document-level concurrency (concurrency at the documentation level)
3 MVCC: Supports multi-version concurrency control
4 Checkpoint Durability (periodic Checkpoint generates a mirror of the data set, which is the basis for disaster recovery)
5 Commit-level Durability (open wal (recorded in the Jonural log) after logging to the WT database update will first write log, and periodically refresh, and then modify the data for disaster recovery based)
6 recovery mechanism: The specific strategy is
- Do it once every 60s checkpoint
- Turn on write ahead log, checkpoint when log size reaches 2GB, and automatically delete unwanted log files.
- Each time
commit_transaction
, call Fsync to persist the already commit log
- Data reliability recovery from MongoDB by Checkpoint+wal log records
Based on the above configuration, MongoDB can guarantee the service crash, all committed operations can be restored via log
3rd the corresponding understanding of the log file
1 MongoDB oplog = mysql Binlog
2 MongoDB WAL = mysql Undo+redo log
Four-Wal technology interpretation
wal, the Write-ahead Logging, is a standard way to implement transaction logging. WAL's central idea is to write the log first, then write the data, and the changes to the data files must occur after the changes have been recorded in the log file. A database system that uses the Wal log can improve performance in two ways when a transaction commits:
- Multiple client write log files can be completed with a single fsync ()
- Log files are sequential, and the cost of synchronizing logs is much smaller than the cost of synchronizing data pages
In general, after using the Wal mechanism, the disk write operation is only about half of the traditional rollback log, which greatly improves the efficiency of database disk I/O operations, thus improving the performance of the database.
With the Wal mechanism, it is not necessary to flush the data pages to disk every time the transaction commits, and if a database crashes, we can use the log to recover the database, and any records that have not yet been attached to the data page will be re-made from the log records (this is called rolling forward recovery, also known as REDO). Wal log mode provides checkpoint operation to schedule data update operations
Five about the engine is still a lot of things that do not understand, interested in the message can be exchanged
MongoDB Fifth article ~ Two kinds of engine for MongoDB