sql >> Database >  >> NoSQL >> MongoDB

Waarom hebben we een 'arbiter' nodig in MongoDB-replicatie?

Ik heb een spreadsheet gemaakt om het effect van Arbiter-knooppunten in een replicaset beter te illustreren.

Het komt eigenlijk neer op deze punten:

  1. Met een RS van 2 dataknooppunten , als u 1 server verliest, komt u onder uw stemminimum (dat is "groter dan N/2"). Een arbiter lost dit op.
  2. Met een RS van even genummerde dataknooppunten , het toevoegen van een arbiter verhoogt uw fouttolerantie met 1 zonder dat het mogelijk is om 2 stemclusters te hebben vanwege een splitsing.
  3. Met een RS van oneven genummerde dataknooppunten , zou het toevoegen van een arbiter een splitsing mogelijk maken om 2 geïsoleerde clusters te creëren met "groter dan N/2" stemmen en dus een scenario met een gesplitst brein.

Verkiezingen worden hier [slecht] gedetailleerd uitgelegd. In dat document staat dat een RS 50 leden (even aantal) en 7 stemgerechtigde leden kan hebben. Ik benadruk "staten" omdat het niet uitlegt hoe het werkt. Voor mij lijkt het dat als je een splitsing hebt met 4 leden (allen stemmen) aan de ene kant en 46 leden (3 stemmen) aan de andere kant, je liever hebt dat de 46 een voorverkiezing kiezen en de 4 een lees- alleen clusteren. Maar dat is precies wat "beperkt stemmen" voorkomt. In die situatie heb je eigenlijk een cluster van 4 leden met een primaire en een cluster van 46 leden die alleen-lezen is. Uitleggen hoe dat logisch is, valt buiten het bestek van deze vraag en ligt buiten mijn kennis.



  1. Gebruik meer dan één schema per verzameling op mongodb

  2. Unix-tijdstempel in seconden uit MongoDB ISODate halen tijdens aggregatie

  3. Specifieke items uit de array verwijderen met MongoDB

  4. kan geen verbinding maken met redis-container vanuit app-container