Overview概述
This document describes a procedure for taking a backup of all components of a sharded cluster. 本文档描述了对分片集群的所有组件进行备份的过程。This procedure uses file system snapshots to capture a copy of the 此过程使用文件系统快照来捕获mongod instance.mongod实例的副本。
Important
To back up a sharded cluster you must stop all writes to the cluster.要备份分片集群,您必须停止对集群的所有写入。
For more information on backups in MongoDB and backups of sharded clusters in particular, see Backup Methods for a Self-Managed Deployment and Backup and Restore a Self-Managed Sharded Cluster.有关MongoDB中的备份,特别是分片集群备份的更多信息,请参阅自我管理部署的备份方法和自我管理分片集群的备份和还原。
Considerations注意事项
Transactions Across Shards跨分片事务
To take a backup with a file system snapshot, you must first stop the balancer, stop writes, and stop any schema transformation operations on the cluster.要使用文件系统快照进行备份,您必须首先停止平衡器,停止写入,并停止集群上的任何架构转换操作。
MongoDB provides backup and restore operations that can run with the balancer and running transactions through the following services:MongoDB提供备份和还原操作,可以与平衡器一起运行,并通过以下服务运行事务:
Encrypted Storage Engine (MongoDB Enterprise Only)加密存储引擎(仅限MongoDB企业版)
For encrypted storage engines that use 对于使用AES256-GCM encryption mode, AES256-GCM requires that every process use a unique counter block value with the key.AES256-GCM加密模式的加密存储引擎,AES256-GCM要求每个进程在键中使用唯一的计数器块值。
For encrypted storage engine configured with 对于配置了AES256-GCM cipher:AES256-GCM密码的加密存储引擎:
-
Restoring from Hot Backup从热备份恢复Starting in 4.2, if you restore from files taken via "hot" backup (i.e. the从4.2开始,如果您从通过“热”备份(即mongodis running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.mongod正在运行)获取的文件进行还原,MongoDB可以在启动时检测“脏”键,并自动滚动数据库键以避免IV(初始化向量)重用。
-
Restoring from Cold Backup从冷备份恢复However, if you restore from files taken via "cold" backup (i.e. the但是,如果您从通过“冷”备份获取的文件中还原(即mongodis not running), MongoDB cannot detect "dirty" keys on startup, and reuse of IV voids confidentiality and integrity guarantees.mongod未运行),MongoDB在启动时无法检测到“脏”键,重复使用IV会使机密性和完整性保证失效。Starting in 4.2, to avoid the reuse of the keys after restoring from a cold filesystem snapshot, MongoDB adds a new command-line option从4.2开始,为了避免从冷文件系统快照恢复后重用键,MongoDB添加了一个新的命令行选项--eseDatabaseKeyRollover.--eseDatabaseKeyRollover。When started with the当使用--eseDatabaseKeyRolloveroption, themongodinstance rolls over the database keys configured withAES256-GCMcipher and exits.--eseDatabaseKeyRollover选项启动时,mongod实例会滚动使用AES256-GCM密码配置的数据库键并退出。
Balancer平衡器
It is essential that you stop the balancer before capturing a backup.在捕获备份之前,必须停止平衡器。
If the balancer is active while you capture backups, the backup artifacts may be incomplete or have duplicate data, as chunks may migrate while recording backups.如果在捕获备份时平衡器处于活动状态,则备份工件可能不完整或具有重复数据,因为块可能会在记录备份时迁移。
Precision精确度
In this procedure, you will stop the cluster balancer and take a backup up of the config database, and then take backups of each shard in the cluster using a file-system snapshot tool. 在此过程中,您将停止集群平衡器并备份配置数据库,然后使用文件系统快照工具备份集群中的每个分片。If you need an exact moment-in-time snapshot of the system, you will need to stop all writes before taking the file system snapshots; otherwise the snapshot will only approximate a moment in time.如果您需要系统的精确时刻快照,则需要在拍摄文件系统快照之前停止所有写入;否则,快照将仅近似于某一时刻。
Consistency一致性
To back up a sharded cluster, you must use the 要备份分片集群,必须使用fsync command or db.fsyncLock() method to stop writes on the cluster. fsync命令或db.fsyncLock()方法停止对集群的写入。This helps reduce the likelihood of inconsistencies in the backup.这有助于降低备份中不一致的可能性。
Note
These steps can only produce a consistent backup if they are followed exactly and no operations are in progress when you begin.只有严格遵循这些步骤,并且在开始时没有进行任何操作,这些步骤才能产生一致的备份。
Snapshots with Amazon EBS in a RAID 10 ConfigurationRAID 10配置中使用Amazon EBS的快照
If your deployment depends on Amazon's Elastic Block Storage (EBS) with RAID configured within your instance, it is impossible to get a consistent state across all disks using the platform's snapshot tool. As an alternative, you can do one of the following:如果部署依赖于在实例中配置了RAID的亚马逊弹性块存储(EBS),则不可能使用平台的快照工具在所有磁盘上获得一致的状态。作为替代方案,您可以执行以下操作之一:
Set a设置fsynclock to flush all writes and lock the cluster against new writes to help reduce the likelihood of an inconsistent state occurring during the backup process.fsync锁以刷新所有写入,并锁定集群以防止新的写入,以帮助降低备份过程中出现不一致状态的可能性。If you choose this option see Back up Instances with Journal Files on Separate Volume or without Journaling.如果选择此选项,请参阅在单独卷上备份具有日记文件的实例或不备份日记。Configure LVM to run and hold your MongoDB data files on top of the RAID within your system.配置LVM以在系统内的RAID顶部运行并保存MongoDB数据文件。If you choose this option, perform the LVM backup operation described in Create a Snapshot.如果选择此选项,请执行创建快照中描述的LVM备份操作。
Version Compatibility版本兼容性
This procedure requires a version of MongoDB that supports fsync locking from 此过程需要一个支持mongos.mongos的fsync锁定的MongoDB版本。
Starting in MongoDB 7.1 (also available starting in 7.0.2, 6.0.11, and 5.0.22) the 从MongoDB 7.1开始(从7.0.2、6.0.11和5.0.22开始也可用),fsync and fsyncUnlock commands can run on mongos to lock and unlock a sharded cluster.fsync和fsyncUnlock命令可以在mongos上运行,以锁定和解锁分片集群。
Stale Data失效数据
Backups provide a snapshot of the current state of the database. When you restore from a backup, the restored database doesn't include any changes made after the backup was taken, which can result in data loss.备份提供数据库当前状态的快照。从备份还原时,还原的数据库不包括备份后所做的任何更改,这可能会导致数据丢失。
Before You Begin开始之前
Starting in MongoDB 8.0, you can use the 从MongoDB 8.0开始,您可以使用directShardOperations role to perform maintenance operations that require you to execute commands directly against a shard.directShardOperations角色执行维护操作,这些操作要求您直接对分片执行命令。
Warning
Running commands using the 使用directShardOperations role can cause your cluster to stop working correctly and may cause data corruption. directShardOperations角色运行命令可能会导致集群停止正常工作,并可能导致数据损坏。Only use the 仅将directShardOperations role for maintenance purposes or under the guidance of MongoDB support. directShardOperations角色用于维护目的或在MongoDB支持的指导下使用。Once you are done performing maintenance operations, stop using the 完成维护操作后,停止使用directShardOperations role.directShardOperations角色。
Steps步骤
To take a self-managed backup of a sharded cluster, complete the following steps:要对分片群集进行自我管理备份,请完成以下步骤:
Find a Backup Window查找备份窗口
Chunk migrations, resharding, and schema migration operations can cause inconsistencies in backups. To find a good time to perform a backup, monitor your application and database usage and find a time when these operations are unlikely to occur.块迁移、重新标记和模式迁移操作可能会导致备份不一致。要找到执行备份的好时机,请监视应用程序和数据库使用情况,并找到不太可能发生这些操作的时间。
For more information, see Schedule Backup Window for a Self-Managed Sharded Cluster.有关更多信息,请参阅自我管理分片群集的计划备份窗口。
Stop the Balancer停止平衡器
To prevent chunk migrations from disrupting the backup, use the 为防止块迁移中断备份,请使用sh.stopBalancer() method to stop the balancer:sh.stopBalancer()方法停止平衡器:
sh.stopBalancer()
If a balancing round is currently in progress, the operation waits for balancing to complete.如果当前正在进行平衡回合,则操作将等待平衡完成。
To verify that the balancer is stopped, use the 要验证平衡器是否已停止,请使用sh.getBalancerState() method:sh.getBalancerState()方法:
use config
while( sh.isBalancerRunning().mode != "off" ) {
print("waiting...");
sleep(1000);
}Lock the Cluster锁定集群
Writes to the database can cause backup inconsistencies. Lock your sharded cluster to protect the database from writes.写入数据库可能会导致备份不一致。锁定分片集群以保护数据库免受写入。
To lock a sharded cluster, use the 要锁定分片集群,请使用db.fsyncLock() method:db.fsyncLock()方法:
db.getSiblingDB("admin").fsyncLock()
Run the following aggregation pipeline on both 在配置服务器的mongos and the primary mongod of the config servers. mongos和主mongod上运行以下聚合管道。To confirm the lock, ensure that the 要确认锁定,请确保fysncLocked field returns true and fsyncUnlocked field returns false.fysncLocked字段返回true,fsyncUnlocked字段返回false。
db.getSiblingDB("admin").aggregate( [
{ $currentOp: { } },
{ $facet: {
"locked": [
{ $match: { $and: [
{ fsyncLock: { $exists: true } }
] } }],
"unlocked": [
{ $match: { fsyncLock: { $exists: false } } }
]
} },
{ $project: {
"fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] },
"fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] }
} }
] )
[ { fsyncLocked: true }, { fsyncUnlocked: false } ]Back up the Primary Config Server备份主配置服务器
Note
Backing up a config server backs up the sharded cluster's metadata. You only need to back up one config server, as they all hold the same data. Perform this step against the CSRS primary member.备份配置服务器会备份分片集群的元数据。您只需要备份一个配置服务器,因为它们都保存相同的数据。对CSRS主要成员执行此步骤。
To create a filesystem snapshot of the config server, follow the procedure in Create a Snapshot.要创建配置服务器的文件系统快照,请按照创建快照中的过程进行操作。
Back up the Primary Shards备份主分片
Perform a filesystem snapshot against the primary member of each shard, using the procedure found in Back Up and Restore a Self-Managed Deployment with Filesystem Snapshots.使用使用文件系统快照备份和还原自我管理部署中的过程,对每个分片的主要成员执行文件系统快照。
Unlock the Cluster解锁集群
After the backup completes, you must unlock the cluster to allow writes to resume.备份完成后,您必须解锁群集以允许继续写入。
To unlock the cluster, use the 要解锁集群,请使用db.fsyncUnlock() method:db.fsyncUnlock()方法:
db.getSibling("admin").fsyncUnlock()
Run the following aggregation pipeline on both 在配置服务器的mongos and the primary mongod of the config servers. mongos和主mongod上运行以下聚合管道。To confirm the unlock, ensure that the 要确认解锁,请确保fysncLocked field returns false and fsyncUnlocked field returns true.fysncLocked字段返回false,fsyncUnlocked字段返回true。
db.getSiblingDB("admin").aggregate( [
{ $currentOp: { } },
{ $facet: {
"locked": [
{ $match: { $and: [
{ fsyncLock: { $exists: true } }
] } }],
"unlocked": [
{ $match: { fsyncLock: { $exists: false } } }
]
} },
{ $project: {
"fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] },
"fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] }
} }
] )
[ { fsyncLocked: false }, { fsyncUnlocked: true } ]Restart the Balancer重新启动平衡器
To restart the balancer, use the 要重新启动平衡器,请使用sh.startBalancer() method:sh.startBalancer()方法:
sh.startBalancer()
To confirm that the balancer is running, use the 要确认平衡器正在运行,请使用sh.getBalancerState() method:sh.getBalancerState()方法:
sh.getBalancerState()
true
The command returns 平衡器运行时,该命令返回true when the balancer is running.true。