Val och automatisk failover

Automatisk failover är en replikuppsättnings förmåga att återhämta sig från ett fel på primary-noden utan mänsklig inblandning. När primary blir otillgänglig väljer de återstående medlemmarna automatiskt en ny primary – vanligtvis inom 10 till 30 sekunder – så att applikationerna bara drabbas av ett kort avbrott i stället för ett fullständigt driftstopp.

Medlemmarna i replikuppsättningen skickar kontinuerligt heartbeat-meddelanden varannan sekund. Om en medlem inte får något svar på ett heartbeat inom electionTimeoutMillis (standardvärde 10 sekunder) markerar den den tysta medlemmen som otillgänglig. Om den saknade medlemmen är primary påbörjar de återstående valbara medlemmarna ett val.

Ett val utlöses i tre situationer: 1) primary blir otillgänglig (nätverkspartition eller krasch), 2) en användare låter manuellt primary träda tillbaka med rs.stepDown(), eller 3) en secondary med högre prioritet ansluter och den aktuella primary har lägre prioritet. Endast medlemmar med votes: 1 och priority > 0 kan bli den nya primary.

MongoDB-val använder ett protokoll som inspirerats av Raft-konsensus. Varje kandidat ökar sin term-räknare och ber de andra medlemmarna om röster. En kandidat vinner om den får röster från en majoritet av de röstberättigade medlemmarna. Kandidaten med den mest uppdaterade oplog (högst optime) föredras – detta förhindrar dataförlust genom att säkerställa att den nya primary har sett alla bekräftade skrivningar.

En kandidat behöver röster från mer än hälften av alla röstberättigade medlemmar (inte bara de som för närvarande kan nås). I en uppsättning med 3 medlemmar och 3 röster är en majoritet 2. Det innebär att den överlevande medlemmen inte kan välja sig själv om 2 medlemmar slutar fungera – den skulle arbeta med inaktuella data utan möjlighet att veta om de andra två medlemmarna har nyare skrivningar.

Valet går till så här: 1) En secondary upptäcker att primary saknas efter timeouten. 2) Den övergår till tillståndet CANDIDATE. 3) Den skickar RequestVote-meddelanden till alla andra medlemmar. 4) Medlemmarna beviljar röster om kandidatens oplog är minst lika aktuell som deras egen och de inte redan har röstat. 5) Vinnaren övergår till PRIMARY och börjar ta emot skrivningar.

Under valperioden (vanligtvis några sekunder) nekas skrivningar eftersom det inte finns någon primary. MongoDB-drivrutinen buffrar skrivoperationerna och försöker skicka dem igen när en ny primary har valts. När retryable writes är aktiverat (standard i moderna drivrutiner) försöks tillfälliga valfel automatiskt igen en gång.

När flera kandidater är lika uppdaterade avgör priority saken – medlemmen med högst prioritet vinner. Om en secondary med högre prioritet återansluter efter att ha varit offline utlöser den ett nytt val för att ta över rollen som primary. Om priority sätts till 0 utesluts medlemmen permanent från möjligheten att bli primary.

I en nätverkspartition kan medlemmarna på ena sidan av uppdelningen inte kommunicera med den andra. Sidan med flest röster kan välja en primärmedlem; minoritetssidan övergår till skrivskyddat läge. Detta förhindrar ett split-brain-scenario där två medlemmar samtidigt tror att de är primärmedlem och accepterar motstridiga skrivningar.

Ni kan övervaka val och failover-händelser genom att granska MongoDB-loggen eller fråga konfigurationen i system.replset. Atlas tillhandahåller realtidsaviseringar för valhändelser. I era applikationsloggar kommer ni att se toppar av MongoNotPrimaryError eller MongoNetworkError under ett val — skrivningar som kan göras om hanterar detta automatiskt.

Så här minimerar ni tiden för failover: 1) Använd replikuppsättningar med ett udda antal medlemmar (3 eller 5) för att undvika behovet av arbitrarier. 2) Använd en write concern med majoritet för att säkerställa att den valda sekundärmedlemmen har alla bekräftade skrivningar. 3) Minimera oplog-fördröjningen genom att tillhandahålla tillräcklig oplog-storlek. 4) Placera replikuppsättningens medlemmar i samma region för heartbeat-signaler med låg latens.

I den här lektionen har ni lärt er att: heartbeats upptäcker fel på primärmedlemmen inom electionTimeoutMillis (10 s som standard), kandidaten med den mest aktuella oploggen och högst prioritet vinner valet och skrivningar som kan göras om gör att applikationer transparent klarar korta valperioder. Härnäst utforskar vi write concerns och hur ni styr skrivningarnas hållbarhet över replikuppsättningen.