feat(master): mongo分片创建

完成相关学习

database/mongoDB/MongoDB.md

@@ -743,9 +743,136 @@ rs.initiate({
     - sh.addShard("shard2/member2.example.com:27011,member4.example.com:27011,member6.example.com:27011");
     - 查看运行结果: sh.status()
 
-### 4. 
-
-
+### 4. MongoDB 监控最佳实践
+
+- 常用的监控工具和手段
+  - MongoDB Ops Manager
+  - Percona
+  - 通用监控平台
+  - 程序脚本
+
+- 如何获取监控数据
+  - 监控信息的来源
+    - db.serverStatus()(主要)
+    - db.isMaster()(次要)
+    - mongostats 命令行工具(只有部分信息)
+  - 注意: db.serverStatus() 包含的监控信息是从上次开机到现在为止的累计数据, 因此不能简单使用
+
+- serverStatus() Output
+  - ![serverStatus.png](pic/serverStatus.png)
+  - serverStatus() 主要信息
+    - connections: 关于连接数的信息
+    - locks: 关于MongoDB使用的锁情况
+    - network: 网络使用情况统计
+    - opcounters: CRUD 的执行次数统计
+    - repl: 复制集配置信息
+  - wiredTiger: 包含大量 wiredTiger 执行情况的信息
+    - block-manager: WT数据块的读写情况
+    - session: session 使用数量
+    - cocurrentTransactions: Ticket 使用情况
+  - mem: 内存使用情况
+  - metrics: 一系列性能指标统计信息
+
+- 监控报警的考量
+  - 具备一定的容错机制以减少误报的发生
+  - 总结应用各指标峰值
+  - 适时调整报警阈值
+  - 留出足够的处理时间
+
+- 建议监控的指标
+  - ![建议监控的指标.png](pic/建议监控的指标.png)
+  - ![建议监控的指标.png](pic/建议监控的指标1.png)
+  - ![建议监控的指标.png](pic/建议监控的指标2.png)
+
+### 5. MongoDB 备份和恢复
+
+- 为何备份
+  - 备份的目的:
+    - 防止硬件故障引起的数据丢失
+    - 防止人为错误误删数据
+    - 时间回溯
+    - 监管要求
+  - 第一点MongoDB生产集群已经通过复制集的多节点实现, 本讲的备份主要是为其他几个目的
+
+- MongoDB 的备份
+  - MongoDB的备份机制分为:
+    - 延迟节点备份
+    - 全量备份 + oplog 增量
+  - 最常见的全量备份方式包括:
+    - mongodump
+    - 复制数据文件
+    - 文件系统快照
+
+- 方案1: 延迟节点备份
+  - ![延迟节点备份.png](pic/延迟节点备份.png)
+  - ![延迟节点备份.png](pic/延迟节点备份1.png)
+
+- 方案2: 全量备份加 oplog
+  - ![全量备份加oplog.png](pic/全量备份加oplog.png)
+  - ![全量备份加oplog.png](pic/全量备份加oplog1.png)
+
+- 复制文件全量备份注意事项
+  - 复制数据库文件:
+    - 必须先关闭节点才能复制, 否则复制到的文件无效;
+    - 也可以选择db.fsyncLock()锁定节点, 但完成后不要忘记db.fsyncUnLock()解锁
+    - 可以且应该在从节点上完成
+    - 该方法时间上会暂时宕机一个从节点, 所以整个过程中应注意投票节点总数
+- 全量备份加oplog注意事项 
+  - 文件系统快照
+    - MongoDB支持使用文件系统快照直接获取数据文件在某一时刻的镜像
+    - 快照过程中可以不用停机
+    - 数据文件和Journal必须在同一个卷上
+    - 快照完成后请尽快复制文件并删除快照
+- 全量备份Mongodump注意事项
+  - mongodump
+    - 使用 mongodump 备份最灵活, 但速度上也是最慢的
+    - mongodump 出来的数据不能表示某个时间点, 只是某个时间段
+    - ![mongodump.png](pic/mongodump.png)
+      - 解决方案: 幂等性
+        - ![解决方案-幂等性.png](pic/解决方案-幂等性.png)
+
+### 6. MongoDB 备份和恢复的操作
+
+- 备份和恢复工具参数
+  - 几个重要参数:
+    - mongodump
+      - --oplog:复制 mongodump 开始到结束过程中的所有 oplog 并输出到结果中。输出文件位于 dump/oplog.bson
+    - mongorestore
+      - --oplogReplay: 恢复完数据文件后再重放 oplog。默认重放 dump/oplog.bson=><dump-directory>/local/oplog.rs.bson。如果 oplog 不在这，则可以:
+        - --oplogFile:指定需要重放的 oplog 文件位置
+        - --oplogLimit: 重放 oplog 时截止到指定时间点
+
+- 实际操作:mongodump/mongorestore
+  - 创建一个数据集, test
+    - 为了模拟dump过程中的数据变化，我们开启一个循环插入数据的线程:
+      - for(var i=0;i<100000; i++){db.random.insertOne({x: Math.random()* 100000});}
+    - 在另一个窗口中我们对其进行mongodump:
+      - mongodump -h 127.0.0.1:27017 --oplog
+    - 回到第一个表, 进行删除表 - (模拟删除)
+      - db.random.drop()
+      - db.random.count() 查看是否删除成功
+    - 在第二台机器, 模拟恢复
+      - mongorestore --host localhost:27017 --oplogReplay
+  - dump 文件的目录结构
+    - ![dump文件的目录结构.png](pic/dump文件的目录结构.png)
+    - ![dump文件操作详解.png](pic/dump文件操作详解.png)
+
+- 更复杂的重放 oplog 方式 - 增量重放
+  - ![更复杂的重放oplog方式.png](pic/更复杂的重放oplog方式.png)
+
+- 分片集备份
+  - 分片集备份大致与复制集原理相同，不过存在以下差异:
+    - 应分别为每个片和config备份;
+    - 分片集备份不仅要考虑一个分片内的一致性问题，还要考虑分片间的一致性问题,因此每个片要能够恢复到同一个时间点;
+
+- 分片集的增量备份
+  - 尽管理论上我们可以使用与复制集同样的方式来为分片集完成增量备份，但实际上分片集的情况更加复杂。这种复杂性来自两个方面:
+    - 各个数据节点的时间不一致:每个数据节点很难完全恢复到一个真正的一致时间点上，通常只能做到大致一致，而这种大致一致通常足够好，除了以下情况;
+    - 分片间的数据迁移:当一部分数据从一个片迁移到另一个片时，最终数据到底在哪里取决于config中的元数据。
+      如果元数据与数据节点之间的时间差异正好导致数据实际已经迁移到新分片上，而元数据仍然认为数据在旧分片上，就会导致数据丢失情况发生。虽然这种情况发生的概率很小，但仍有可能导致问题。
+  - 要避免上述问题的发生，只有定期停止均衡器;只有在均衡器停止期间，增量恢复才能保证正确。  
+
+### 7. MongoDB 安全架构