Managed MongoDB, med automatisk failover gennem din load balancer

MongoDBs egne replica sets ved allerede, hvordan de overlever en fejl — det er hele pointen med at køre et. Det de ikke giver dig gratis, er et stabilt sted for din app at forbinde til, som bliver ved med at virke hen over et valg, og nogen der holder øje med flåden, så et nedbrudt medlem ikke bare bliver siddende. Suble drifter nu den flåde for dig.

Vælg MongoDB i cluster-guiden, vælg et antal noder, og du får et rigtigt replica set — provisioneret, forbundet til en load balancer der altid finder den nuværende primary, og klar til brug på få minutter.

Sådan virker det

Et MongoDB-cluster er N medlems-VM'er, der hver kører mongod med en fuld lokal kopi af data — shared-nothing, ingen delt disk nogen afhænger af. Medlem et bootstrapper replica settet (rs.initiate()); resten tilslutter sig med rs.add(), og MongoDB streamer hver skrivning til dem over sin egen replikeringsprotokol.

• MongoDB vælger selv sin primary. Der er ingen separat koordinator at drifte — et replica sets medlemmer stemmer allerede om, hvem der er primary, og vælger automatisk en ny i det øjeblik den nuværende ikke kan nås. Suble blander sig ikke i det; den sørger bare for, at medlemmerne kører og kan nå hinanden.
• Et stabilt skrive-endpoint. Load balanceren for dit cluster udstiller et :27017-endpoint, der altid ruter til det medlem, der *lige nu* er primary. Et lille sundhedstjek på hvert medlem rapporterer dets rolle, og i det øjeblik replica settet vælger en ny, følger endpointet med — din connection string ændrer sig aldrig.
• Et load-balanceret læse-endpoint. Et andet :27018-endpoint spreder læsninger hen over de sekundære, så rapportering eller analyse-forespørgsler ikke konkurrerer med dine skrivninger.
• Tre eller flere noder. Et replica set har brug for et reelt flertal for at vælge en primary sikkert, så managed MongoDB-clusters starter ved tre medlemmer.

Justerbare indstillinger, anvendt som en rullende genstart

Fanen Indstillinger for dit cluster udstiller de mongod-parametre, det faktisk kan betale sig at justere — WiredTiger cache-størrelse, den maksimale grænse for indkommende forbindelser, tærsklen for langsomme operationer, log-detaljeringsgrad — valideret mod fornuftige grænser, så der ikke er nogen måde at konfigurere et cluster til en ødelagt tilstand.

Hver eneste af dem er en config-fil-indstilling, så at anvende en ændring betyder at skrive den nye mongod.conf og genstarte processen for at den træder i kraft. Suble gør det som en rullende genstart — sekundære først, en ad gangen, mens den venter på at hver fuldt tilslutter sig replica settet igen, før den går videre til den næste, og den nuværende primary altid til sidst. Din app ser den samme korte genforbindelse, som et primary-valg normalt giver, og intet andet.

Hvad er det næste

Dette er den første udgivelse af managed MongoDB, og den dækker kernen i at drifte et: opret et cluster, få et rigtigt replica set, og forbind gennem et endpoint der overlever en failover. Nogle ting Postgres og Redis allerede har hos Suble er stadig på vej for MongoDB — skalering af nodeantal, tilpasning af medlemsplan, rullende OS-opdateringer, database-/brugerstyring fra dashboardet, og backups til din egen S3-bucket. Vi annoncerer hver enkelt, efterhånden som den udkommer.

Opret en på et minut

I dashboardet: Clusters → New cluster → Database → MongoDB, vælg tre eller flere noder, vælg en størrelse, og opret. Få minutter senere har du et kørende replica set. Afslør root-adgangskoden på cluster-siden, kopier connection string som den er (den har allerede directConnection=true sat), og peg din app mod den.