Database Manual / Self-Managed Deployments / Administration / Backup Methods / Restore Sharded Clusters

Back Up a Self-Managed Sharded Cluster with File System Snapshots使用文件系统快照备份自我管理的分片群集

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 mongod is running), MongoDB can detect "dirty" keys on startup and automatically rollover the database key to avoid IV (Initialization Vector) reuse.从4.2开始,如果您从通过“热”备份(即mongod正在运行)获取的文件进行还原,MongoDB可以在启动时检测“脏”键,并自动滚动数据库键以避免IV(初始化向量)重用。
  • Restoring from Cold Backup从冷备份恢复

    However, if you restore from files taken via "cold" backup (i.e. the mongod is 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 --eseDatabaseKeyRollover. 从4.2开始,为了避免从冷文件系统快照恢复后重用键,MongoDB添加了一个新的命令行选项--eseDatabaseKeyRolloverWhen started with the --eseDatabaseKeyRollover option, the mongod instance rolls over the database keys configured with AES256-GCM cipher 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),则不可能使用平台的快照工具在所有磁盘上获得一致的状态。作为替代方案,您可以执行以下操作之一:

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 fsync and fsyncUnlock commands can run on mongos to lock and unlock a sharded cluster.从MongoDB 7.1开始(从7.0.2、6.0.11和5.0.22开始也可用),fsyncfsyncUnlock命令可以在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 directShardOperations role to perform maintenance operations that require you to execute commands directly against a shard.从MongoDB 8.0开始,您可以使用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:要对分片群集进行自我管理备份,请完成以下步骤:

1

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.有关更多信息,请参阅自我管理分片群集的计划备份窗口

2

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);
}
3

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字段返回truefsyncUnlocked字段返回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 } ]
4

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.要创建配置服务器的文件系统快照,请按照创建快照中的过程进行操作

5

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.使用使用文件系统快照备份和还原自我管理部署中的过程,对每个分片的主要成员执行文件系统快照。

6

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字段返回falsefsyncUnlocked字段返回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 } ]
7

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