mongo常用操作

mongo术语：

https://docs.mongodb.com/manual/reference/glossary/

构建mongo集群可参考：

https://docs.mongodb.com/manual/tutorial/deploy-shard-cluster/

mongo的shard机制：

https://docs.mongodb.com/manual/sharding/

mongo集群的状态：

mongos> sh.status();
--- Sharding Status --- 
  sharding version: {
        "_id" : 1,
        "minCompatibleVersion" : 5,
        "currentVersion" : 6,
        "clusterId" : ObjectId("5b150d3329f5ae8c563a9e80")
  }
  shards:
        {  "_id" : "shard0000",  "host" : "x.x.x.x1:9202",  "state" : 1 }
        {  "_id" : "shard0001",  "host" : "x.x.x.x2:9203",  "state" : 1 }
  active mongoses:
        "3.6.5" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  no
        Failed balancer rounds in last 5 attempts:  5
        Last reported error:  Connection refused
        Time of Reported error:  Tue Sep 11 2018 17:16:25 GMT+0800 (CST)
        Migration Results for the last 24 hours: 
                No recent migrations
  databases:
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
                config.system.sessions
                        shard key: { "_id" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                shard0000       1
                        { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : shard0000 Timestamp(1, 0) 
        {  "_id" : "test",  "primary" : "shard0000",  "partitioned" : false }
        {  "_id" : "test2",  "primary" : "shard0000",  "partitioned" : true }
        {  "_id" : "test3",  "primary" : "shard0001",  "partitioned" : false }
        {  "_id" : "test4",  "primary" : "shard0000",  "partitioned" : false }

这里就可以看到有几个shards了。

要看replica set，在mongos里是看不了的，要到config server或者shardsvr上看。

replica-set-name:PRIMARY> rs.status();
{
        "set" : "replica-set-name",
        "date" : ISODate("2018-09-19T13:04:05.505Z"),
        "myState" : 1,
        "term" : NumberLong(4),
        "configsvr" : true,
        "heartbeatIntervalMillis" : NumberLong(2000),
        "optimes" : {
                "lastCommittedOpTime" : {
                        "ts" : Timestamp(1537362245, 1),
                        "t" : NumberLong(4)
                },
                "readConcernMajorityOpTime" : {
                        "ts" : Timestamp(1537362245, 1),
                        "t" : NumberLong(4)
                },
                "appliedOpTime" : {
                        "ts" : Timestamp(1537362245, 1),
                        "t" : NumberLong(4)
                },
                "durableOpTime" : {
                        "ts" : Timestamp(1537362245, 1),
                        "t" : NumberLong(4)
                }
        },
        "members" : [
                {
                        "_id" : 0,
                        "name" : "x.x.x.x:9204",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 4180052,
                        "optime" : {
                                "ts" : Timestamp(1537362245, 1),
                                "t" : NumberLong(4)
                        },
                        "optimeDate" : ISODate("2018-09-19T13:04:05Z"),
                        "electionTime" : Timestamp(1533182194, 1),
                        "electionDate" : ISODate("2018-08-02T03:56:34Z"),
                        "configVersion" : 12604,
                        "self" : true
                }
        ],
        "ok" : 1,
        "operationTime" : Timestamp(1537362245, 1),
        "$gleStats" : {
                "lastOpTime" : Timestamp(0, 0),
                "electionId" : ObjectId("7fffffff0000000000000004")
        },
        "$clusterTime" : {
                "clusterTime" : Timestamp(1537362245, 1),
                "signature" : {
                        "hash" : BinData(0,"fsfsfsdfsdfsdfsdfsdfsfsfs"),
                        "keyId" : NumberLong(0)
                }
        }
}

默认db和collection都没有分shard的，需要手动操作下。

MongoSpark的配置选项可以在这里找到：

https://docs.mongodb.com/spark-connector/master/configuration/

写的话就看WriteConfig好了。每个参数应该传什么值还是看代码好些：

https://github.com/mongodb/mongo-spark/blob/master/src/main/scala/com/mongodb/spark/config/WriteConfig.scala

 查看是否sharding也可以用：

mongos> db.collection.getShardDistribution()
Collection db.collection is not sharded.

 查看当前操作：

db.currentOp()

提高写的性能：

1. batch write。

Strategies for Bulk Inserts to a Sharded Collection

1. Pre-Split the Collection 这里其实就是因为如果是空集合，那么每次还要 take time to receive data, create splits, and distribute the split chunks to the available shards. 这一步就是为了减少这个开销，当然如果集合已经存在了就可以省略这一步了。
2. Unordered Writes to mongos 无序的batch write可以并行，提升插入性能
3. Avoid Monotonic Throttling 递增地插入，会导致永远只在一个chunk上操作，导致了其实最后的性能都会和单个shard的差不多，因此最好是能保证随机，这样就会均衡地放在多个shard上。

https://docs.mongodb.com/manual/core/bulk-write-operations/

2. unordered。

Bulk write operations can be either ordered or unordered.
With an ordered list of operations, MongoDB executes the operations serially. If an error occurs during the processing of one of the write operations, MongoDB will return without processing any remaining write operations in the list. See ordered Bulk Write
With an unordered list of operations, MongoDB can execute the operations in parallel, but this behavior is not guaranteed. If an error occurs during the processing of one of the write operations, MongoDB will continue to process remaining write operations in the list. See Unordered Bulk Write.
Executing an ordered list of operations on a sharded collection will generally be slower than executing an unordered list since with an ordered list, each operation must wait for the previous operation to finish.
By default, bulkWrite() performs ordered operations. To specify unordered write operations, set ordered : false in the options document.

默认是有序的，比较坑爹。

https://docs.mongodb.com/manual/core/bulk-write-operations/

3. Write Concern

主要是这几个参数：

{ w: <value>, j: <boolean>, wtimeout: <number> }

• the w option to request acknowledgement that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.
• the j option to request acknowledgement that the write operation has been written to the journal, and
• the wtimeout option to specify a time limit to prevent write operations from blocking indefinitely.

也就是说，写操作是否需要确认，可想而知，不需要确认当然就快很多啦。但是网络的错误这里还是可以捕获到的。

https://docs.mongodb.com/manual/reference/write-concern/

Journaling日志机制

如果开启了journal日志功能，MongoDB会在数据目录下创建一个journal文件夹，用来存放预写重放日志。同时这个目录也会有一个last-sequence-number文件。如果MongoDB安全关闭的话，会自动删除此目录下的所有文件，如果是崩溃导致的关闭，不会删除日志文件。在MongoDB进程重启的过程中，journal日志文件用于自动修复数据到一个一致性的状态。

MongoDB先在内存保存写操作，并记录journaling日志到磁盘，然后才会把数据改变刷入到磁盘上的数据文件。

https://jockchou.gitbooks.io/getting-started-with-mongodb/content/book/journal.html

每隔60秒, 或当Journal文件超过2GB, 会有一个叫Checkpoints的事件, WT会把WT Cache中的数据存入FS Cache, 然后一次性将所有改变应用到磁盘上。换言之, 如果你既没有用Replica Set, 也没有用Journal。那么在你宕机的时候仍然能从最后一个Checkpoints恢复数据。

https://learn-mongodb.readthedocs.io/storage-engine/wiredtiger-vs-mmapv1/

 导入数据

bin/mongoimport --host [IP] --port [PORT] --drop --file [FILE] --db [DB] --collection [COLLECTION]

文件就按行隔开，每行是一条json。类似这样：

{ "item": "journal", "qty": 25, "size": { "h": 14, "w": 21, "uom": "cm" }, "status": "A" }
{ "item": "notebook", "qty": 50, "size": { "h": 8.5, "w": 11, "uom": "in" }, "status": "A" }
{ "item": "paper", "qty": 100, "size": { "h": 8.5, "w": 11, "uom": "in" }, "status": "D" }
{ "item": "planner", "qty": 75, "size": { "h": 22.85, "w": 30, "uom": "cm" }, "status": "D" }
{ "item": "postcard", "qty": 45, "size": { "h": 10, "w": 15.25, "uom": "cm" }, "status": "A" }

 导出数据

https://docs.mongodb.com/manual/reference/program/mongodump/

mongodump是导成二进制的。要导出json或csv，用mongoexport.

https://docs.mongodb.com/manual/reference/program/mongoexport/

bin/mongoexport --host [IP] --port [PORT] --db [DB] --collection [COLLECTION] --fields [FIELDS] --type csv --out [FILE_NAME] --query '{"FIELD_NAME" : {$exists : true}}'

 性能监控

用mongostat。

bin/mongostat -h 【HOST:PORT】

结果如下：

insert query update delete getmore command flushes mapped vsize  res faults qrw arw net_in net_out conn                time
   936    *0 255482     *0       0  1436|0       0     0B 1.76G 149M      0 0|0 0|0  55.6m   8.91m  365 Oct 11 21:24:47.771
   785    *0 272450     *0       0  1321|0       0     0B 1.76G 150M      0 0|0 0|0  57.4m   9.47m  365 Oct 11 21:24:48.771
   965    *0 262622     *0       0  1490|0       0     0B 1.76G 149M      0 0|0 0|0  56.7m   9.16m  365 Oct 11 21:24:49.771
   929    *0 224718     *0       0  1372|0       0     0B 1.76G 149M      0 0|0 0|0  48.7m   7.84m  365 Oct 11 21:24:50.772
   824    *0 271654     *0       0  1363|0       0     0B 1.76G 149M      0 0|0 0|0  57.9m   9.47m  365 Oct 11 21:24:51.772
   925    *0 272144     *0       0  1464|0       0     0B 1.76G 149M      0 0|0 0|0  58.0m   9.48m  365 Oct 11 21:24:52.771

 删除shard

http://www.mongoing.com/docs/tutorial/remove-shards-from-cluster.html

通过以下命令不断地查看shard的状态。

use admin
db.runCommand( { removeShard: "mongodb0" } )

或者：

db.adminCommand({removeShard:'shard0002'})

一旦 state 的值变为 “completed”,就可以安全地停止 mongodb0` 分片上的monod进程. 

mongos> db.runCommand({removeShard:'shard0002'})
{
        "ok" : 0,
        "errmsg" : "removeShard may only be run against the admin database.",
        "code" : 13,
        "codeName" : "Unauthorized",
        "$clusterTime" : {
                "clusterTime" : Timestamp(1539325098, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1539325098, 1)
}
mongos> use admin
switched to db admin
mongos> db.runCommand({removeShard:'shard0002'})
{
        "msg" : "draining started successfully",
        "state" : "started",
        "shard" : "shard0002",
        "note" : "you need to drop or movePrimary these databases",
        "dbsToMove" : [ ],
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1539325149, 2),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1539325149, 2)
}
mongos> db.runCommand({removeShard:'shard0002'})
{
        "msg" : "draining ongoing",
        "state" : "ongoing",
        "remaining" : {
                "chunks" : NumberLong(3495),
                "dbs" : NumberLong(0)
        },
        "note" : "you need to drop or movePrimary these databases",
        "dbsToMove" : [ ],
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1539325150, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1539325150, 1)
}

如果想更改draining的状态，直接改数据库就行：

//connect to a mongos server with the mongo javascript shell
use config
//unset draining from all shards
db.shards.update({},{$unset:{draining:true}}, false, true)

https://stackoverflow.com/questions/11813664/stop-draining-shard-in-mongodb

但是如果删除了切片，又想把它加回来，必须将data数据目录清理干净才可以再加入集群，否则即使能加入成功也不会存储数据，集合都不会被创建。

https://blog.csdn.net/liqi_q/article/details/79047361

Adding a shard to a cluster creates an imbalance, since the new shard has no chunks. While MongoDB begins migrating data to the new shard immediately, it can take some time before the cluster balances. See the Add Shards to a Cluster tutorial for instructions on adding a shard to a cluster.

Removing a shard from a cluster creates a similar imbalance, since chunks residing on that shard must be redistributed throughout the cluster. While MongoDB begins draining a removed shard immediately, it can take some time before the cluster balances. Do not shutdown the servers associated to the removed shard during this process.

When you remove a shard in a cluster with an uneven chunk distribution, the balancer first removes the chunks from the draining shard and then balances the remaining uneven chunk distribution.

可以看到，整个balancing都是立刻生效的。

https://docs.mongodb.com/manual/core/sharding-balancer-administration/#sharding-balancing

实际上整个迁移过程如下：

1. The balancer process sends the moveChunk command to the source shard.
2. The source starts the move with an internal moveChunk command. During the migration process, operations to the chunk route to the source shard. The source shard is responsible for incoming write operations for the chunk.
3. The destination shard builds any indexes required by the source that do not exist on the destination.
4. The destination shard begins requesting documents in the chunk and starts receiving copies of the data. See also Chunk Migration and Replication.
5. After receiving the final document in the chunk, the destination shard starts a synchronization process to ensure that it has the changes to the migrated documents that occurred during the migration.
6. When fully synchronized, the source shard connects to the config database and updates the cluster metadata with the new location for the chunk.
7. After the source shard completes the update of the metadata, and once there are no open cursors on the chunk, the source shard deletes its copy of the documents.

可以看到，整个过程中，由source shard来接管请求，由destination shard来同步最新的修改，最终是有两份拷贝，等到数据同步完成了，再把source shard的拷贝删了。也就是说，在迁移的过程中，写是往旧的shard写的。