MongoDB arbiters mund të bllokojnë shkrimet dhe të dobësojnë qëndrueshmërinë
MongoDB arbiters mund të ndihmojnë një replica set të zgjedhë një primary, por nuk mund të ruajnë, replikojnë ose konfirmojnë të dhëna. Percona thotë se rastet e saj të mbështetjes tregojnë se ky dallim mund ta kthejë një deployment prodhimi që duket i shëndetshëm në një sistem që ngadalëson shkrimet, arrin timeout ose kryen rollback të rekordeve të konfirmuara.
Një replica set është një grup serverësh MongoDB që mbajnë kopje të të njëjtave të dhëna. MongoDB e prezantoi arbiter në versionet e saj të hershme në vitin 2010, në mënyrë që operatorët të mund të krijonin një numër tek votash pa paguar për një server tjetër që mban të dhëna. Gjatë një zgjedhjeje, procesit që përcakton se cili anëtar bëhet primary, arbiter jep një votë. Ai nuk zbaton oplog, rekordin e renditur të ndryshimeve të databazës në MongoDB, dhe nuk e ka përmirësuar kurrë qëndrueshmërinë e të dhënave.
Ky kufizim u bë më i rëndësishëm gjatë epokave të MongoDB 3.x dhe 4.x. WiredTiger u bë storage engine i parazgjedhur, ndërsa protokolli i replica set kaloi në pv1. MongoDB gjithashtu i bëri readConcern dhe writeConcern, konfigurime që kontrollojnë sa fuqishëm duhet të konfirmohen leximet dhe shkrimet, elemente qendrore të qëndrueshmërisë. Change streams, transaksionet me shumë dokumente, flow control dhe default read and write concerns në nivel cluster-i mbështeten të gjitha në forma të marrëveshjes së shumicës. Një arbiter numërohet për shumicën e zgjedhjes, por jo për shumicën e anëtarëve që mbajnë të dhëna, e cila nevojitet për të konfirmuar shkrimet ose për të avancuar majority commit point, ndryshimin më të fundit të konfirmuar në mënyrë të qëndrueshme nga një numër i mjaftueshëm replicas.
Një rast mbështetjeje nga Percona përfshinte një sharded cluster, i cili i ndan të dhënat mes disa replica sets. Ai kishte tre shards dhe një config-server replica set. Çdo shard vendoste tre anëtarë që mbanin të dhëna në një data center, tre në një të dytë dhe një arbiter në një vendndodhje të tretë. Kjo krijonte shtatë anëtarë votues për çdo shard, gjashtë prej të cilëve mbanin të dhëna. Në vend të kësaj, config servers përdornin gjashtë anëtarë që mbanin të dhëna, nga dy në secilën prej tri vendndodhjeve dhe pa arbiter.
Pasi një data center dështoi, zgjedhjet përfunduan dhe çdo shard zgjodhi një primary të ri. Më pas, throughput i shkrimeve ra nga afërsisht 3,000–4,000 operacione në sekondë në secilin shard në rreth 50–75. Aplikacionet lidheshin përmes mongos, query router i MongoDB, dhe përdornin `{ w: 2, j: true }`, që kërkonte konfirmim nga dy anëtarë me ruajtje të qëndrueshme në journal. Tre anëtarë që mbanin të dhëna dhe arbiter mbetën të arritshëm në secilin shard.
Problemi ishte një operacion i brendshëm dhe jo write concern i zgjedhur nga aplikacioni. Disa detyra të sharded cluster, duke përfshirë collection-routing refreshes, lëshojnë një local no-op, një operacion që nuk ndryshon asnjë të dhënë të përdoruesit, me majority write concern. Me shtatë votues dhe një arbiter, `writeMajorityCount` ishte katër. Arbiter mund të votonte, por nuk mund ta konfirmonte atë shkrim, ndaj tre anëtarët e mbetur që mbanin të dhëna nuk mund ta përmbushnin kërkesën. majority commit point ndaloi së avancuari dhe routing refreshes prisnin një timeout të hardkoduar prej rreth 60 sekondash. Config servers e shmangën të njëjtin dështim, sepse katër nga gjashtë anëtarët e tyre që mbanin të dhëna mbijetuan, aq sa duhej për shumicën e tyre.
Një rast i dytë tregoi pse një arbiter nuk mund ta lehtësojë flow control, mekanizmin e MongoDB për ngadalësimin e primary kur replicas mbeten shumë prapa. replica set kishte katër anëtarë që mbanin të dhëna, të ndarë në mënyrë të barabartë mes dy data centers, si edhe një arbiter në një vendndodhje të tretë. Dy secondaries në një vendndodhje mbetën deri në rreth 1,000 sekonda prapa gjatë shkrimeve intensive që gjeneruan një oplog të madh në primary. Primary dhe secondary i tij lokal mbetën të përditësuar, por avancimi i majority commit point kërkonte tre nga katër anëtarët që mbanin të dhëna. Me vetëm dy të përditësuar, flow control ngadalësoi shkrimet në primary, edhe pse arbiter vazhdonte të ishte i disponueshëm.
Shembulli më serioz përdorte një topology Primary-Secondary-Arbiter, që zakonisht shkurtohet në PSA. Primary, N1, kishte election priority 2 dhe aplikacioni përdorte `w: 1`, që do të thoshte se një shkrim mund të konfirmohej pasi të arrinte vetëm një anëtar. Kur N1 pësoi crash, secondary, N2, u bë primary dhe pranoi shkrime të konfirmuara për rreth një orë. Më pas N1 u rikthye, por përpara se të kishte arritur përditësimin, N2 doli jashtë funksionimit. N1 dhe arbiter formuan një shumicë votuese, duke i lejuar N1 të bëhej primary pavarësisht se i mungonin ndryshimet e asaj ore.
Kur N2 u ribashkua, oplog i tij përmbante një histori më të re, por konfliktuese, përtej pikës së fundit të përbashkët me N1. MongoDB kreu rollback të këtyre ndryshimeve për t'u përputhur me primary e zgjedhur. Dokumentet mund të rikuperoheshin vetëm sepse MongoDB i kishte ruajtur si skedarë BSON, formati i saj binar i dokumenteve, në direktorinë rollback nën `dbPath`, vendndodhjen e ruajtjes së databazës. Ato nuk ishin replikuar kurrë diku tjetër. Një anëtar i tretë që mbante të dhëna dhe kishte mbetur i përditësuar mund të kishte qenë përpara N1 dhe i kualifikuar për t'u bërë primary, megjithëse çdo shkrim i fundit që nuk kishte arritur tek ai mund t'i nënshtrohej përsëri rollback.
Udhëzimet e dokumentuara të MongoDB për deployment pasqyrojnë këto rreziqe. Për sets me tre anëtarë rekomandohet Primary-Secondary-Secondary, ose PSS. PSA paraqitet si një alternativë me kosto më të ulët, me redundancë dhe fault tolerance më të dobëta, sepse ekzistojnë vetëm dy kopje të plota të të dhënave. Një arbiter nuk duhet të ndajë të njëjtin host me një primary ose secondary, sepse dështimi i një host-i do të eliminonte njëkohësisht si të dhënat, ashtu edhe një votë. Disa arbiters gjithashtu cenojnë majority writes të besueshme. Duke filluar nga MongoDB 5.3, mbështetja për disa arbiters në një replica set është çaktivizuar si parazgjedhje, sepse një set mund të pranonte shkrime pa pasur mjaftueshëm secondaries për t'i replikuar ato.
Arbiters gjithashtu kufizojnë transaksionet. Një shard key nuk mund të ndryshohet përmes një transaksioni kur replica set përmban një arbiter. Për shkak se arbiters nuk mund të kryejnë operacionet e të dhënave që nevojiten për transaksionet me shumë shards, një transaksion që përfshin disa shards do të japë error dhe do të abortojë nëse ndonjë operacion lexon nga ose shkruan në një shard që përmban një të tillë. MongoDB Atlas nuk mbështet arbiters në asnjë tier.
Mësimi praktik është që disponueshmëria e votimit dhe qëndrueshmëria e të dhënave të vlerësohen veçmas. Një ekran statusi mund të tregojë një zgjedhje të suksesshme, ndërkohë që databaza nuk mund të avancojë majority commits, të ecë në një hap me replikimin ose të ruajë shkrimet e konfirmuara. Ekipet duhet të monitorojnë replication lag, write latency dhe lëvizjen e majority commit point, të testojnë dështimet e plota të vendndodhjeve dhe të zgjedhin write concerns që pasqyrojnë rëndësinë e të dhënave. Për organizatat që vendosin se ku t'i operojnë këto sisteme, AEU Data ofron cloud dhe infrastrukturë të dhënash evropiane, ndërsa projektimi i mirë i replica set mbetet një përgjegjësi operacionale.
Zëvendësimi i një arbiter me një anëtar që mban të dhëna kushton më shumë kapacitet, por shton një kopje tjetër të aftë për të konfirmuar dhe ruajtur shkrimet. Rastet e Percona tregojnë se anëtari votues më i lirë mund të shkaktojë një kosto më të madhe operacionale kur shkrimet bllokohen, transaksionet dështojnë ose rekordet mbijetojnë vetëm në skedarët rollback.