管理分片集群负载均衡器
在此页面上
在版本 6.1 中更改。
本页介绍与负载均衡相关的常见管理过程。有关负载均衡的介绍,请参阅分片集群负载均衡器 。有关负载均衡的基础信息,请参阅负载均衡器内部知识。
负载均衡器进程已从 mongos
实例移到配置服务器副本集的主节点。
检查负载均衡器状态
sh.getBalancerState()
会检查是否已启用负载均衡器(即,允许负载均衡器运行)。sh.getBalancerState()
不会检查负载均衡器是否正在主动迁移数据。
如要查看您的分片集群中是否已启用负载均衡器,请运行以下命令(会返回一个布尔值):
sh.getBalancerState()
您还可以使用 sh.status()
查看负载均衡器是否已启用。currently-enabled
字段指示负载均衡器是否已启用,而 currently-running
字段指示负载均衡器当前是否正在运行。
检查负载均衡器是否正在运行
要查看集群中的负载均衡器进程是否处于活动状态:
配置默认范围大小
分片集群的默认范围大小为 128 MB。在大多数情况下,默认大小适用于拆分和迁移数据段。 有关范围大小如何影响部署的信息,请参阅详细信息,请参阅范围大小。
更改默认范围大小会影响迁移和自动分割期间所处理的范围,但不会以追溯方式影响所有范围。
从 MongoDB 6.0.3 开始,不再执行自动数据块分割。这是因为均衡策略的改进。自动分割命令仍然存在,但不执行操作。
要配置默认范围大小,请参阅在分片集群中修改范围大小。
安排均衡窗口
某些情况下,尤其是当数据集增长缓慢且迁移可能会影响性能时,确保负载均衡器仅在特定时间处于活动状态非常有用。默认情况下,负载均衡器进程始终处于启用状态并会迁移数据块。以下过程指定了 activeWindow
,即负载均衡器能够迁移数据块的时间范围:
切换到 配置数据库 。
发出以下命令以切换到配置数据库。
use config
确保负载均衡器不是stopped
。
负载均衡器在 stopped
状态下不会激活。要确保负载均衡器未处于 stopped
状态,请使用 sh.startBalancer()
,如下所示:
sh.startBalancer()
如果您处于 activeWindow
时间范围之外,负载均衡器则不会启动。
从 MongoDB 6.0.3 开始,不再执行自动数据块分割。这是因为均衡策略的改进。自动分割命令仍然存在,但不执行操作。
在 6.0.3 之前的 MongoDB 版本中,sh.startBalancer()
还支持分片集群的自动拆分。
修改负载均衡器的窗口。
使用 updateOne()
设置 activeWindow
,如下所示:
db.settings.updateOne( { _id: "balancer" }, { $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } }, { upsert: true } )
将 <start-time>
和 <end-time>
替换为采用两位数小时与分钟值的时间值(即 HH:MM
),从而指定负载均衡窗口的开始与结束边界。
对于
HH
值,请使用介于00
-23
之间的小时值。对于
MM
值,请使用从00
到59
(含)的分钟值。
对于本地或自管理分片集群,MongoDB 会计算开始与停止时间(相对于配置服务器副本集中主要成员的时区)。
对于 Atlas 集群,MongoDB 会评估相对于 UTC 时区的开始和停止时间。
注意
负载均衡器窗口必须足以完成当天所插入全部数据的迁移。
由于数据插入速率可能会因活动和使用模式而变化,因此请务必确保您选择的负载均衡窗口足以支持您的部署需求。
检查负载均衡窗口
要查看当前的负载均衡窗口,请运行以下命令:
use config db.settings.find( { _id: "balancer" } )
移除负载均衡窗口时间表
如果您已设置负载均衡窗口且希望删除时间表以使负载均衡器始终处于运行状态,则请使用 $unset
清除 activeWindow
,如下所示:
use config db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )
禁用负载均衡器
默认情况下,负载均衡器可随时运行,且仅按需移动数据段。要在一小短时间内禁用负载均衡器并阻止所有迁移,请执行以下过程:
发出以下操作以禁用负载均衡器:
sh.stopBalancer() 如果迁移正在进行,系统将在停止之前完成进行中的迁移。
从 MongoDB 6.0.3 开始,不再执行自动数据块分割。这是因为均衡策略的改进。自动分割命令仍然存在,但不执行操作。
在 6.0.3 之前的 MongoDB 版本中,
sh.stopBalancer()
还会禁用分片集群的自动拆分。要确保负载均衡器不会启动,请运行以下命令。如果负载均衡器已被禁用,此命令则会返回
false
:sh.getBalancerState() 或者,要验证在禁用后没有进行中的迁移,请在
mongosh
Shell 中运行以下操作:use config while( sh.isBalancerRunning() ) { print("waiting..."); sleep(1000); }
注意
要从驱动程序禁用负载均衡器,请对 admin
数据库使用 balancerStop 命令,如下所示:
db.adminCommand( { balancerStop: 1 } )
启用负载均衡器
如果已禁用负载均衡器并准备重新启用它,请执行以下过程:
发出以下操作之一以启用负载均衡器:
在
mongosh
shell 中,发出以下命令:sh.startBalancer() 注意
要从驱动程序启用负载均衡器,请对
admin
数据库使用 balancerStart 命令,如下所示:db.adminCommand( { balancerStart: 1 } ) 从 MongoDB 6.0.3 开始,不再执行自动数据块分割。这是因为均衡策略的改进。自动分割命令仍然存在,但不执行操作。
在 6.0.3 之前的 MongoDB 版本中,
sh.startBalancer()
还支持分片集群的自动拆分。
在备份期间禁用负载均衡
注意
仅当手动进行备份时才需禁用负载均衡器,具体方法是调用 mongodump
或安排会在特定时间调用 mongodump
的任务。
使用协调式备份与恢复流程时,不必禁用负载均衡器:
如果 MongoDB 在备份期间迁移数据段,则最后可能导致不一致的分片集群快照。切勿在负载均衡器处于活动状态时运行备份。要确保负载均衡器在备份操作期间处于非活动状态,请执行以下操作:
如果在某一负载均衡回合中关闭负载均衡器,则不会立即将其关闭。负载均衡器会先完成进行中的数据段移动,然后再停止所有后续负载均衡回合。
在开始备份操作之前,请确认负载均衡器未处于活动状态。您可以使用以下命令来确定负载均衡器是否处于活动状态:
!sh.getBalancerState() && !sh.isBalancerRunning()
备份过程完成后,您可以重新激活负载均衡器进程。
对集合禁用负载均衡
您可以使用 sh.disableBalancing()
方法为特定集合禁用负载均衡。您可能想为特定集合禁用负载均衡器以支持维护操作或非典型工作负载,例如在数据引入或数据导出期间。
对集合禁用负载均衡时,MongoDB 不会中断进行中的迁移。
要对集合禁用负载均衡,请使用 mongosh
shell 连接到 mongos
并调用 sh.disableBalancing()
方法。
例如:
sh.disableBalancing("students.grades")
sh.disableBalancing()
方法接受集合的完整命名空间作为其参数。
对集合启用负载均衡
您可以使用 sh.enableBalancing()
方法为特定集合启用负载均衡。
为集合启用负载均衡后,MongoDB 不会立即开始对数据进行负载均衡。但是,如果分片集合中的数据未进行负载均衡,MongoDB 可以开始更均匀地分发该数据。
要对集合启用负载均衡,请使用 mongosh
shell 连接到 mongos
并调用 sh.enableBalancing()
方法。
例如:
sh.enableBalancing("students.grades")
sh.enableBalancing()
方法接受集合的完整命名空间作为其参数。
确认负载均衡功能是已启用还是已禁用
要确认是启用还是禁用了集合负载均衡,请在 config
数据库中查询 collections
集合以获取集合命名空间,然后检查 noBalance
字段。例如:
db.getSiblingDB("config").collections.findOne({_id : "students.grades"}).noBalance;
此操作将返回 null 错误、true
、false
或无输出:
null 错误表示集合命名空间不正确。
如果结果为
true
,负载均衡则已禁用。如果结果为
false
,则当前已启用负载均衡,但过去已对集合禁用负载均衡。该集合的均衡状态将在负载均衡器下次运行时开始。如果该操作没有返回输出,则当前已启用负载均衡,并且该集合过去从未禁用过负载均衡。该集合的均衡状态将在负载均衡器下次运行时开始。
您还可使用 sh.status()
来查看负载均衡器是否已启用。currently-enabled
字段可表明负载均衡器是否已启用。
更改数据段迁移的复制行为
辅助限制
在数据块迁移过程中,_secondaryThrottle
值决定何时继续迁移数据块内的下一个文档。
在 config.settings
集合中:
如果将负载均衡器的
_secondaryThrottle
设置设为写关注,则数据块迁移期间的每次文档移动均须收到所需的确认,然后才能继续处理下一个文档。如果未进行
_secondaryThrottle
设置,迁移过程不会等待复制到从节点,而是继续处理下一个文档。这是 WiredTiger 的默认行为。
要更改 _secondaryThrottle
设置,请连接到 mongos
实例,并直接更新配置数据库的 settings
集合中的 _secondaryThrottle
值。例如,从连接到 mongos
的mongosh
shell 中,运行以下命令:
use config db.settings.updateOne( { "_id" : "balancer" }, { $set : { "_secondaryThrottle" : { "w": "majority" } } }, { upsert : true } )
更改 _secondaryThrottle
设置可能不会立即生效。为确保立即生效,请停止并重新启动负载均衡器,以启用所选的 _secondaryThrottle
值。
有关数据段迁移各步骤中复制行为的更多信息,请参阅范围迁移和复制。
等待删除
负载均衡器的 _waitForDelete
设置和 moveChunk
命令会影响负载均衡器从分片迁移多个数据段的方式。同样,负载均衡器的 _waitForDelete
设置和 moveRange
命令也会影响负载均衡器如何从分片迁移多个数据段。默认情况下,负载均衡器在开始下一数据段迁移之前不会等待进行中迁移的删除阶段完成。要让删除阶段阻止下一数据段迁移开始,可将 _waitForDelete
设为 true。
有关数据段迁移的详细信息,请参阅范围迁移。有关数据段迁移队列行为的详细信息,请参阅异步范围迁移清理。
_waitForDelete
通常用于内部测试。要更改负载均衡器的 _waitForDelete
值:
连接到
mongos
实例。更新配置数据库的
settings
集合中的_waitForDelete
值。例如:use config db.settings.updateOne( { "_id" : "balancer" }, { $set : { "_waitForDelete" : true } }, { upsert : true } )
设为 true
后,要恢复为默认行为,请执行以下操作:
超过大小限制的负载均衡范围
默认情况下,如果范围中的文档数大于配置的范围大小除以平均文档大小的结果的 2 倍,则 MongoDB 无法移动该范围。
通过将负载均衡器设置 attemptToBalanceJumboChunks
指定为 true
,负载均衡器可以迁移这些大范围,但前提是它们没有被标记为 jumbo。
要设置负载均衡器的 attemptToBalanceJumboChunks
设置,请连接到 mongos
实例并直接更新 config.settings
集合。例如,从连接到 mongosh
实例的mongos
shell 中,运行以下命令:
db.getSiblingDB("config").settings.updateOne( { _id: "balancer" }, { $set: { attemptToBalanceJumboChunks : true } }, { upsert: true } )
如果您要移动的范围标记为 jumbo
,则可以手动清除 jumbo 标志,让负载均衡器尝试迁移范围。
您还可使用以下任一方法手动迁移超过大小限制(带或不带 jumbo
标签)的范围:
moveRange
命令并使用 forceJumbo: true 选项moveChunk
命令并使用 forceJumbo: true 选项
但在运行 moveRange
或 moveChunk
并使用 forceJumbo: true
时,对集合的写操作可能会在迁移期间长时间阻塞。
更改给定分区的最大存储大小
注意
更改分片的最大存储大小功能已被弃用。MongoDB 使用 WiredTiger 存储引擎来管理数据的存储方式。WiredTiger 会压缩数据以尽量减少存储空间使用量。要了解详情,请参阅压缩。
对于 MongoDB 6.1 及更早版本,您仍可使用 maxSize
字段为分片集群中的给定分片设置最大存储大小。您可在 config.shards
集合中找到与分片相关的配置数据。
从 6.2 版开始,MongoDB 删除了 addShard
命令中的 maxSize
字段。因此: