mongodb - 边写边转储

Question

针对每秒写入很多的正在运行的服务器运行 mongodump 是否安全？是否有可能以这种方式获得损坏的转储？

来自 here :

Use --oplog to capture incoming write operations during the mongodump operation to ensure that the backups reflect a consistent data state.

是不是说无论写入多少次数据库dump都会保持一致？

如果我在凌晨 1 点运行 mongodump --oplog 并在凌晨 2 点完成，然后我运行 mongorestore --oplogReplay 我会得到什么状态？

来自 here :

However, the use of mongodump and mongorestore as a backup strategy can be problematic for sharded clusters and replica sets.

但是为什么？我有 1 个主要副本集和 2 个辅助副本集。针对次要之一运行 mongodump 有什么问题？它应该与主要相同(除了复制滞后差异)。

Answer 1

docs对此很清楚:

--oplog

Creates a file named oplog.bson as part of the mongodump output. The oplog.bson file, located in the top level of the output directory, contains oplog entries that occur during the mongodump operation. This file provides an effective point-in-time snapshot of the state of a mongod instance. To restore to a specific point-in-time backup, use the output created with this option in conjunction with mongorestore --oplogReplay.

Without --oplog, if there are write operations during the dump operation, the dump will not reflect a single moment in time. Changes made to the database during the update process can affect the output of the backup.

--oplog has no effect when running mongodump against a mongos instance to dump the entire contents of a sharded cluster. However, you can use --oplog to dump individual shards.

如果没有 --oplog，您仍然会得到一个有效的转储，只是有点不一致——一些在凌晨 1 点到凌晨 2 点之间完成的写入将会丢失。

使用 --oplog，您可以在凌晨 2 点捕获 oplog 文件。转储仍然不一致，在恢复时重放操作日志修复了这个问题。

转储分片集群的问题值得 dedicated page in the docs .本质上是因为同步所有节点的备份很复杂:

To create backups of a sharded cluster, you will stop the cluster balancer, take a backup of the config database, and then take backups of each shard in the cluster using mongodump to capture the backup data. To capture a more exact moment-in-time snapshot of the system, you will need to stop all application writes before taking the filesystem snapshots; otherwise the snapshot will only approximate a moment in time.

转储副本集没有问题。