Mongodb persistence (4)

Mongodb 1.8 and later versions began to support journal, which we often call redolog for fault recovery and persistence. 1. Enable the journal function to use the mongod -- journal option, or disable -- nojournal. In Versions later than 2.0, journal is enabled by default to ensure data security. In version2.0 or 32-bit Systems

Mongodb 1.8 and later versions began to support journal, which is the redo log we often call for fault recovery and persistence. 1. Enable the journal function to use the mongod -- journal option, or disable -- nojournal. In Versions later than 2.0, journal is enabled by default to ensure data security. In version 2.0 or 32-bit Systems

Mongodb 1.8 and later versions began to support journal, which is the redo log we often call for fault recovery and persistence. 1. Enable the journal function to use the mongod -- journal option, or disable -- nojournal. In Versions later than 2.0, journal is enabled by default to ensure data security. Version <2.0 or 32-bit is disabled by default. Because the journal will use more memory (as described below), and the 32-bit system supports too small memory, it is disabled. Because Mongodb initializes the journal Space in advance and does not open the listening port before the initialization is complete, it may be unable to connect for a period of time after the startup, so you don't have to worry about it. Check the log, connect after the journal Initialization is complete. We recommend that you try to use ext4, xfs, and other file systems, such as ext3, to initialize the disk very slowly. After you start mongod, for a long time, the log is printed, and ext4 can be used instantly. In addition, Mongodb uses a pre-allocated mechanism for db space during runtime. Therefore, it is helpful to use a more advanced file system to prevent high concurrency congestion caused by disks. 2 .? The file, recovery, and backup journal is stored in the/journal/folder of the data file. The runtime file is generally like this, where j.32 and j.33 are the journal files in use, when a single file reaches 1 GB, a new file will be created. The old file will not be recycled and will be automatically deleted. Lsn stores the last journal serial number used. It is a binary file, which actually stores a timestamp from the system startup to the present. Prealloc.2 is an unused initialized journal File. Use db. shutdownServer () and kill-2 to shut down the system, that is, clean shutdown. All files except prealloc. * in the journal folder will be deleted. If the system powers down or crashes during running, mongo will use journal for recovery when it starts again without running repair. We can back up journal, oplog, and data snapshots to restore them to the nearest state when data is lost, ensuring security. This is what Shanda's cloud computing system does. At the same time, it uses the go language for asynchronous backup and has the opportunity to communicate with them. 3 .? In addition to fault recovery, batch submission of journal can also improve the write performance. batch-commit (batch-commit) is usually refreshed once every MS by default. In this process, all writes can be committed at one time, which is a single transaction. All writes are successful or all of them fail. The refresh time can be changed in the range of 2-300 ms, but this is not absolute. Mongodb provides the journal latency test function:> db. runCommand ("journalLatencyTest") in actual running, the refresh time is a big one in the journalCommitInterval setting and latency test. Some server disks have cache but no battery. The delay is quite high without the cache. In the figure, the cache is not used. Mongo also supports ssd and can be used if necessary. In a busy system, when journal and data are placed on a volume, the value is also relatively large. View journal running status:>? Db. serverStatus (): commits: the number of operations submitted within the journalCommitInterval time. JournaledMB: the amount of data written to the journal file within the journalCommitInterval time. WriteToDataFilesMB: the volume of data that is refreshed from journal to disk during the journalCommitInterval period. Compression: v> 2.0 indicates the compression ratio of data submitted to the journal by the client. Note that not all data is written to the journal. (Journaled_size_of_data/uncompressed_size_of_data ). CommitsInWriteLock: number of submissions when a write lock is present, which indicates a high write pressure. EarlyCommits: the time before journalCommitInterval and the number of times the mongod request was submitted. Use this parameter to determine if journalCommitInterval is too long. Dur. timeMS. prepLogBuffer: time from privateView ing to Logbuffer. Dur. timeMS. writeToJournal: the time from the logbuffer refresh to the journalfile. Dur. timeMS. writeToDataFiles: ing from journalbuffer to MMF, And then refresh the MMF to the disk. The file system and disk will affect the write performance. Dur. timeMS. remapPrivateView: The time to remap data to PrivateView, the smaller the performance, the better. This will be explained later, which is why journal uses more memory, because journal uses another memory area called PrivateView. 4 .? Conclusion: After using journal, mongodb ensures backup and disaster tolerance. Batch submission also makes writing faster (not persistent ). We also need to choose a more advanced file system and disk with more memory to ensure the good running of journal. Refer: http://docs.mongodb.org/manual/reference/server-status/#durhttp://www.mongodb.org/display/DOCS/Journalinghttp://www.mongodb.org/display/DOCS/Journaling+Administration+Notes