mongodb全家桶
| 软件 | 描述 |
|---|---|
mongod |
数据库软件服务 |
mongo |
命令行工具，管理mongodb数据库 |
mongos |
路由进程，分片环境使用 |
mongodump/mongorestore
|
命令行数据库备份与恢复工具 |
Compass |
mongodb GUI管理工具 |
MongoDB Ops Manager(企业版) |
mongodb集群管理软件 自动化管理补丁，升级，在线扩容 监控报警，持续备份，任意时间点恢复等 |
MongoDB BI Connerctor（企业版） |
SQL解释器、BI套接件 |
MongoDB Charts（企业版） |
mongodb可视化软件，托拉拽创建mongodb图表 创建，分享和嵌入mongodb可视化 专为mongodb文档模型设计，一行代码在自己应用程序嵌入图表 |
Atlas（付费及免费） |
mongodb云托管服务，包括永久免费云数据库 |
mongodb备份
备份机制分为：延迟节点备份；全量备份【方式包括：mongodump、复制数据文件、文件系统快照】+ oplog增量=任意时间点备份恢复
备份目的：防止硬件故障丢失数据、防止人为误删数据、时间回溯、监管要求
mongodb集群已经通过复制集的多节点实现备份了
延迟节点备份：正常从节点几乎与主节点相同状态，延迟节点根据延迟时间保持该时间节点的状态
全量备份+oplog：
复制文件：
必须先关闭节点才能复制，否则复制文件无效，也可选择db.fsyncLock()锁定节点，完成后db.fsyncUnlock()解锁，
应该在从节点完成，该方法实际上会暂时宕机一个从节点，所以整个过程中应注意投票节点总数。
文件系统快照：
获取数据文件在某一时刻镜像，快照过程可以不用停机，数据文件和Journal必须同一卷上，快照完成后请尽快复制文件并删除快照。
mongodump全量备份：
备份最灵活，速度也是最慢，备份的数据不能表示某个时间点，只是某个时间段。
解决方案：幂等性
mongodump备份数据mongodump -h 127.0.0.1:27017 -d test -c test
mongodump
--oplog ：复制mongodump开始到结束过程中所有oplog并输出到结果中，输出文件位于dump/oplog.bson
mongorestore
--oplogReplay:恢复完数据后再重放oplog，默认重放dump/oplog.bson
=><dump-directory>/local/oplog.rs.bson.如果oplog不在则可：
--oplogFile:指定重放的oplog文件位置
--oplogLimit:重放oplog时截止到指定时间点
mongo:PRIMARY> db.test.find()
{ "_id" : ObjectId("6146f5e9a50876842a04b10c"), "name" : "lucy" }
{ "_id" : ObjectId("6146f5e9a50876842a04b10d"), "name" : "lily" }
mongo:PRIMARY> db.test.count()
2
mongo:PRIMARY> for(var i=0;i<10000;i++){db.test.insertOne({'name':'name'+Math.random()})}
{
"acknowledged" : true,
"insertedId" : ObjectId("61475436fbd482ba9813c52e")
}
mongo:PRIMARY> db.test.count()
10002
[root@xxx bin]# mongodump --host localhost:27019 --oplog
2021-09-19T23:20:32.422+0800 writing admin.system.version to
2021-09-19T23:20:32.422+0800 done dumping admin.system.version (1 document)
2021-09-19T23:20:32.423+0800 writing test.test to
2021-09-19T23:20:32.454+0800 done dumping test.test (10002 documents)
2021-09-19T23:20:32.454+0800 writing captured oplog to
2021-09-19T23:20:32.455+0800 dumped 1 oplog entry
[root@iZbp18qq1n1pli2wswopjbZ bin]#
#执行dump成功后，会在mongodump同级目录下生成dump目录
admin 【system.version.bson system.version.metadata.json】
oplog.bson #dump期间的产生的日志
test【test.bson test.metadata.json】#数据文件和集合元数据
mongorestore恢复数据mongorestore -h 127.0.0.1:27017 -d test -c test test.bson
恢复dump目录下为数据库名目录mock,mock目录下为orders.bson和orders.metadata.json文件
windows: mongorestore -h 127.0.0.1:27017 C:\Users\DragonersLi\Desktop\aggregation\dump
linux： /www/server/mongodb/bin/mongorestore -h 127.0.0.1:17027 -u root -p root /root/aggregation/dump
mongorestore --host localhost:27018 --oplogReplay #恢复数据库【恢复mongorestore同级dump目录】
[root@xxx bin]# mongorestore --host 127.0.0.1 --port 27018 --oplogReplay
2021-09-19T23:32:00.114+0800 using default 'dump' directory
2021-09-19T23:32:00.114+0800 preparing collections to restore from
2021-09-19T23:32:00.114+0800 reading metadata for test.test from dump/test/test.metadata.json
2021-09-19T23:32:00.127+0800 restoring test.test from dump/test/test.bson
2021-09-19T23:32:00.402+0800 no indexes to restore
2021-09-19T23:32:00.402+0800 finished restoring test.test (10002 documents)
2021-09-19T23:32:00.402+0800 replaying oplog
2021-09-19T23:32:00.402+0800 done
[root@iZbp18qq1n1pli2wswopjbZ bin]#
mongo:PRIMARY> db.test.count() *1 #查看导入进来的总数（命令行下可直接进行运算666）
100020
分片集备份大致与复制集原理相同，不过存在差异：
应分别为每个片和config备份；
分片集备份不仅要考虑一个分片内的一致性问题，还要考虑分片间的一致性问题，因此每个片要能够恢复到同一时间点
分片集的增量备份更为复杂，各个数据节点时间不一致，每个数据节点很难完全恢复到一个真正的一致时间点上，通常只能做到大致一致，
分片间的数据迁移，当一个片迁移到另一个片时，最终数据到底在哪里取决于config中的元数据，
如果元数据与数据节点之间时间差异正好导致数据实际已经迁移到新分片上，
而元数据仍认为数据在旧分片上，就会导致数据丢失情况发生，虽然概率很小。
要避免该问题，只有定期停止均衡器，只有在均衡器停止期间，增量恢复才能保证正确。
关系型数据库
mysql迁移到文档型数据库mongodb
关系模型转换为json文档模型存储
停止现有基于RDBMS应用，下线应用和数据库，需要较长时间
使用RDBMS数据库导出工具，将数据库表导出到CSV或者JSON
#mysqldump -h127.0.0.1 -uroot -proot test -T /root #把test库导出sql表结构和txt数据csv格式文件到root目录
使用mongoimport将CSV或JSON文件导入到mongodb数据库
#mongoimport -h127.0.0.1 -p27018 -d music -c player --headerline --type=csv /root/mysql/player.txt
#mongoimport --db users --collection contacts --type csv --file data.csv --fields "name","surname","etc"
通过工具批量同步，实时同步，应用主导迁移（应用请求过来判断mongodb是否存在该记录，没有就从rdbms同步过来）
数据迁移方式对比：
| 方法 | 技术实现方式 | 特点 | 适用场景 |
|---|---|---|---|
| 数据库导入导出 | 数据库自带工具，自己编写脚本 | 简单方便，一次迁移全部数据 | 基于已有数据的新应用 旧应用更新换代 采用重写方式 |
| 批量同步 | Talend/Pentaho/脚本程序 | 适用SQL，批量查询需要数据，写到目标端，无需代码开发 | |
| 实时同步 | Informatica/Tapdata/Oracle Golden Gate | 基于数据库日志解析并实时写入到目标端，准实时同步，无需代码开发 | 无缝切换，旧应用不下线，和新应用并存 主机下行 关系库加速 实时数据平台 |
| 应用迁移 | 在已有应用增加mongodb支持 | 需要较多开发和测试支持 | 旧应用更新换代，采用修改升级原有应用方式 |
关系型数据库运行遇到性能瓶颈，直接替换这些业务难度大，风险高。使用实时同步工具，将数据同步到mongodb，快速构建新应用，是一种低风险高成效的应用模式。
Tapdata Agent 支持各种数据库秒级同步，多表合一能力。
同步时，可以根据关系模型表之间的关系，拖拽实现关联生成文档模型而不用写代码。当数据同步后，更改了关系型数据库内容，也会实时同步到文档型数据库中。
问题诊断工具
mongostat用于了解mongodb运行状态;mongotop用于了解集合压力状态
问题诊断：mongod日志分析，python工具mtools可将所有慢日志查询通过图表形式展现，总结出所有慢查询模式出现次数消耗时间等。安装：pip install mtools
db.serverStatus() #上次开机到现在的监控数据
connections:连接数信息
locks：锁使用情况
network：网络使用情况
opcounters：crud执行次数统计
repl：复制集配置信息
wiredTiger:包含大量wirdTiger执行信息
mem：内存使用情况
metrics：一系列性能指标统计信息
...
db.isMaster() #次要
db.stats() #整个实例数据总量
mongostat localhost:27018 #只有部分信息
网友评论