Restore a Sharded Cluster恢复分片群集

On this page本页内容

This procedure restores a sharded cluster from an existing backup snapshot, such as LVM snapshots. 此过程从现有备份快照(如LVM快照)恢复分片群集。The source and target sharded cluster must have the same number of shards. 源分片群集和目标分片群集的分片数必须相同。For information on creating LVM snapshots for all components of a sharded cluster, see Back Up a Sharded Cluster with File System Snapshots.有关为分片群集的所有组件创建LVM快照的信息,请参阅使用文件系统快照备份分片群集

Note注意

mongodump and mongorestorecannot be part of a backup strategy for 4.2+ sharded clusters that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.对于正在进行分片事务的4.2+分片集群,mongodump和MongoRestore不能作为备份策略的一部分,因为使用mongodump创建的备份无法维持跨分片事务的原子性保证。

For 4.2+ sharded clusters with in-progress sharded transactions, use one of the following coordinated backup and restore processes which do maintain the atomicity guarantees of transactions across shards:对于具有进行中分片事务的4.2+分片群集,请使用以下协调的备份和恢复过程之一,这些过程确实维护了跨分片事务的原子性保证:

For MongoDB 4.0 and earlier deployments, refer to the corresponding versions of the manual. For example:有关MongoDB 4.0及更早版本的部署,请参阅手册的相应版本。例如:

Considerations考虑因素

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密码配置的数据库密钥并退出。

Tip提示
  • 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 versions 4.0及更早版本,如果使用AES256-GCM加密模式,请勿复制数据文件或从文件系统快照进行恢复(“热”或“冷”)。

A. (Optional) Review Replica Set Configurations(可选)查看副本集配置

This procedure initiates a new replica set for the Config Server Replica Set (CSRS) and each shard replica set using the default configuration. 此过程使用默认配置为配置服务器副本集(CSR)和每个分片副本集启动一个新的副本集。To use a different replica set configuration for your restored CSRS and shards, you must reconfigure the replica set(s).要为恢复的CSR和分片使用不同的副本集配置,必须重新配置副本集。

If your source cluster is healthy and accessible, connect a mongo shell to the primary replica set member in each replica set and run rs.conf() to view the replica configuration document.如果源集群正常且可访问,请将mongo shell连接到每个副本集中的主副本集成员,然后运行rs.conf()以查看副本配置文档。

If you cannot access one or more components of the source sharded cluster, please reference any existing internal documentation to reconstruct the configuration requirements for each shard replica set and the config server replica set.如果无法访问源分片群集的一个或多个组件,请参考任何现有的内部文档,以重新构建每个分片副本集和配置服务器副本集的配置要求。

B. Prepare the Target Host for Restoration准备目标主机进行恢复

Storage Space Requirements存储空间要求
Ensure the target host hardware has sufficient open storage space for the restored data. 确保目标主机硬件有足够的开放存储空间来存储还原的数据。If the target host contains existing sharded cluster data that you want to keep, ensure that you have enough storage space for both the existing data and the restored data.如果目标主机包含要保留的现有分片群集数据,请确保有足够的存储空间存储现有数据和恢复的数据。
LVM Requirements
For LVM snapshots, you must have at least one LVM managed volume group and an a logical volume with enough free space for the extracted snapshot data.对于LVM快照,必须至少有一个LVM受管卷组和一个逻辑卷,该逻辑卷具有足够的可用空间来存放提取的快照数据。
MongoDB Version RequirementsMongoDB版本要求

Ensure the target host and source host have the same MongoDB Server version. 确保目标主机和源主机具有相同的MongoDB服务器版本。To check the version of MongoDB available on a host machine, run mongod --version from the terminal or shell.要检查主机上可用的MongoDB版本,请从终端或shell运行mongod --version

For complete documentation on installation, see Install MongoDB.有关安装的完整文档,请参阅安装MongoDB

Shut Down Running MongoDB Processes关闭运行MongoDB进程

If restoring to an existing cluster, shut down the mongod or mongos process on the target host.如果恢复到现有群集,请关闭目标主机上的mongodmongos进程。

For hosts running mongos, connect a mongo shell to the mongos and run db.shutdownServer() from the admin database:对于运行mongos的主机,将mongo shell连接到mongos,并从管理数据库运行db.shutdownServer()

