还原分片群集
在本页面
Note
以下过程适用于 3.6 分片群集。对于 MongoDB 的早期版本,请参考《 MongoDB 手册》的相应版本。
此过程从现有备份(例如LVM snapshots或database dumps)还原分片群集。源和目标分片群集必须具有相同数量的分片。有关分片群集备份的完整文档,请参见使用数据库转储备份分片群集和使用文件系统快照备份分片群集。
MongoDB Cloud Backups
MongoDB Cloud Services 提供了内置的备份和还原功能,用于自动还原分片群集备份。
有关更多信息,请参见MongoDB Atlas,MongoDB 云 Management 器和MongoDB 运营 Manager。
A.(可选)查看副本集配置
此过程使用默认配置为配置服务器副本集(CSRS)和每个分片副本集启动一个新副本集。要为还原的 CSRS 和分片使用不同的副本集配置,必须重新配置副本集。
如果您的源群集正常且可访问,则将mongo shell 连接到每个副本集中的主副本集成员,然后运行rs.conf()以查看副本配置文档。
如果您无法访问源分片群集的一个或多个组件,请参考任何现有的内部文档,以重构每个分片副本集和配置服务器副本集的配置要求。
B.准备要还原的目标主机
-
储存空间要求
- 确保目标主机硬件具有足够的开放存储空间来存储还原的数据。如果目标主机包含要保留的现有分片群集数据,请确保您有足够的存储空间来容纳现有数据和已还原数据。
-
LVM Requirements
- 对于 LVM 快照,您必须至少有一个 LVMManagement 的卷组和一个逻辑卷,该逻辑卷具有足够的可用空间来存储提取的快照数据。
-
MongoDB 版本要求
- 确保目标主机和源主机具有相同的 MongoDB Server 版本。要检查主机上可用的 MongoDB 版本,请在终端或 Shell 程序上运行
mongod --version
。
- 确保目标主机和源主机具有相同的 MongoDB Server 版本。要检查主机上可用的 MongoDB 版本,请在终端或 Shell 程序上运行
有关安装的完整文档,请参见Install MongoDB。
对于运行mongos的主机,将mongo shell 连接到mongos
并从admin
数据库运行db.shutdownServer():
use admin
db.shutdownServer()
对于运行mongod的主机,将mongo shell 连接到mongod
并运行db.isMaster():
-
如果ismaster为 false,则
mongod
是副本集的secondary成员。您可以通过从admin
数据库运行db.shutdownServer()来关闭它。 -
如果ismaster为 true,则
mongod
是副本集的primary成员。关闭副本集* first *的辅助成员。使用rs.status()标识副本集的其他成员。
主服务器在检测到大多数成员脱机后会自动降级。降级后(db.isMaster返回ismaster: false),您可以安全地关闭mongod
-
准备数据目录
- 在目标主机上为还原的数据库文件创建目录。确保运行mongod的用户具有该目录中所有文件和子文件夹的读取,写入和执行权限:
sudo mkdir /path/to/mongodb
sudo chown -R mongodb:mongodb /path/to/mongodb
sudo chmod -R 770 /path/to/mongodb
用您创建的数据目录的路径替换/path/to/mongodb
。在 RHEL/CentOS,Amazon Linux 和 SUSE 上,默认用户名是mongod
。
sudo mkdir /path/to/mongodb/logs
sudo chown -R mongodb:mongodb /path/to/mongodb/logs
sudo chmod -R 770 /path/to/mongodb/logs
用您创建的日志目录的路径替换/path/to/mongodb/logs
。在 RHEL/CentOS,Amazon Linux 和 SUSE 上,默认用户名是mongod
。
-
创建配置文件
- 此过程假定以mongod和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
在 RHEL/CentOS,Amazon Linux 和 SUSE 上,默认用户名是mongod
。
在首选的文本编辑器中打开配置文件,然后根据部署要求对其进行修改。或者,如果您有权访问mongod的原始配置文件,请将其复制到目标主机上的首选位置。
Important
验证您的配置文件是否包含以下设置:
-
storage.dbPath必须设置为首选数据目录的路径。
-
systemLog.path必须设置为首选日志目录的路径
-
net.bindIp必须包含主机的 IP 地址。
-
replication.replSetName在任何给定副本集中的每个成员中具有相同的值。
-
sharding.clusterRole在任何给定副本集中的每个成员中具有相同的值。
C.还原配置服务器副本集
恢复 CSRS 主 mongod 数据文件。
选择与您的首选备份方法相对应的选项卡:
- 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.
- 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.
- 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.
- 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.
- Use mongorestore to restore the data captured by mongodump into the mongod. If you ran mongodump with --oplog, you must run mongorestore with --oplogReplay to restore the captured oplog entries.
The following operation restores a mongodump dump created with the --gzip, --archive, and --oplog options:
mongorestore --host localhost --port 27017 \
--oplogReplay \
--gzip --archive="/path/to/dump.gz"
Add any additional options as required by your deployment. Change the hostname and port based on the configuration of the target mongod.
-
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.
-
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.
- 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
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.
删除本地数据库。
使用db.dropDatabase()删除local
数据库:
use local
db.dropDatabase()
对于任何计划或已完成的分片主机名或副本集名称更改,请更新 config.shards 中的元数据。
如果满足以下所有条件,则可以跳过此步骤:
-
在此过程中,分片成员主机的主机名均不会更改。
-
在此过程中,分片副本集名称没有更改,也不会更改。
对Config Database中的shards集合发出以下find()方法。将<shardName>
替换为分片的名称。默认情况下,分片名称是其副本集名称。如果使用addShard命令添加了分片并且指定了自定义name
,则必须将name
指定为<shardName>
。
use config
db.shards.find( { "_id" : "<shardName>" } )
此操作返回类似于以下内容的文档:
{
"_id" : "shard1",
"host" : "myShardName/alpha.example.net:27018,beta.example.net:27018,charlie.example.net:27018",
"state" : 1
}
Important
_id
值必须与相应分片上_id : "shardIdentity"
文档中的shardName
值匹配。在此过程后面的还原分片时,请验证shards中的_id
字段与分片上的shardName
值匹配。
使用updateOne()方法更新hosts
字符串以反映计划的分片集名称和分片主机名列表。例如,以下操作使用"_id" : "shard1"
更新分片的host
连接字符串:
db.shards.updateOne(
{ "_id" : "shard1" },
{ $set : { "host" : "myNewShardName/repl1.example.net:27018,repl2.example.net:27018,repl3.example.net:27018" } }
)
重复此过程,直到所有分片元数据准确反映集群中每个分片的计划副本集名称和主机名列表。
Note
将 mongod 重新启动为新的单节点副本集。
Shut down mongod。取消 Comments 或添加以下配置文件选项:
replication
replSetName: myNewCSRSName
sharding
clusterRole: configsvr
如果要更改副本集名称,则必须先使用新名称更新replSetName字段,然后再 continue。
使用更新的配置文件启动mongod:
mongod --config /path/to/mongodb/mongod.conf
如果您已将mongod配置为作为系统服务运行,请使用系统服务 Management 员推荐的过程来启动它。
启动新的副本集。
使用默认设置rs.initiate()初始化副本集。
rs.initiate()
操作完成后,使用rs.status()检查成员是否已成为primary。
添加其他副本集成员。
对于 CSRS 中的每个副本集成员,请在其主机上启动mongod。成功启动群集的所有其余成员后,将mongo shell 连接到主副本集成员。在主数据库中,使用rs.add()方法添加副本集的每个成员。包括副本集名称作为前缀,然后是成员的mongod进程的主机名和端口:
rs.add("config2.example.net:27019")
rs.add("config3.example.net:27019")
如果要添加具有特定副本member
配置设置的成员,则可以将文档传递给rs.add(),该文档定义成员主机名和部署所需的任何members[n]
设置。
rs.add(
{
"host" : "config2.example.net:27019",
priority: <int>,
votes: <int>,
tags: <int>
}
)
每个新成员执行一次initial sync赶上主要成员。根据要同步的数据量,网络拓扑和运行状况以及每台主机的功能等因素,完成初始同步可能需要较长的时间。
当您添加其他成员时,副本集可能会选择一个新的主副本。使用rs.status()标识哪个成员是当前主要成员。您只能从主数据库运行rs.add()。
配置任何其他必需的复制设置。
rs.reconfig()方法基于作为参数传入的配置文档更新副本集配置。您必须对副本集的主要成员运行reconfig()。
参考步骤 A 中标识的副本集的原始配置文件输出。查看副本集配置并根据需要应用设置。
D.恢复每个分片副本集
恢复分片主 mongod 数据文件。
选择与您的首选备份方法相对应的选项卡:
- 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.
- Copy the mongod data files from the snapshot mount to the data directory created in B. Prepare the Target Host for Restoration:
c -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.
- 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.
- 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.
- Use mongorestore to restore the data captured by mongodump into the mongod. If you ran mongodump with --oplog, you must run mongorestore with --oplogReplay to restore the captured oplog entries.
The following operation restores a mongodump dump created with the --gzip, --archive, and --oplog options:
mongorestore --host localhost --port 27017 \
--oplogReplay \
--gzip --archive="/path/to/dump.gz"
Add any additional options as required by your deployment. Change the hostname and port based on the configuration of the target mongod.
-
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.
-
Copy the mongod data files from the backup data location to the data directory created in B. Prepare the Target Host for Restoration:
c -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.
- 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
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.
创建一个具有__system 角色的临时用户。
在此过程中,您将修改admin.system.version集合中的文档。对于执行authentication的群集,只有__system角色才授予修改此集合的权限。如果群集不强制执行身份验证,则可以跳过此步骤。
Warning
__system
角色授权其持有者对数据库中的任何对象执行任何操作。此过程包括有关删除在此步骤中创建的用户的说明。 请勿 保持此用户的活动状态超出此过程的范围。
请考虑使用配置为clientSource
authentication restriction的用户来创建此用户,以便只有指定的主机才能认证为特权用户。
- 在
admin
数据库或userAdminAnyDatabase角色上以具有userAdmin角色的用户身份进行身份验证:
use admin
db.auth("myUserAdmin","mySecurePassword")
- 创建一个具有__system角色的用户:
db.createUser(
{
user: "mySystemUser",
pwd: "<replaceMeWithAStrongPassword>",
roles: [ "__system" ]
}
)
密码应随机,长且复杂,以确保系统安全并防止或延迟恶意访问。
- 验证为特权用户:
db.auth("mySystemUser","<replaceMeWithAStrongPassword>")
删除本地数据库。
使用db.dropDatabase()删除local
数据库:
use local
db.dropDatabase()
从 admin.system.versions 集合中删除 minOpTimeRecovery 文档。
对admin
数据库中的system.version集合发出以下deleteOne()方法:
use admin
db.system.version.deleteOne( { _id: "minOpTimeRecovery" } )
可选:对于任何 CSRS 主机名或副本集名称更改,请更新每个分片的身份文档中的分片元数据。
如果满足以下所有条件,则可以跳过此步骤:
-
在此过程中,任何 CSRS 主机的主机名均未更改。
-
在此过程中,CSRS 副本集名称未更改。
admin
数据库上的system.version集合包含与分片有关的元数据,包括 CSRS 连接字符串。如果在还原 CSRS 时更改了 CSRS 名称或任何成员主机名,则必须更新此元数据。
对admin
数据库中的system.version集合发出以下find()方法:
use admin
db.system.version.find( {"_id" : "shardIdentity" } )
find()方法返回的文档类似于以下内容:
{
"_id" : "shardIdentity",
"clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
"shardName" : "shard1",
"configsvrConnectionString" : "myCSRSName/alpha.example.net:27019,beta.example.net:27019,charlie.example.net:27019" }
以下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
shardName
值必须与 CSRS 上shards集合中的_id
值匹配。验证 CSRS 上的元数据与分片的元数据匹配。有关查看 CSRS 元数据的说明,请参阅此过程的 C.Restore Config Server Replica Set 部分中的子步骤 3.
将 mongod 重新启动为新的单节点副本集。
Shut down mongod。取消 Comments 或添加以下配置文件选项:
replication
replSetName: myNewShardName
sharding
clusterRole: shardsvr
如果要更改副本集名称,则必须先使用新名称更新replSetName字段,然后再 continue。
使用更新的配置文件启动mongod:
mongod --config /path/to/mongodb/mongod.conf
如果您已将mongod配置为作为系统服务运行,请使用系统服务 Management 员推荐的过程来启动它。
启动新的副本集。
使用默认设置rs.initiate()初始化副本集。
rs.initiate()
操作完成后,使用rs.status()检查成员是否已成为primary。
添加其他副本集成员。
对于分片副本集中的每个副本集成员,在其主机上启动mongod。成功启动群集的所有其余成员后,将mongo shell 连接到主副本集成员。在主数据库中,使用rs.add()方法添加副本集的每个成员。包括副本集名称作为前缀,然后是成员的mongod进程的主机名和端口:
rs.add("repl2.example.net:27018")
rs.add("repl3.example.net:27018")
如果要添加具有特定副本member
配置设置的成员,则可以将文档传递给rs.add(),该文档定义成员主机名和部署所需的任何members[n]
设置。
rs.add(
{
"host" : "repl2.example.net:27018",
priority: <int>,
votes: <int>,
tags: <int>
}
)
每个新成员执行一次initial sync赶上主要成员。根据要同步的数据量,网络拓扑和运行状况以及每台主机的功能等因素,完成初始同步可能需要较长的时间。
当您添加其他成员时,副本集可能会选择一个新的主副本。使用rs.status()标识哪个成员是当前主要成员。您只能从主数据库运行rs.add()。
配置任何其他必需的复制设置。
rs.reconfig()方法基于作为参数传入的配置文档更新副本集配置。您必须对副本集的主要成员运行reconfig()。
参考步骤 A 中标识的副本集的原始配置文件输出。查看副本集配置并根据需要应用设置。
删除临时特权用户。
对于执行身份验证的群集,请删除此过程前面创建的特权用户:
- 在
admin
数据库或userAdminAnyDatabase角色上以具有userAdmin角色的用户身份进行身份验证:
use admin
db.auth("myUserAdmin","mySecurePassword")
- 删除特权用户:
db.removeUser("mySystemUser")
E.重新启动每个 mongos
重新启动群集中的每个mongos。
mongos --config /path/to/config/mongos.conf
包括部署所需的所有其他命令行选项。
如果 CSRS 副本集名称或任何成员主机名已更改,请使用更新的配置服务器连接字符串更新mongos配置文件设置sharding.configDB:
sharding:
configDB: "myNewCSRSName/config1.example.net:27019,config2.example.net:27019,config3.example.net:27019"
F.验证群集可访问性
将mongo Shell 连接到群集的mongos进程之一。使用sh.status()检查总体群集状态。如果sh.status()指示平衡器未在运行,请使用sh.startBalancer()重新启动平衡器。
要确认所有分片均可以访问和通信,请将测试数据插入到临时分片集合中。确认正在集群中的每个分片之间拆分和迁移数据。您可以将mongoShell 连接到每个分片主数据库,并使用db.collection.find()验证数据是否按预期分片。