Comment on page
MongoDB备份方法
在本页
当在生产环境中部署 MongoDB 时,应该制定一种策略,以备在发生数据丢失事件时捕获和还原备份。
MongoDB 官方云服务 MongoDB Atlas 提供2种完全托管的备份方法
MongoDB Cloud Manager 是针对 MongoDB 的托管备份,监控和自动化服务。MongoDB Cloud Manager 支持用户在图形化界面操作备份和还原 MongoDB 副本集和分片集群.
提示
使用其他 MongoDB 备份方法很难实现分片群集快照。
要开始使用 MongoDB Cloud Manager 备份,请注册 MongoDB Cloud Manager。有关 MongoDB Cloud Manager 的文档,请参阅 MongoDB Cloud Manager 的文档。
借助 Ops Manager,MongoDB 用户可以在自己的基础架构上安装和运行驱动 MongoDB Cloud Manager 的相同核心软件。Ops Manager 是一种本地解决方案,具有与 MongoDB Cloud Manager 相似的功能,可与订阅的企业版高级功能一起使用。
For more information about Ops Manager, see the MongoDB Enterprise Advanced page and the Ops Manager Manual.
使用 AES256-GCM 的加密存储引擎的注意事项
- 从热备份还原
- 从冷备份还原从4.2开始, 为了避免从冷的文件系统快照还原后重新使用密钥,MongoDB 添加了一个新的命令行选项
--eseDatabaseKeyRollover
. 使用--eseDatabaseKeyRollover
选项启动,mongod
实例将回滚使用AES256-GCM
密码配置的数据库密钥,然后退出。
提示
- In general, if using filesystem based backups for MongoDB Enterprise 4.2+, use the “hot” backup feature, if possible.
- 通常,如果对 MongoDB Enterprise 4.2+ 使用基于文件系统的备份,情尽可能使用“热”备份功能。
- For MongoDB Enterprise versions 4.0 and earlier, if you use
AES256-GCM
encryption mode, do not make copies of your data files or restore from filesystem snapshots (“hot” or “cold”). - 对于 MongoDB Enterprise 4.0 及更早版本,如果您使用
AES256-GCM
加密模式,请不要复制数据文件或从文件系统快照(“热”或“冷”)还原。
您可以通过复制MongoDB的基础数据文件来创建MongoDB部署的备份。
如果 MongoDB 存储数据文件的卷支持时间点快照,则可以使用这些快照在确切的时间创建 MongoDB 系统的备份。文件系统快照是操作系统卷管理器功能,并非特定于 MongoDB。借助文件系统快照,操作系统可以获取卷的快照以用作数据备份的基准。快照的机制取决于基础存储系统。例如,在 Linux 上,逻辑卷管理器(LVM)可以创建快照。同样,Amazon 的 EC2 EBS 存储系统支持快照。
要获取正在运行的 mongod 进程的正确快照,您必须启用日记功能,并且日记必须与其他MongoDB 数据文件位于同一逻辑卷上。如果未启用日记功能,则无法保证快照将保持一致或有效。
mongodump
从 MongoDB 数据库读取数据,并创建高保真 BSON 文件,该 mongorestore
工具可用于填充 MongoDB 数据库。 mongodump
和 mongorestore
是用于备份和还原小型 MongoDB 部署的简单高效的工具,但是对于捕获大型系统的备份而言并不是理想的选择。应用程序可以在
mongodump
捕获输出的同时继续修改数据,对于副本集,当进行mongodump
操作时,mongodump
提供 --oplog
选项来包括它输出的oplog 实体。这允许响应的mongorestore
恢复捕获的 oplog。要恢复创建时带了--oplog
选项的备份,进行mongorestore
操作是需要有 --oplogReplay
选项。注意
对于具有正在进行的分片事务的 4.2+ 版本分片集群,请使用以下一个协调的备份和还原过程,这些过程_确实维护_了跨分片事务的原子性保证:
译者:谢伟成
最近更新 2yr ago