Valg og automatisk failover

Automatisk failover er et MongoDB-replikasæts evne til at komme sig efter en fejl på primary-noden uden menneskelig indgriben. Når primary bliver utilgængelig, vælger de resterende medlemmer automatisk en ny primary — typisk inden for 10 til 30 sekunder — så applikationer kun oplever en kort pause i stedet for et fuldstændigt nedbrud.

Medlemmerne af et replikasæt udveksler løbende heartbeat-meddelelser hvert 2. sekund. Hvis et medlem ikke modtager et heartbeat-svar inden for electionTimeoutMillis (standardværdien er 10 sekunder), markerer det det tavse medlem som utilgængeligt. Hvis det manglende medlem er primary, starter de resterende kvalificerede medlemmer et valg.

Et valg udløses i tre situationer: 1) primary bliver utilgængelig (netværksopdeling eller nedbrud), 2) en bruger træder manuelt ned som primary med rs.stepDown(), eller 3) en secondary med højere prioritet tilslutter sig, mens den aktuelle primary har lavere prioritet. Kun medlemmer med votes: 1 og priority > 0 kan blive den nye primary.

MongoDB-valg bruger en protokol, der er inspireret af Raft-konsensus. Hver kandidat øger sin term-tæller og anmoder de andre medlemmer om stemmer. En kandidat vinder, hvis den får stemmer fra et flertal af de stemmeberettigede medlemmer. Kandidaten med den mest opdaterede oplog (højeste optime) foretrækkes — det forhindrer datatab ved at sikre, at den nye primary har set alle bekræftede skrivninger.

En kandidat skal have stemmer fra mere end halvdelen af alle stemmeberettigede medlemmer (ikke kun dem, der aktuelt kan nås). I et sæt med 3 medlemmer og 3 stemmer er et flertal 2. Det betyder, at hvis 2 medlemmer går ned samtidigt, kan det overlevende medlem ikke vælge sig selv — det ville arbejde med forældede data uden mulighed for at vide, om de to andre medlemmer har nyere skrivninger.

Valget foregår sådan: 1) En secondary opdager efter timeoutet, at primary er væk. 2) Den skifter til tilstanden CANDIDATE. 3) Den sender RequestVote-meddelelser til alle andre medlemmer. 4) Medlemmerne afgiver deres stemme, hvis kandidatens oplog er mindst lige så opdateret som deres egen, og de ikke allerede har stemt. 5) Vinderen skifter til PRIMARY og begynder at acceptere skrivninger.

Mens valget står på (typisk nogle få sekunder), afvises skrivninger, fordi der ikke findes en primary. MongoDB-driveren gemmer skrivehandlingerne i en buffer og prøver dem igen, når en ny primary er valgt. Når skrivninger, der kan forsøges igen, er aktiveret (standard i moderne drivere), forsøges midlertidige fejl under valget automatisk igen én gang.

Når flere kandidater er lige opdaterede, afgør prioriteten udfaldet — medlemmet med den højeste prioritet vinder. Hvis en secondary med højere prioritet vender tilbage efter at have været offline, udløser den et nyt valg for at overtage rollen som primary. Hvis du angiver prioriteten til 0, udelukkes medlemmet permanent fra at blive primary.

I en netværkspartition kan medlemmer på den ene side af opdelingen ikke kommunikere med den anden. Siden med flertallet af stemmerne kan vælge en primær, mens mindretalssiden går i skrivebeskyttet tilstand. Det forhindrer et split-brain-scenarie, hvor to medlemmer samtidig tror, at de er primære, og accepterer modstridende skrivninger.

Du kan overvåge valg og failover-hændelser ved at undersøge MongoDB-loggen eller forespørge i konfigurationen i system.replset. Atlas giver realtidsadvarsler om valghændelser. I dine applikationslogge vil du se stigninger i MongoNotPrimaryError eller MongoNetworkError under et valg — gentagelige skrivninger håndterer dette automatisk.

Sådan minimerer du failover-tiden: 1) Brug replikasæt med et ulige antal medlemmer (3 eller 5) for at undgå behovet for arbitre. 2) Brug en skrivebekræftelse med flertal for at sikre, at den valgte sekundære har alle bekræftede skrivninger. 3) Minimer forsinkelsen i oploggen ved at sørge for en tilstrækkelig størrelse på oploggen. 4) Placér medlemmerne af replikasættet i samme region for at få heartbeat-signaler med lav latenstid.

I denne lektion lærte du, at heartbeat-signaler registrerer fejl i den primære inden for electionTimeoutMillis (10 sek. som standard), at kandidaten med den mest aktuelle oplog og den højeste prioritet vinder valget, og at gentagelige skrivninger lader applikationer håndtere korte valgperioder transparent. Dernæst undersøger vi skrivebekræftelser og ser på, hvordan du styrer skrivningers holdbarhed på tværs af replikasættet.