sql >> Databasteknik >  >> NoSQL >> MongoDB

Varför behöver vi en "arbiter" i MongoDB-replikering?

Jag skapade ett kalkylblad för att bättre illustrera effekten av Arbiter-noder i en replikuppsättning.

Det handlar i princip om dessa punkter:

  1. Med en RS av 2 datanoder , om du förlorar 1 server kommer du under ditt röstminimum (som är "större än N/2"). En skiljedomare löser detta.
  2. Med en RS av jämna datanoder , om du lägger till en Arbiter ökar din feltolerans med 1 utan att göra det möjligt att ha 2 röstningskluster på grund av en splittring.
  3. Med en RS av udda numrerade datanoder , att lägga till en Arbiter skulle tillåta en split för att skapa 2 isolerade kluster med "större än N/2" röster och därför ett delat hjärnscenario.

Val förklaras [i dåligt] detalj här. I det dokumentet sägs att en RS kan ha 50 medlemmar (jämnt antal) och 7 röstberättigade medlemmar. Jag betonar "tillstånd" eftersom det inte förklarar hur det fungerar. För mig verkar det som att om du har en splittring med 4 medlemmar (alla röstar) på ena sidan och 46 medlemmar (3 röstande) på den andra, så skulle du hellre vilja att de 46 väljer en primär och att de 4 ska vara en läs- endast kluster. Men, det är precis vad "begränsad röstning" förhindrar. I den situationen kommer du faktiskt att ha ett 4-medlemskluster med ett primärt och ett 46-medlemskluster som är skrivskyddat. Att förklara hur det är vettigt ligger utanför den här frågans omfattning och bortom min kunskap.



  1. En enkel taggningsimplementering med MongoDB

  2. MongoDB hel och partiell textsökning

  3. Använd Mongosniff för att förtydliga vad din MongoDB hör och säger

  4. Redis Mass Insertion