Mongodb uses the GetLastError command to write data to the security mechanism

I. INTRODUCTION

Many people complain that mongodb is a memory database and has no transactions and may be insecure. In fact, this is a misunderstanding of Mongodb. Mongodb has a complete redolog, binlog, and persistence mechanism, do not worry too much about data loss.

Journal is the redo log in Mongodb, while Oplog is the binlog responsible for copying (corresponding to Mysql ).

On google. groupuser, mongo developers have an explanation as follows:

#########
By default:
Collection data (including oplog) is fsynced to disk every 60 seconds.
Write operations are fsynced to journal file every 100 milliseconds.
Note, oplog is available right away in memory for slaves to read. Oplog is a capped collection
So a new oplog is never created, old data just rolls off.
GetLastError with params:
(No params) = return after data updated in memory.
Fsync: true:
With-journal = wait for next fsync to journal file (up to 100 milliseconds );
Without-journal = force fsync of collection data to disk then return.
W: 2 = wait for data to be updated in memory on at least two replicas.
########

You can see:

1. If journal is enabled, only ms of data will be lost even if the power is down, which can be tolerated by most applications. From 1.9.2 +, mongodb will enable the journal function by default to ensure data security. In addition, the refresh time of journal can be changed. In the range of 2 to MS, run the-journalCommitInterval command.

2. The Oplog and data are refreshed to the disk for 60 s. For replication, you can directly copy the data to the Sencondary node without waiting for the oplog to refresh the disk.

GetLastError Command

GetLastError is a Mongodb command. In terms of its name, it seems to be the last error, but it is actually a client blocking method of Mongodb. Use this command to obtain information about whether the write operation is successful.

GetlastError has several parameters: j, w, and fsync. In most language drivers, this command is encapsulated into writeConcern classes, such as java.

II. When to use this command:

1. Mongodb write operations do not return any values by default, which reduces the waiting time for write operations. That is to say, no matter whether the data is written to the disk or has encountered any errors, no error is reported. However, we generally do not feel relieved to do so. At this time, we call the getlastError command to obtain the returned value.

Java is used as an example. For example, when we create a unique index for a field, we insert two identical data entries for this field without setting WriterConcern or WriterConcern. in NORMAL mode, even if an exception is thrown, no error is returned. The return value of the insert () function in java is the WriteResult class,
WriteResult (CommandResult o, WriteConcern concern ){
_ LastErrorResult = o;
_ LastConcern = concern;
_ Lazy = false;
_ Port = null;
_ Db = null;
    }

This class actually wraps the returned value of getlastError, but the _ lastErrorResult attribute of WriteResult is actually empty. Because the dup key error is a server error, server error is returned only in WriterConcern. SAFE or higher-level mode.

2. When reading and writing Mongodb in multi-threaded mode, if these read and write operations are logically ordered, it is necessary to call the getlasterror command at this time, it is used to ensure that the last operation can be executed only after the next operation is executed, because the connection between the two executions may be different. In most cases, we use the connection pool to connect to mongodb, so this is worth noting.

For example, we encountered this exception "The connection may have been used since this write, cannot obtain a result". There are two causes of The exception. The number of connection pools is too small and The competition is too fierce, writerConcern is not set. SAFE.
See: https://groups.google.com/forum? Fromgroups = #! Topic/mongodb-user/xzw0Cb831VY
PS: in java and other languages, you do not need to display and call this command. You only need to set WriterConcern.

3. getlastError best practices

1. If there are no special requirements, use WriterConcern. SAFE at the lowest level, that is, w = 1.

2. For unimportant data, such as log logs, you can use WriterConcern. NONE or WriterConcern. NORMAL, that is, w =-1 or w = 0, saving the time to wait for the network.

3. Write a large amount of discontinuous data. If getLastError is called for each write, the performance will be reduced because the waiting time for the network is too long. In this case, you can call getLastError every N times. However, in the Shard structure, this method does not necessarily ensure that the previous write is successful.

4. For batchs of write, getlastError should be called at the end of batch write, which not only ensures that the last write is correct, it also ensures that all writes can reach the server. If you write tens of thousands of records consecutively without calling getlastError, you cannot ensure that all data is successfully written in the same TCP socket. This may cause problems in the case of concurrency. To avoid this concurrency problem, you can refer to how to complete batch operations in a link (request), URL: java driver concurrency

Http://www.mongodb.org/display/DOCS/Java+Driver+Concurrency

5. Configuration with extremely high data security requirements: j = true, w = "majority" db. runCommand ({getlasterror: 1, j: true, w: 'Majority ', wtimeout: 10000 })
The java language can be set in the persistent option. These settings in the persistent option are global and can be set separately for a single (connection) operation.

Refer:
1. Http://www.mongodb.org/display/DOCS/Journaling
2. Http://www.mongodb.org/display/DOCS/Java+Driver+Concurrency
3. Http://www.mongodb.org/display/DOCS/getLastError+Command