We use cookies and other similar technology to collect data to improve your experience on our site, as described in our Privacy Policy.

AppsCode
  • KubeDB

    Run Production-Grade Databases on Kubernetes

    arrow_forward
    Stash

    Backup and Recovery Solution for Kubernetes

    arrow_forward
    KubeVault

    Run Production-Grade Vault on Kubernetes

    arrow_forward
    Voyager

    Secure HAProxy Ingress Controller for Kubernetes

    arrow_forward
    ConfigSyncer

    Kubernetes Configuration Syncer

    arrow_forward
    Guard

    Kubernetes Authentication WebHook Server

    arrow_forward
    KubeDB

    KubeDB simplifies Provision, Upgrade, Scaling, Volume Expansion, Monitor, Backup, Restore for various Databases in Kubernetes on any Public & Private Cloud

    • task_altLower administrative burden
    • task_altNative Kubernetes Support
    • task_altPerformance
    • task_altAvailability and durability
    • task_altManageability
    • task_altCost-effectiveness
    • task_altSecurity
    Stash

    A complete Kubernetes native disaster recovery solution for backup and restore your volumes and databases in Kubernetes on any public and private clouds.

    • task_altDeclarative API
    • task_altBackup Kubernetes Volumes
    • task_altBackup Database
    • task_altMultiple Storage Support
    • task_altDeduplication
    • task_altData Encryption
    • task_altVolume Snapshot
    • task_altPolicy Based Backup
    KubeVault

    KubeVault is a Git-Ops ready, production-grade solution for deploying and configuring Hashicorp's Vault on Kubernetes.

    • task_altVault Kubernetes Deployment
    • task_altAuto Initialization & Unsealing
    • task_altVault Backup & Restore
    • task_altConsume KubeVault Secrets with CSI
    • task_altManage DB Users Privileges
    • task_altStorage Backend
    • task_altAuthentication Method
    • task_altDatabase Secret Engine
    Voyager

    Secure HAProxy Ingress Controller for Kubernetes

    • task_altHTTP & TCP
    • task_altSSL
    • task_altPlatform support
    • task_altHAProxy
    • task_altPrometheus
    • task_altLet's Encrypt
    configsyncer

    Kubernetes Configuration Syncer

    • task_altConfiguration Syncer
    Guard

    Kubernetes Authentication WebHook Server

    • task_altIdentity Providers
    • task_altCLI
    • task_altRBAC
  • RESOURCES
  • Webinar New
CONTACT SALES
KubeDB KubeDB
github-icon twitterx-icon
TRY NOW FREE
You are looking at the documentation of a prior release. To read the documentation of the latest release, please visit here.

New to KubeDB? Please start here.

MongoDB Arbiter

Arbiter is a member of MongoDB ReplicaSet. It does not have a copy of data set and cannot become a primary. 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. Replica sets may have arbiters to add a vote in elections for primary. Arbiters always have exactly 1 election vote, and thus allow replica sets to have an uneven number of voting members without the overhead of an additional member that replicates data. By default, it is a priority-0 member.

For example, in the following replica set with a 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:

  lifecycle

Considerations

There are some important considerations that should be taken care of by the Database administrators when deploying MongoDB.

Priority

Starting in MongoDB 3.6, arbiters have priority 0. When you upgrade a replica set to MongoDB 3.6, if the existing configuration has an arbiter with priority 1, MongoDB 3.6 reconfigures the arbiter to have priority 0.

IMPORTANT: Do not run an arbiter on systems that also host the primary or the secondary members of the replica set. [reference].

Performance Issues

If you are using a three-member primary-secondary-arbiter (PSA) architecture, consider the following:

  • The write concern “majority” can cause performance issues if a secondary is unavailable or lagging.See Mitigate Performance Issues with PSA Replica Set to mitigate these issues.

  • 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.

Concerns with multiple Arbiters

Using multiple arbiters on same replicaSet can causes data inconsistency. Multiple arbiters prevent the reliable use of the majority write concern. For more details in this concerns, read this.

By considering this issue into account, KubeDB doesn’t support multiple arbiter to be deployed in a single replicaset.

Security

As arbiters do not store data, they do not possess the internal table of user and role mappings used for authentication. Thus When running with authorization, arbiters exchange credentials with other members of the set to authenticate.

Also MongoDB doc suggests to use TLS to avoid leaking unencrypted data when arbiter communicates with other replicaset member.

Protocol version

For replica sets, the write concern { w: 1 } only provides acknowledgement of write operations on the primary. Data may be rolled back if the primary steps down before the write operations have replicated to any of the secondaries. This type behaviour is called w:1 roolback.

For the following MongoDB versions, pv1 (protocol version 1, which is default Starting in 4.0) increases the likelihood of w:1 rollbacks compared to pv0 (no longer supported in MongoDB 4.0+) for replica sets with arbiters:

i) MongoDB 3.4.1
ii) MongoDB 3.4.0
iii) MongoDB 3.2.11 or earlier

Next Steps

NB: The images in this page are taken from MongoDB website.

What's on this Page

Search
Improve This Page