Replica Set Arbiter副本集仲裁器
On this page本页内容
In some circumstances (such as when you have a primary and a secondary, but cost constraints prohibit adding another secondary), you may choose to add an arbiter to your replica set. 在某些情况下（例如，当您有一个主副本和一个辅助副本，但成本限制禁止添加另一个辅助时），您可以选择向复制副本集添加仲裁器。An arbiter participates in elections for primary but an arbiter does not have a copy of the data set and cannot become a primary.仲裁器参与选举primary，但仲裁器没有数据集的副本，不能成为primary。
An arbiter has exactly 仲裁者只有1 election vote. By default an arbiter has priority 0.1张选举选票。默认情况下，仲裁器的优先级为0。
Do not run an arbiter on systems that also host the primary or the secondary members of the replica set.不要在同时承载复制集的主成员或辅助成员的系统上运行仲裁器。
To add an arbiter, see Add an Arbiter to Replica Set.要添加仲裁器，请参阅将仲裁器添加到副本集。
Release Version Considerations发布版本注意事项
Arbiters are not supported with quarterly rapid releases. 仲裁器不支持季度快速发布。If your deployment includes arbiters, only use LTS releases.如果您的部署包括仲裁器，请仅使用LTS版本。
Performance Issues with PSA replica setsPSA复制集的性能问题
If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:如果您使用的是由三个成员组成的主辅仲裁器（PSA）架构，请考虑以下事项：
The write concern如果辅助设备不可用或滞后，写入关注"majority"can cause performance issues if a secondary is unavailable or lagging."majority"可能会导致性能问题。For advice on how to mitigate these issues, see Mitigate Performance Issues with PSA Replica Set.有关如何缓解这些问题的建议，请参阅使用PSA副本集缓解性能问题。If you are using a global default如果使用全局默认的"majority"and the write concern is less than the size of the majority, your queries may return stale (not fully replicated) data."majority"，并且写入关注小于多数的大小，则查询可能会返回过时（未完全复制）的数据。
Replica Set Protocol Version and Arbiter副本集协议版本和仲裁器
For the following MongoDB versions, 对于以下MongoDB版本，与带有仲裁器的副本集的pv1 increases the likelihood of w:1 rollbacks compared to pv0 (no longer supported in MongoDB 4.0+) for replica sets with arbiters:pv0（在MongoDB 4.0+中不再支持）相比，pv1增加了w:1回滚的可能性：
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
See Replica Set Protocol Version.请参阅副本集协议版本。
For more information, see the 有关详细信息，请参阅setFeatureCompatibilityVersion command.setFeatureCompatibilityVersion命令。
Feature Compatibility Version功能兼容性版本
Arbiters do not replicate the Arbiters不会复制admin.system.version collection. admin.system.version集合。Because of this, arbiters always have a feature compatibility version equal to the downgrade version of the binary, regardless of the fCV value of the replica set.因此，无论副本集的fCV值如何，仲裁器的功能兼容性版本始终等于二进制文件的降级版本。
Concerns with Multiple Arbiters对多个仲裁员的关注
Use a single arbiter to avoid problems with data consistency. Multiple arbiters prevent the reliable use of the majority write concern.使用单个仲裁器来避免数据一致性问题。多个仲裁器阻止了多数写入关注的可靠使用。
To ensure that a write will persist after the failure of a primary node, the majority write concern requires a majority of nodes to acknowledge a write operation. 为了确保写操作在主节点发生故障后持续存在，多数写操作需要多数节点确认写操作。Arbiters do not store any data, but they do contribute to the number of nodes in a replica set. Arbiter不存储任何数据，但它们确实会增加副本集中的节点数量。When a replica set has multiple arbiters it is less likely that a majority of data bearing nodes will be available after a node failure.当副本集具有多个仲裁器时，在节点故障后，大多数数据承载节点不太可能可用。
If a secondary node falls behind the primary, and the cluster is 如果次要节点落后于主要节点，并且集群被reconfigured, votes from multiple arbiters can elect the node that had fallen behind. reconfigured，则来自多个仲裁器的投票可以选择落后的节点。The new primary will not have the unreplicated writes even though the writes could have been majority committed by the old configuration. The result is data loss.新的主配置将不会有未复制的写入，即使写入可能大部分由旧配置提交。结果是数据丢失。
To avoid this scenario, use at most a single arbiter.为了避免这种情况，最多使用一个仲裁器。
New in version 5.3. 5.3版新增。
Starting in MongoDB 5.3, support for multiple arbiters in a replica set is disabled by default. 从MongoDB 5.3开始，默认情况下会禁用对副本集中多个仲裁器的支持。If you attempt to add multiple arbiters to a replica set, the server returns an error:如果尝试将多个仲裁器添加到副本集中，服务器将返回错误：
MongoServerError: Multiple arbiters are not allowed unless all nodes
were started with --setParameter 'allowMultipleArbiters=true'
To add multiple arbiters to a replica set using MongoDB 5.3 or later, start each node with the 要使用MongoDB 5.3或更高版本向副本集添加多个仲裁器，请将allowMultipleArbiters parameter set to true:allowMultipleArbiters参数设置为true来启动每个节点：
mongod --setParameter allowMultipleArbiters=true
Security安全
Authentication身份验证
When running with 当使用authorization, arbiters exchange credentials with other members of the set to authenticate. authorization运行时，仲裁器会与集合的其他成员交换凭据以进行身份验证。MongoDB encrypts the authentication process, and the MongoDB authentication exchange is cryptographically secure.MongoDB对身份验证过程进行加密，MongoDB身份验证交换在加密方面是安全的。
Because arbiters do not store data, they do not possess the internal table of user and role mappings used for authentication. 因为仲裁器不存储数据，所以它们不拥有用于身份验证的用户和角色映射的内部表。Thus, the only way to log on to an arbiter with authorization active is to use the localhost exception.因此，在授权处于活动状态的情况下登录仲裁器的唯一方法是使用localhost异常。
Communication通信
The only communication between arbiters and other set members are: votes during elections, heartbeats, and configuration data. These exchanges are not encrypted.仲裁器和其他集合成员之间的唯一通信是：选举期间的投票、心跳和配置数据。这些交换没有加密。
However, if your MongoDB deployment uses TLS/SSL, MongoDB will encrypt all communication between replica set members. 但是，如果您的MongoDB部署使用TLS/SSL，MongoDB将加密副本集成员之间的所有通信。See Configure 请参阅为TLS/SSL配置mongod and mongos for TLS/SSL for more information.mongod和mongos以获取更多信息。
As with all MongoDB components, run arbiters in trusted network environments.与所有MongoDB组件一样，在可信的网络环境中运行仲裁器。
Example实例
For example, in the following replica set with 2 data-bearing members (the primary and a secondary), an arbiter allows the set to have an odd number of votes to break a tie:例如，在以下具有2个数据承载成员（主要成员和次要成员）的副本集中，仲裁器允许该集拥有奇数个投票以打破平局：