use admin
db.shutdownServer()

For hosts running a mongod, connect a mongo shell to the mongod and run db.hello():对于运行mongod的主机,将MongoShell连接到mongod并运行db.hello()

Prepare Data Directory准备数据目录

Create a directory on the target host for the restored database files. 在目标主机上为还原的数据库文件创建目录。Ensure that the user that runs the mongod has read, write, and execute permissions for all files and subfolders in that directory:确保运行mongod的用户对该目录中的所有文件和子文件夹具有读取、写入和执行权限:

sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb

Substitute /path/to/mongodb with the path to the data directory you created. 用创建的数据目录的路径替换/path/to/mongodbOn RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.在RHEL/CentOS、Amazon Linux和SUSE上,默认用户名是mongod

Prepare Log Directory准备日志目录

Create a directory on the target host for the mongod log files. 在目标主机上为mongod日志文件创建一个目录。Ensure that the user that runs the mongod has read, write, and execute permissions for all files and subfolders in that directory:确保运行mongod的用户对该目录中的所有文件和子文件夹具有读取、写入和执行权限:

sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs

Substitute /path/to/mongodb/logs with the path to the log directory you created. 用您创建的日志目录的路径替换/path/to/mongodb/logsOn RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.在RHEL/CentOS、Amazon Linux和SUSE上,默认用户名是mongod

Create Configuration File创建配置文件

This procedure assumes starting a mongod with a configuration file.此过程假定使用配置文件启动mongod

Create the configuration file in your preferred location. 在首选位置创建配置文件。Ensure that the user that runs the mongod has read and write permissions on the configuration file:确保运行mongod的用户对配置文件具有读写权限:

sudo touch /path/to/mongod.conf
sudo chown mongodb:mongodb /path/to/mongodb/mongod.conf
sudo chmod 644 /path/to/mongodb/mongod.conf

On RHEL / CentOS, Amazon Linux, and SUSE, the default username is mongod.在RHEL/CentOS、Amazon Linux和SUSE上,默认用户名是mongod

Open the configuration file in your preferred text editor and modify at it as required by your deployment. 在首选文本编辑器中打开配置文件,并根据部署的需要进行修改。Alternatively, if you have access to the original configuration file for the mongod, copy it to your preferred location on the target host.或者,如果您可以访问mongod的原始配置文件,请将其复制到目标主机上的首选位置。

Important重要

Validate that your configuration file includes the following settings:验证配置文件是否包含以下设置:

  • storage.dbPath must be set to the path to your preferred data directory.必须设置为首选数据目录的路径。
  • systemLog.path must be set to the path to your preferred log directory必须设置为首选日志目录的路径
  • net.bindIp must include the IP address of the host machine.必须包括主机的IP地址。
  • replication.replSetName has the same value across each member in any given replica set.在任何给定副本集中的每个成员上具有相同的值。
  • sharding.clusterRole has the same value across each member in any given replica set.在任何给定副本集中的每个成员上具有相同的值。

C. Restore Config Server Replica Set恢复配置服务器副本集

1

Restore the CSRS primary mongod data files.恢复CSRS主mongod数据文件。

Select the tab that corresponds to your preferred backup method:选择与首选备份方法对应的选项卡:

  1. Mount the LVM snapshot on the target host machine. The specific steps for mounting an LVM snapshot depends on your LVM configuration.

    The following example assumes an LVM snapshot created using the Create a Snapshot step in the Back Up and Restore with Filesystem Snapshots procedure.

    lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
    gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
    mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb

    This example may not apply to all possible LVM configurations. Refer to the LVM documentation for your system for more complete guidance on LVM restoration.

  2. Copy the mongod data files from the snapshot mount to the data directory created in B. Prepare the Target Host for Restoration:

    cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb

    The -a option recursively copies the contents of the source path to the destination path while preserving folder and file permissions.

  3. Comment out or omit the following configuration file settings:

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr

    To start the mongod using a configuration file, specify the --config option in the command line specifying the full path to the configuration file:

    mongod --config /path/to/mongodb/mongod.conf

    If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.

    After the mongod starts, connect to it using the mongo shell.

  1. Make the data files stored in your selected backup medium accessible on the host. This may require mounting the backup volume, opening the backup in a software utility, or using another tool to extract the data to disk. Refer to the documentation for your preferred backup tool for instructions on accessing the data contained in the backup.

  2. Copy the mongod data files from the backup data location to the data directory created in B. Prepare the Target Host for Restoration:

    cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb

    The -a option recursively copies the contents of the source path to the destination path while preserving folder and file permissions.

  3. Comment out or omit the following configuration file settings:

    #replication
    #  replSetName: myCSRSName
    #sharding
    #  clusterRole: configsvr
  4. To start the mongod using a configuration file, specify the --config option in the command line specifying the full path to the configuration file:

    mongod --config /path/to/mongodb/mongod.conf
    Note注意

    Cloud Manager or Ops Manager Only

    If performing a manual restoration of a Cloud Manager or Ops Manager backup, you must specify the disableLogicalSessionCacheRefresh server parameter prior to startup.

    mongod --config /path/to/mongodb/mongod.conf \
      --setParameter disableLogicalSessionCacheRefresh=true

    If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.

    After the mongod starts, connect to it using the mongo shell.

2

Drop the local database.删除local数据库。

Use db.dropDatabase() to drop the local database:使用db.dropDatabase()删除local数据库:

use local
db.dropDatabase()
3

For any planned or completed shard hostname or replica set name changes, update the metadata in config.shards .对于任何计划或完成的分片主机名或副本集名称更改,请更新config.shards中的元数据。

You can skip this step if all of the following are true:如果满足以下所有条件,则可以跳过此步骤:

  • No shard member host machine hostname has or will change during this procedure.在此过程中,没有或不会更改分片成员主机名。
  • No shard replica set name has or will change during this procedure.在此过程中,分片复制集名称没有或将不会更改。

Issue the following find() method on the shards collection in the Config Database. 配置数据库中的shards集合发出以下find()方法。Replace <shardName> with the name of the shard. 用分片的名称替换<shardName>By default the shard name is its replica set name. 默认情况下,分片名称是其副本集名称。If you added the shard using the addShard command and specified a custom name, you must specify that name to <shardName>.如果使用addShard命令添加了shard并指定了自定义name,则必须将该名称指定给<shardName>

use config
db.shards.find( { "_id" : "<shardName>" } )

This operation returns a document that resembles the following:此操作将返回一个类似于以下内容的文档:

{
   "_id" : "shard1",
   "host" : "myShardName/alpha.example.net:27018,beta.example.net:27018,charlie.example.net:27018",
   "state" : 1
}
Important重要

The _id value must match the shardName value in the _id : "shardIdentity" document on the corresponding shard. _id值必须与相应shard上的_id : "shardIdentity"文档中的shardName值匹配。When restoring the shards later in this procedure, validate that the _id field in shards matches the shardName value on the shard.在本过程稍后恢复分片时,请验证shards中的_id字段是否与分片上的shardName值匹配。

Use the updateOne() method to update the hosts string to reflect the planned replica set name and hostname list for the shard. 使用updateOne()方法更新hosts字符串,以反映分片的计划副本集名称和主机名列表。For example, the following operation updates the host connection string for the shard with "_id" : "shard1":例如,以下操作会使用"_id" : "shard1"更新分片的host连接字符串:

db.shards.updateOne(
  { "_id" : "shard1" },
  { $set : { "host" : "myNewShardName/repl1.example.net:27018,repl2.example.net:27018,repl3.example.net:27018" } }
)

Repeat this process until all shard metadata accurately reflects the planned replica set name and hostname list for each shard in the cluster.重复此过程,直到所有分片元数据准确反映集群中每个分片的计划副本集名称和主机名列表。

Note注意

If you do not know the shard name, issue the find() method on the shards collection with an empty filter document {}:如果不知道分片名称,请在shards集合上使用空筛选文档{}发出find()方法:

use config
db.shards.find({})

Each document in the result set represents one shard in the cluster. 结果集中的每个文档代表集群中的一个分片。For each document, check the host field for a connection string that matches the shard in question, i.e. a matching replica set name and member hostname list. 对于每个文档,检查host字段是否有与所讨论的分片匹配的连接字符串,即匹配的副本集名称和成员主机名列表。Use the _id of that document in place of <shardName>.使用该文档的_id代替<shardName>

4

Restart the mongod as a new single-node replica set.作为新的单节点副本集重新启动mongod

Shut down the mongod. 关闭mongodUncomment or add the following configuration file options:取消注释或添加以下配置文件选项:

replication
  replSetName: myNewCSRSName
sharding
  clusterRole: configsvr

If you want to change the replica set name, you must update the replSetName field with the new name before proceeding.如果要更改副本集名称,必须先用新名称更新replSetName字段,然后才能继续。

Start the mongod with the updated configuration file:使用更新的配置文件启动mongod

mongod --config /path/to/mongodb/mongod.conf

If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.如果已将mongod配置为作为系统服务运行,请使用系统服务管理器建议的流程启动它。

After the mongod starts, connect to it using the mongo shell.mongod启动后,使用mongo shell连接到它。

5

Initiate the new replica set.启动新的副本集。

Initiate the replica set using rs.initiate() with the default settings.使用带有默认设置的rs.initiate()启动副本集。

rs.initiate()

Once the operation completes, use rs.status() to check that the member has become the primary.操作完成后,使用rs.status()检查成员是否已成为主要成员。

6

Add additional replica set members.添加其他副本集成员。

For each replica set member in the CSRS, start the mongod on its host machine. 对于CSR中的每个副本集成员,在其主机上启动mongodOnce you have started up all remaining members of the cluster successfully, connect a mongo shell to the primary replica set member. 成功启动集群的所有剩余成员后,将mongo shell连接到主副本集成员。From the primary, use the rs.add() method to add each member of the replica set. 在主副本中,使用rs.add()方法添加副本集的每个成员。Include the replica set name as the prefix, followed by the hostname and port of the member's mongod process:包括副本集名称作为前缀,后跟成员mongod进程的主机名和端口:

rs.add("config2.example.net:27019")
rs.add("config3.example.net:27019")

If you want to add the member with specific replica member configuration settings, you can pass a document to rs.add() that defines the member hostname and any members settings your deployment requires.如果要添加具有特定副本成员配置设置的成员,可以将定义members主机名和部署所需的任何成员设置的文档传递给rs.add()

rs.add(
 {
   "host" : "config2.example.net:27019",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

Each new member performs an initial sync to catch up to the primary. 每个新成员执行一次初始同步,以赶上主要成员。Depending on factors such as the amount of data to sync, your network topology and health, and the power of each host machine, initial sync may take an extended period of time to complete.根据需要同步的数据量、网络拓扑和运行状况以及每台主机的功率等因素,初始同步可能需要较长的时间才能完成。

The replica set may elect a new primary while you add additional members. 在添加其他成员时,副本集可能会选择一个新的主副本。Use rs.status() to identify which member is the current primary. 使用rs.status()标识哪个成员是当前主成员。You can only run rs.add() from the primary.只能从主服务器运行rs.add()

7

Configure any additional required replication settings.配置任何其他必需的复制设置。

The rs.reconfig() method updates the replica set configuration based on a configuration document passed in as a parameter. rs.reconfig()方法根据作为参数传入的配置文档更新副本集配置。You must run reconfig() against the primary member of the replica set.必须对复制集的主要成员运行reconfig()

Reference the original configuration file output of the replica set as identified in step A. Review Replica Set Configurations and apply settings as needed.参考步骤“A.查看副本集配置并根据需要应用设置”中确定的副本集的原始配置文件输出。

D. Restore Each Shard Replica Set恢复每个分片副本集

1

Restore the shard primary mongod data files.还原分片主mongod数据文件。

Select the tab that corresponds to your preferred backup method:选择与首选备份方法对应的选项卡:

  1. Mount the LVM snapshot on the target host machine. The specific steps for mounting an LVM snapshot depends on your LVM configuration.

    The following example assumes an LVM snapshot created using the Create a Snapshot step in the Back Up and Restore with Filesystem Snapshots procedure.

    lvcreate --size 250GB --name mongod-datafiles-snapshot vg0
    gzip -d -c mongod-datafiles-snapshot.gz | dd o/dev/vg0/mongod-datafiles-snapshot
    mount /dev/vg0/mongod-datafiles-snapshot /snap/mongodb

    This example may not apply to all possible LVM configurations. Refer to the LVM documentation for your system for more complete guidance on LVM restoration.

  2. Copy the mongod data files from the snapshot mount to the data directory created in B. Prepare the Target Host for Restoration:

    cp -a /snap/mongodb/path/to/mongodb /path/to/mongodb

    The -a option recursively copies the contents of the source path to the destination path while preserving folder and file permissions.

  3. Comment out or omit the following configuration file settings:

    #replication
    #  replSetName: myShardName
    #sharding
    #  clusterRole: shardsvr

    To start the mongod using a configuration file, specify the --config option in the command line specifying the full path to the configuration file:

    mongod --config /path/to/mongodb/mongod.conf

    If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.

    After the mongod starts, connect to it using the mongo shell.

  1. Make the data files stored in your selected backup medium accessible on the host. This may require mounting the backup volume, opening the backup in a software utility, or using another tool to extract the data to disk. Refer to the documentation for your preferred backup tool for instructions on accessing the data contained in the backup.

  2. Copy the mongod data files from the backup data location to the data directory created in B. Prepare the Target Host for Restoration:

    cp -a /backup/mongodb/path/to/mongodb /path/to/mongodb

    The -a option recursively copies the contents of the source path to the destination path while preserving folder and file permissions.

  3. Comment out or omit the following configuration file settings:

    #replication
    #  replSetName: myShardName
    #sharding
    #  clusterRole: shardsvr
  4. To start the mongod using a configuration file, specify the --config option in the command line specifying the full path to the configuration file:

    mongod --config /path/to/mongodb/mongod.conf
    Note注意

    Cloud Manager or Ops Manager Only

    If performing a manual restoration of a Cloud Manager or Ops Manager backup, you must specify the disableLogicalSessionCacheRefresh server parameter prior to startup:

    mongod --config /path/to/mongodb/mongod.conf \
      --setParameter disableLogicalSessionCacheRefresh=true

    If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.

    After the mongod starts, connect to it using the mongo shell.

2

Create a temporary user with the __system role.创建具有_系统角色的临时用户。

During this procedure you will modify documents in the admin.system.version collection. 在此过程中,您将修改admin.system.version集合中的文档。For clusters enforcing authentication, only the __system role grants permission to modify this collection. 对于强制验证的集群,只有__system角色授予修改此集合的权限。You can skip this step if the cluster does not enforce authentication.如果集群不强制执行身份验证,则可以跳过此步骤。

Warning警告

The __system role entitles its holder to take any action against any object in the database. __system角色使其持有者有权对数据库中的任何对象采取任何操作。This procedure includes instructions for removing the user created in this step. 此过程包括删除此步骤中创建的用户的说明。Do not keep this user active beyond the scope of this procedure.请勿在本程序的范围之外保持此用户的活动状态。

Consider creating this user with the clientSourceauthentication restriction configured such that only the specified hosts can authenticate as the privileged user.考虑在创建此用户时配置clientSource身份验证限制,以便只有指定的主机可以作为权限用户进行身份验证。

  1. Authenticate as a user with the userAdmin role on the admin database or userAdminAnyDatabase role:admin数据库或userAdminAnyDatabase角色上的userAdmin角色的用户身份进行身份验证:

    use admin
    db.auth("myUserAdmin","mySecurePassword")
  2. Create a user with the __system role:创建具有__system角色的用户:

    db.createUser(
      {
        user: "mySystemUser",
        pwd: "<replaceMeWithAStrongPassword>",
        roles: [ "__system" ]
      }
    )

    Passwords should be random, long, and complex to ensure system security and to prevent or delay malicious access.密码应该是随机、长且复杂的,以确保系统安全,防止或延迟恶意访问。

  3. Authenticate as the privileged user:作为权限用户进行身份验证:

    db.auth("mySystemUser","<replaceMeWithAStrongPassword>")
3

Drop the local database.删除local数据库。

Use db.dropDatabase() to drop the local database:使用db.dropDatabase()删除local数据库:

use local
db.dropDatabase()
4

Remove the minOpTimeRecovery document from the admin.system.versions collection.admin.system.versions集合中删除minOpTimeRecovery文档。

To update the sharding internals, issue the following deleteOne() method on the system.version collection in the admin database:要更新分片内部,请对admin数据库中的system.version集合发出以下deleteOne()方法:

use admin
db.system.version.deleteOne( { _id: "minOpTimeRecovery" } )
Note注意

The system.version collection is an internal, system collection. system.version集合是一个内部系统集合。You should only modify it when when given specific instructions like these.只有在得到如下具体说明时,才应该修改它。

5

Optional: For any CSRS hostname or replica set name changes, update shard metadata in each shard's identity document.每个CSD副本的名称或CSD副本的元数据集的更新都是可选的。

You can skip this step if all of the following are true:如果满足以下所有条件,则可以跳过此步骤:

  • The hostnames for any CSRS host did not change during this procedure.在此过程中,任何CSRS主机的主机名都没有更改。
  • The CSRS replica set name did not change during this procedure.在此过程中,CSRS副本集名称没有更改。

The system.version collection on the admin database contains metadata related to the shard, including the CSRS connection string. admin数据库上的system.version集合包含与分片相关的元数据,包括CSRS连接字符串。If either the CSRS name or any member hostnames changed while restoring the CSRS, you must update this metadata.如果在恢复CSR时更改了CSRS名称或任何成员主机名,则必须更新此元数据。

Issue the following find() method on the system.version collection in the admin database:对管理数据库中的system.version集合发出以下find()方法:

use admin
db.system.version.find( {"_id" : "shardIdentity" } )

The find() method returns a document that resembles the following:find()方法返回一个类似于以下内容的文档:

{
  "_id" : "shardIdentity",
  "clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
  "shardName" : "shard1",
  "configsvrConnectionString" : "myCSRSName/alpha.example.net:27019,beta.example.net:27019,charlie.example.net:27019" }

The following updateOne() method updates the document such that the host string represents the most current CSRS connection string:以下updateOne()方法更新文档,使host字符串代表最新的CSRS连接字符串:

db.system.version.updateOne(
  { "_id" : "shardIdentity" },
  { $set :
    { "configsvrConnectionString" : "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"}
  }
)
Important重要

The shardName value must match the _id value in the shards collection on the CSRS. shardName值必须与CSR上shards集合中的_id值匹配。Validate that the metadata on the CSRS match the metadata for the shard. 验证CSR上的元数据是否与分片的元数据匹配。Refer to substep 3 in the C. Restore Config Server Replica Set portion of this procedure for instructions on viewing the CSRS metadata.有关查看CSRS元数据的说明,请参阅本过程“C.恢复配置服务器副本”部分的子步骤3。

6

Restart the mongod as a new single-node replica set.作为新的单节点副本集重新启动mongod

Shut down the mongod. 关闭mongodUncomment or add the following configuration file options:取消注释或添加以下配置文件选项:

replication
  replSetName: myNewShardName
sharding
  clusterRole: shardsvr

If you want to change the replica set name, you must update the replSetName field with the new name before proceeding.如果要更改副本集名称,必须先用新名称更新replSetName字段,然后才能继续。

Start the mongod with the updated configuration file:使用更新的配置文件启动mongod

mongod --config /path/to/mongodb/mongod.conf

If you have mongod configured to run as a system service, start it using the recommended process for your system service manager.如果已将mongod配置为作为系统服务运行,请使用系统服务管理器建议的流程启动它。

After the mongod starts, connect to it using the mongo shell.mongod启动后,使用mongo shell连接到它。

7

Initiate the new replica set.启动新的副本集。

Initiate the replica set using rs.initiate() with the default settings.使用带有默认设置的rs.initiate()启动副本集。

rs.initiate()

Once the operation completes, use rs.status() to check that the member has become the primary.操作完成后,使用rs.status()检查成员是否已成为primary

8

Add additional replica set members.添加其他副本集成员。

For each replica set member in the shard replica set, start the mongod on its host machine. 对于分片副本集中的每个副本集成员,在其主机上启动mongodOnce you have started up all remaining members of the cluster successfully, connect a mongo shell to the primary replica set member. 成功启动集群的所有剩余成员后,将mongo shell连接到主副本集成员。From the primary, use the rs.add() method to add each member of the replica set. 在主副本中,使用rs.add()方法添加副本集的每个成员。Include the replica set name as the prefix, followed by the hostname and port of the member's mongod process:包括副本集名称作为前缀,后跟成员mongod进程的主机名和端口:

rs.add("repl2.example.net:27018")
rs.add("repl3.example.net:27018")

If you want to add the member with specific replica member configuration settings, you can pass a document to rs.add() that defines the member hostname and any members settings your deployment requires.如果要添加具有特定副本member配置设置的成员,可以将定义成员主机名和部署所需的任何members设置的文档传递给rs.add()

rs.add(
 {
   "host" : "repl2.example.net:27018",
   priority: <int>,
   votes: <int>,
   tags: <int>
 }
)

Each new member performs an initial sync to catch up to the primary. 每个新成员执行一次初始同步,以赶上主要成员。Depending on factors such as the amount of data to sync, your network topology and health, and the power of each host machine, initial sync may take an extended period of time to complete.根据需要同步的数据量、网络拓扑和运行状况以及每台主机的功率等因素,初始同步可能需要较长的时间才能完成。

The replica set may elect a new primary while you add additional members. 在添加其他成员时,副本集可能会选择一个新的主副本。Use rs.status() to identify which member is the current primary. 使用rs.status()标识哪个成员是当前主成员。You can only run rs.add() from the primary.只能从主服务器运行rs.add()

9

Configure any additional required replication settings.配置任何其他必需的复制设置。

The rs.reconfig() method updates the replica set configuration based on a configuration document passed in as a parameter. rs.reconfig()方法根据作为参数传入的配置文档更新副本集配置。You must run reconfig() against the primary member of the replica set.必须对复制集的主要成员运行reconfig()

Reference the original configuration file output of the replica set as identified in step A. Review Replica Set Configurations and apply settings as needed.参考步骤“A.查看副本集配置并根据需要应用设置”中确定的副本集的原始配置文件输出。

10

Remove the temporary privileged user.删除临时权限用户。

For clusters enforcing authentication, remove the privileged user created earlier in this procedure:对于强制执行身份验证的群集,请删除在此过程前面创建的权限用户:

  1. Authenticate as a user with the userAdmin role on the admin database or userAdminAnyDatabase role:admin数据库或userAdminAnyDatabase角色上的userAdmin角色的用户身份进行身份验证:

    use admin
    db.auth("myUserAdmin","mySecurePassword")
  2. Delete the privileged user:删除权限用户:

    db.removeUser("mySystemUser")

E. Restart Each mongos重新启动每个mongos

Restart each mongos in the cluster.重新启动群集中的每个mongos

mongos --config /path/to/config/mongos.conf

Include all other command line options as required by your deployment.包括部署所需的所有其他命令行选项。

If the CSRS replica set name or any member hostname changed, update the mongos configuration file setting sharding.configDB with updated configuration server connection string:如果CSRS副本集名称或任何成员主机名发生更改,请使用更新的配置服务器连接字符串更新mongos配置文件设置sharding.configDB

sharding:
  configDB: "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"

F. Validate Cluster Accessibility验证群集可访问性

Connect a mongo shell to one of the mongos processes for the cluster. mongo shell连接到集群的一个mongos进程。Use sh.status() to check the overall cluster status. 使用sh.status()检查整个集群状态。If sh.status() indicates that the balancer is not running, use sh.startBalancer() to restart the balancer. 如果sh.status()指示平衡器未运行,请使用sh.startBalancer()重新启动平衡器。[1]

To confirm that all shards are accessible and communicating, insert test data into a temporary sharded collection. 要确认所有分片都可访问和通信,请将测试数据插入临时分片集合。Confirm that data is being split and migrated between each shard in your cluster. 确认数据正在集群中的每个分片之间拆分和迁移。You can connect a mongo shell to each shard primary and use db.collection.find() to validate that the data was sharded as expected.您可以将mongo shell连接到每个分片primary,并使用db.collection.find()验证数据是否按预期进行了分片。

[1] Starting in MongoDB 4.2, sh.startBalancer() also enables auto-splitting for the sharded cluster.从MongoDB 4.2开始,sh.startBalancer()还为分片集群启用自动拆分。
←  Schedule Backup Window for Sharded ClustersRecover a Standalone after an Unexpected Shutdown →