作者回复: 这个就是RPO指标决定的。Recovery Point Objective. 如果是定期备份,你的RPO就是你的备份间隔时间,比如说24小时。这样的话你由可能丢失24小时的数据。 如果你希望RPO最小化,就要启用实时备份oplog的方式。MongoDB官方提供OpsManager可以实现,数据可以恢复到故障之前一分钟。 然后,一般需要恢复的场景不是宕机。宕机这种比较常见的场景在MongoDB里面是通过复制集来解决的。一个节点宕机不影响业务,重启就好了。 备份恢复通常是出现一些数据问题,比如说,有人删库跑路。
作者回复: oplog是有幂等性的。回放的时候,t1 的数据+oplog的一条,合在一起,还是一条。
作者回复: 集群不会丢失数据,但是你的延迟节点会出现故障,无法工作。
作者回复: 需要提供更多信息排查 - show dbs 输出 - dump 命令 - restore 命令 - restore 以后的show dbs
作者回复: 有影响。延迟节点是一个数据节点,会响应writeConcern。只不过它一定要过了slaveDelay的时间段才会写数据,响应。所以如果你在一个3节点复制集群使用writeConcern:3 ,其中有一个是延迟30分钟的话,你可能要等30分钟才能返回。