如果对数据实时性有要求，可以考虑VPN拨入远程网络，然后在本地建立一个secondary，这样可以一直保持数据最新。

首先对于攻击索要赎金的做法请一定say no！不与恐怖分子讨价还价。绝大部分时候他们根本不会复制你的数据，只是直接删除了而已，除非你是一个非常有钱的公司，你的数据非常有价值。如果不是，他基本上只是通过脚本大范围扫描到没有开启密码验证的服务器，直接删除并且发邮件索要赎金。道理很简单，在他扫描的大量服务器中，如果他都做了备份才来要钱，把数据从你这搬到他那要多少时间？如果在这期间被人发现网络流量异常而紧急关闭，他可能来不及删除数据非没有办法索要赎金。再说，如果你的监控比较完备，就可以知道数据被复制到哪里去了，这对黑客来说可能是一个威胁。且不用说他还很可能要为这个备份空间付费（如果是偷来的空间他就没有办法保证备份数据的安全，那你就更没有必要去买回来），这样的亏本生意谁做？

各种理由都表明，不要为此付费，没有意义。

看起来只是日期格式的问题。试一下yyyy-MM-dd的格式呢？

首先一个是关系数据，一个是非关系数据，直接把前者同步到后者虽然可以办到，但是几乎可以确定这样在性能上是会有很大问题的。所以第一点要注意的是，在保持同步的过程中，一定是有一个模型转换的工作。

然后，同步过程肯定可以通过自己编写代码来实现，这也是最为灵活的做法，但是很多人可能无法接受自己写代码所带来的工作量及稳定性要求（比如网络中断了一会怎么办？如何重试？），所以会有一些工具来帮助做这些事情。取决于对实时性要求，可以选择ETL工具和CDC工具。前者比较常用的有Kettle/Pentaho，后者有Tungsten，以及一些特定数据库专用的工具比如GoldenGate。

以工具为例，大致说一下工作原理（如果自己实现也是类似的原理）：

ETL工具

通常要求需要同步的表有一个最后更新字段（如果没有可以通过触发器加上，基本没有额外工作量），ETL工具会定期访问需要同步的表，找出上次同步之后有过更新的行，并把这些行同步到MongoDB中，最后更新自己的最后同步时间。原理应该比较简单。

CDC工具

相较于ETL工具，如果有更高的实时性要求，定期查表可能就不足以满足需求了，所以CDC工具的思路是跟踪关系数据库的bin log，一旦有更新就马上同步到MongoDB中去。但是这就要求CDC工具能够识别并解析不同数据库的bin log，商用数据库很多并不会公开自己的bin log格式是怎么样的，虽然也有开源项目尝试解析这些log并给出开源实现，但是毕竟不是官方实现，稳定性方面要差一些。

目前没有支持这样做

这里的 “热备份”和“冷备份”并没有准确的官方定义，所以我要了解到底是怎么定义这两个概念的才好继续说明。

有可能在插入已有集合时使用的是以前预分配的空间，或者文档删除后重复利用空间，而新集合需要重新分配空间所以会失败。先查一下磁盘空间：

df -h

其实这是一个跟MongoDB没有直接关系的问题。NodeJS中需要等待的操作都是异步的，特别是出现了I/O的部分（包括磁盘、网络I/O）一般来说都是异步的。

很显然，find()在实际获取数据的那一刻，也就是forEach的时候肯定是需要等待数据库，所以：

function(doc){
    list.push(doc);
}

是会在另外一个时刻（数据准备就绪时）被唤醒并执行的，而callback(list)则会马上被执行，所以callback的时候list仍然是[]。

如果这个查询的结果不是很大，可以考虑:

cursor.toArray(function(err, docs) {
    if (err) throw err;
    callback(docs);
});

同时注意大部分时候callback的签名都是function(err, doc)，所以你那个签名可能会得到一堆null，因为第一个参数是err，一般都是null。

肯定有弊端，任何数据库使用IN都不是好的选择，这相当于n个or，每个都需要一次独立的查询。

RDBMS中一般是用JOIN来避免使用IN。MongoDB中如果出现了IN一个很大的列表的问题，一般问题出在模型设计，或者不合理的需求上。还需要知道具体的问题才好分析。

首先确定一下账户有没有问题。

另外需要注意不要用旧版本的GUI连接新版本的MongoDB。3.0开始支持scram-sha-1的认证，旧的GUI来连接一定会出现Authentication Failed。特别是MongoVUE已经停止维护很久了，最后一个版本也是与MongoDB 3.0不兼容的。Robomongo下载最新版本即可。