Some problems of Golang MongoDB driving MgO

This is a creation in Article, where the information may have evolved or changed.

MgO is the Golang drive of MongoDB.

Connection pool

We create a new session with the Dial function:

Session, Err: = MgO. Dial (URL)

The session created can communicate with all the servers in the MongoDB cluster. It is important to note that for a cluster to call only once Dial, the New and Copy methods of the session returned by this Dial can create more sessions, which share the underlying connection pool (the Dial creates multiple sessions Use a different connection pool).

More specifically, look at the strong session (strong is a consistency model, where the strong session is discussed because it is relatively simple, see below). A strong session will use a fixed connection, in other words, MGO will not help you create more connections. We can create more sessions by using the session's New and Copy, which means that more connections can be built and that these connections can be reused through the internal connection pool.

MgO provides a way for setpoollimit to control the maximum number of connections that are in use, but it is likely that the number of connections actually established is greater than this value. The official documentation specifically states that you do not use this to define concurrency limits for your application (It is a bad practice and an unsupported using case to uses the database driver to define the CONCU Rrency limit of an application). Setpoollimit cannot control the number of connections actually established, if you want to control it, it is more prudent to directly control the number of sessions.

More related discussions:

Https://groups.google.com/forum/#!topic/mgo-users/oVJcXKPvNbU

https://groups.google.com/forum/?fromgroups=#!topic/mgo-users/s1juysWHO8w

Consistency modes (consistency mode)

You can set the consistency mode for each session (consistency mode):

1. Strong consistency Mode (default)
2. Monotonic consistency Mode
3. Eventual consistency mode

Strong consistency Mode

The session reads and writes to the primary server and uses a unique connection, so all read and write operations are completely consistent (there is no problem of disorderly ordering or getting old data).

Monotonic consistency Mode

The session's read operation starts with a secondary server (and through a unique connection), and as soon as a write occurs, the session's connection is switched to the primary server. This shows that in this mode, you can scatter some read operations to the secondary server, but the read operation is not necessarily able to obtain the latest data. The official statement is more detailed:

in The monotonic consistency mode reads is not being entirely up-to-date, but they would a Lways See the history of changes moving forward, the data read would be consistent across sequential queries in the same SE Ssion, and modifications made within the session would be observed in following queries (Read-your-writes).

In practice, the monotonic mode was obtained by performing initial reads on a unique connection to an arbitrary secondary, If one is available, and once the first write happens, the session connection are switched over to the primary server. This manages to distribute some of the reading load with secondaries, while maintaining some useful guarantees.

Eventual consistency mode

The read operation of the session is initiated to any secondary server, and multiple reads do not necessarily use the same connection, that is, the read operation is not necessarily orderly. Session writes are always initiated to the primary server, but may use different connections, that is, the write operation is not necessarily orderly. Eventual consistency mode is the fastest, it is a resource-friendly (resource-friendly) mode.