精选留言(9)

• 

  xishuai

  老师，除了dump时指定oplog，是不是oplog也要单独备份呢？

  作者回复: dump的话单独备份是不需要的。除非你另有别的用途

  2020-03-12

   1

  
• 

  dream

  老师，请问mysql中的数据怎么迁移到mongodb呢？对于少量数据(100m内) 和 大量数据(几个T) 的处理方式分别是什么呢？
  

  作者回复: 如果是一次性迁移，直接导出到CSV文件然后使用mongoimport命令。100MB或者几个T都是这样。
  
  如果是持续迁移，那需要一些专门的工具，比如说我们公司的tapdata产品。

  2020-01-21

  

  
• 

  Geek_f7ecaa

  在遇到误删除数据需要恢复的到删除时间点的数据时，需要通过OPLOG先找到误操作的时间点，但往往遇到因为oplog往往比较大（生产环境几十、上百G），导致查询和分析OPLOG很慢，恢复效率较低，有没有更高效一些的恢复方法？

  作者回复: 你是如何在查询和分析，可以稍微明确一些吗？

  2020-01-20

  

  
• 

  齐宝金

  请问下老师，副本集集群有通过物理备份+oplog实现任意点的恢复吗，就是类似mysql的innobackupex+binlog的方式，有可参照的案例吗

  作者回复: 可以的，大致步骤是：
  
  1）用snapshot或者关机复制文件方式进行全量备份
  
  2）使用mongodump 备份 oplog 库
  
  3）恢复全量备份
  
  4） 使用 mongorestore 的 --oplogFile --oplogLimit 参数来恢复指定的oplog 时间点
  
  可以参考下面这个英文博客
  https://alexmarquardt.com/2017/01/25/mongodb-point-in-time-restore/
  

  2020-01-11

  

  
• 

  癫狂的小兵

  唐老师你好，想问一个问题。对于单个实例的mongodb, 假设条件1：数据库有10个集合，每个集合的文档数是1亿条记录和假设条件2：数据库只有1个集合,同样拥有1亿条记录，那么对于同样数量级的访问请求 这两个假设条件下性能是否会有不同，影响有多大呢？ 问题主要是想知道，同一实例下，大集合之间会不会有互相影响(不存在聚合查询, 各查各的)

  作者回复: 如果两个情况下，你的请求量是完全一样的，比如说，同样的请求，查的是同一个集合，一样的并发，那么影响不大，因为其他集合的数据只是在硬盘上，不会被调用到内存里。如果你对其他9个集合也有访问，那性能自然就不相同了。

  2020-01-09

  

  
• 

  鲨无赦

  唐老师好，问2个问题：
  1、分片集群下的副本集只有2台机器，一次意外断电导致其中一台系统启动不了，这个副本集也就坏了，如果强制把它从分片集群理彻底删除，现在一直处理【"draining" : true】。
  
  2、用MongoShake从A副本集同步数据到B副本集报错【Size must be between 0 and 16793600(16MB) First element】，2个副本集配置和参数都一样，那报错的这个文档为什么在A副本集写入是成功？

  作者回复: 1） 应该先修复副本集再做删除动作，可以删掉坏掉的那个节点的数据，让它自动恢复数据。
  
  2） 这个要看mongoshake团队，有个钉钉群，你可以搜一下加群问。

  2020-01-08

  

  
• 

  qbit

  另外两种全量备份方式（文件复制、文件快照）后面会讲到吗？

  作者回复: 这两种方式比较简单，一个是复制文件，一个是操作系统命令，就没有特别讲了。

  2020-01-05

  

  
• 

  cheriston

  [root@server22 ~]# mongorestore --host 192.168.127.22:27017 --oplogReplay
  2020-01-03T17:31:36.817+0800 using default 'dump' directory
  2020-01-03T17:31:36.817+0800 preparing collections to restore from
  2020-01-03T17:31:36.818+0800 reading metadata for test.random from dump/test/random.metadata.json
  2020-01-03T17:31:36.819+0800 restoring to existing collection config.cache.chunks.test.random without dropping
  2020-01-03T17:31:36.819+0800 reading metadata for config.cache.chunks.test.random from dump/config/cache.chunks.test.random.metadata.json
  2020-01-03T17:31:36.819+0800 restoring config.cache.chunks.test.random from dump/config/cache.chunks.test.random.bson
  2020-01-03T17:31:36.819+0800 restoring to existing collection config.cache.databases without dropping
  2020-01-03T17:31:36.819+0800 reading metadata for config.cache.databases from dump/config/cache.databases.metadata.json
  2020-01-03T17:31:36.819+0800 restoring to existing collection config.cache.collections without dropping
  2020-01-03T17:31:36.819+0800 reading metadata for config.cache.collections from dump/config/cache.collections.metadata.json
  2020-01-03T17:31:36.820+0800 restoring config.cache.databases from dump/config/cache.databases.bson
  2020-01-03T17:31:36.821+0800 finished restoring test.random (0 documents, 0 failures)
  2020-01-03T17:31:36.821+0800 restoring config.cache.collections from dump/config/cache.collections.bson
  2020-01-03T17:31:36.821+0800 finished restoring config.cache.chunks.test.random (0 documents, 0 failures)
  2020-01-03T17:31:36.822+0800 terminating read on config.cache.databases
  2020-01-03T17:31:36.822+0800 finished restoring config.cache.databases (0 documents, 0 failures)
  2020-01-03T17:31:36.822+0800 terminating read on config.cache.collections
  panic: close of closed channel

  2020-01-03

   1

  
• 

  撑伞也是雨中人。

  老师 分片集群具体如何实施备份？ 停掉均衡器之后，各个节点通过定时任务备份（各个机器启动备份时间点是否能够绝对一致，如果备份时间点存在几秒的差别，是否有致命风险？）

  作者回复: 停掉均衡以后，备份可以保证每个节点各自是准确的。但是各个节点之间时间点很难保证在同一点上，所以每个节点恢复以后那个状态不是完全同步的。这个没有致命风险，但是确实有数据不一致的可能性。如果要做到完全一致，需要使用MongoDB 企业版 Ops Manager的分片备份功能。

  2020-01-02

  

  