ttlsa Tutorial Series mongodb - (five) mongodb architecture - Copy & Copy principles set

Why 80% of the code can not do farming architect? >>>  

mongodb Cluster: replication, replication set and fragmentation. It is strongly recommended to use the copy function mongodb in a production environment. Copy with the failover, read expansion, thermal and offline backup batch operations. By default, the master node is responsible for all client read and write requests from the node can not write unreadable. A working principle 1. mongodb replication requires at least two instances. Wherein a master node is responsible for handling client requests, the rest are from the node, is responsible for copying data on the primary node. All operations oplog master node records thereon, obtained from the node periodically polls the master node operation, and then perform these operations on their own copy of the data to ensure data consistency from the node to the master node. 2. The recording operation is referred to as the master node oplog (operation log), stored in a local database (local database is not copied, copy used to store status information). oplog Each document represents the operations performed on the primary node. oplog only as a mechanism for maintaining data synchronization with the node from the master node. 3. oplog.rs capped collection is a fixed length. By default, using the example of the 64-bit oplog 5% of the available space, this space will be allocated in the local database, and pre-allocated when the server starts. 4. If the master node from the node behind very far, oplog not executing the log from the node, oplog may have a round rolled around, it will keep up the master node from the node, the copy will stop. From the node need to do a complete synchronization can be used {resync: 1} resynchronization command performed manually or automatically designated --autoresync resynchronization allowed options from the start node. The cost of resynchronization expensive, should try to avoid, how to avoid them is to configure a large enough oplog. View oplog information:

> db.oplog.rs.stats()
{
        "ns" : "local.oplog.rs",
        "count" : 7276573,
        "size" : 1980730564,
        "avgObjSize" : 272.20651314842854,
        "storageSize" : 2097156096,
        "numExtents" : 1,
        "nindexes" : 0,
        "lastExtentSize" : 2097156096,
        "paddingFactor" : 1,
        "systemFlags" : 0,
        "userFlags" : 0,
        "totalIndexSize" : 0,
        "indexSizes" : {

        },
        "capped" : true,
        "max" : 2147483647,
        "ok" : 1
}

View oplog.rs content:

> db.oplog.rs.find().limit(1).toArray()
[
        {
                "ts" : Timestamp(1357529944000, 1),
                "h" : NumberLong("-3237467944396345731"),
                "v" : 2,
                "op" : "i",
                "ns" : "ttlsa_event.ttlsa_events",
                "o" : {
                        "_id" : ObjectId("50ea43599ca66a2d7e000000"),
                        "aid" : 110000,
                        "kid" : 10007,
                        "tag" : "Mobile",
                        "uid" : 368514901,
                        "stmp" : 1357529945,
                        "born" : 1357529945,
                        "total" : 1,
                        "val" : [
                                {
                                        "nickname" : "m44332148",
                                        "productid" : 109350,
                                        "product" : "三国时代OL",
                                        "stmp" : 1357529945
                                }
                        ]
                }
        }
]

Field Description: ts: timestamp operation, an operation for performing time tracking. op: Operation types, i represents the insert, u represents the update, d for delete ns: to perform an operation set name o:. Copy the content of the document two mongodb support the traditional master-slave architecture. No automatic failover, specify the master and slave end. Set architecture is strongly recommended to copy, copy copy set architecture than architecture better maintenance, more powerful. master-slave architecture is generally used in the following two situations: 1. slave over 11 2. The need to replicate a single database schema master-salve configuration: // master server boot master, simply specify the master parameters

# mongod --master

// slave server start slave, you need to specify slave and master parameters IP and port

# mongod --slave --source master_server:27017

Master-slave replication options are: 1. --only specify only the copy of the database on the slave node 2. --slavedelay specify the number of seconds delay slave node synchronization master 3. --fastsync data snapshot master node based start slave 4. --autoresync slave node if the node is not synchronized, the active resynchronization 5. --oplogSize master node oplog size three. replication set copy sets least three servers or two arbitration servers + a. Copy the set of configuration See : http: //www.ttlsa.com/html/1093.html view metadata information oplog the master:

> db.printReplicationInfo()
configured oplog size: 2000MB
log length start to end: 16685504secs (4634.86hrs)
oplog first event time: Mon Jan 07 2013 11:42:50 GMT+0800 (CST)
oplog last event time: Fri Jul 19 2013 14:34:34 GMT+0800 (CST)
now: Fri Jul 19 2013 14:34:38 GMT+0800 (CST)

Field Description: configured oplog size: oplog file size log length start to end: Enable period oplog first oplog log event time: generating a first time oplog last transaction log event time: Time now produce the last transaction log: Now time to view the synchronization status of slave:

> db.printSlaveReplicationInfo()
source:   10.1.11.157:27017
         no replication info, yet.  State: ARBITER
source:   10.1.11.156:27017
         syncedTo: Fri Jul 19 2013 14:34:42 GMT+0800 (CST)
                 = 2 secs ago (0hrs)

Field Description: source: from IP and port syncedTo library: The current situation increases the synchronization node:

ttlsa:PRIMARY> rs.add("10.1.11.111:27017")

Reduce node:

ttlsa:PRIMARY> rs.remove("10.1.11.111:27017")

Allowed the read operation from the library:

ttlsa:SECONDARY> db.getMongo().setSlaveOK()

Manual transfer primary:

ttlsa:SECONDARY> rs.freeze([secs]) //make a node ineligible to become primary for the time specified 
ttlsa:PRIMARY> rs.stepDown([secs]) //step down as primary (momentarily) (disconnects)

Replication set status: 1. STARTUP: just added to the replication set, loading configuration has not been 2. STARTUP2: configuration has been loaded, the initialization state 3. RECOVERING: being restored, read NA 4. ARBITER: arbiter 5. DOWN: Node unreachable 6. uNKNOWN: not acquiring other nodes do not know what state the state generally occurs in only two members of the framework, split brain 7. rEMOVED: data rollback rollback ends: copy set removal 8. rOLLBACK , or SECONDARY RECOVERING proceeds to state 9. FATAL: error. View Log grep "replSet FATAL" to find the wrong reasons, re-do sync 10. PRIMARY: The master node 11. SECONDARY:. Nodes four backup copy certified if the certification is enabled, you need to master node and local nodes from the database, build a the same user name and password of a user, can read and write. When connected to the master node from the node, the user will be stored in local.system.users with the authentication, the user first attempts to use repl, if not, using the first available local.system.users the user.

> use local
> db.addUser("repl","password")

V. slice slice next section said. Please indicate the source:  http://www.ttlsa.com/html/1679.html

Reproduced in: https: //my.oschina.net/766/blog/211104