Percona ClusterSync 1.0.0 shton kalimin automatik për MongoDB
Percona ClusterSync për MongoDB, mjeti që lëviz të dhënat midis grupimeve MongoDB, ka arritur versionin 1.0.0 me një modalitet të integruar disponueshmërie të lartë aktive-standby. Në një postim në blog të publikuar më 30 shtator 2026, autori Adnan Supic, me një shënim redaktori që i jep meritë Inel Pandzic, shpjegon se deri tani, ClusterSync ishte një pikë e vetme dështimi: nëse hosti, kontejneri ose pod-i që ekzekutonte mjetin dështonte, replikimi ndalonte dhe një operator duhej të vinte re ndërprerjen dhe të rikuperonte procesin manualisht. Lëshimi i ri u lejon operatorëve të ekzekutojnë instanca të shumta kundrejt të njëjtave grupime burimore dhe të synuara, në mënyrë që një instancë standby të marrë kontrollin automatikisht kur ajo aktive dështon.
Mënyra se si funksionon modaliteti i ri është e thjeshtë. Tani mund të ekzekutoni instanca të shumta Percona ClusterSync të drejtuara kah të njëjtat grupime MongoDB burimore dhe të synuara. Instancat koordinohen përmes një qiraje të mbështetur në MongoDB të ruajtur në grupin e synuar, në një bazë të dhënash të quajtur percona_clustersync_mongodb. Saktësisht një instancë mban qiranë dhe është AKTIVE, që do të thotë se ekzekuton replikimin. Pjesa tjetër qëndrojnë STANDBY dhe shikojnë që qiraja të skadojë. Nuk ka koordinator të jashtëm; grupi MongoDB i synuar që tashmë keni vepron si burimi i së vërtetës. Disponueshmëria e lartë është gjithmonë e ndezur dhe kërkon zero ndryshime konfigurimi. Një instancë e vetme thjesht fiton qiranë menjëherë dhe sillet saktësisht si më parë. Nëse doni kalim automatik, filloni një instancë të dytë ose të tretë me të njëjtin burim dhe objektiv, dhe vendosja është kryer.
Tre mekanizma e bëjnë kalimin automatik të sigurt: zgjedhja e bazuar në qira, rrethimi i termit dhe rikuperimi i bazuar në pikën e kontrollit. Zgjedhja e qirasë shmang ndarjen e trurit sepse e gjithë gjendja e koordinimit jeton në bazën e të dhënave percona_clustersync_mongodb në objektiv. Zgjedhja është një shkrim i vetëm atomik me kusht: një instancë e merr qiranë vetëm nëse ajo aktualja ka skaduar, dhe skadimi vlerësohet kundrejt orës së serverit. Dy standby që garojnë nuk mund të fitojnë të dy, dhe mospërputhja e orës midis hosteve ClusterSync është e parëndësishme sepse ora e MongoDB është e vetmja që ka rëndësi. Vetë qiraja është një dokument i vogël me fusha për identifikuesin e qirasë, termin, ID-në e instancës, datën e zgjedhjes dhe kohën e skadimit.
Rrethimi i bazuar në term parandalon një dështim klasik të sistemeve të shpërndara të njohur si shkrim zombie. Fusha e termit është një shenjë rrethimi monotonike që rritet në çdo zgjedhje, çdo ndryshim nga AKTIVE në STANDBY, dhe vuloset në çdo shkrim të pikës së kontrollit që bën AKTIVJA në percona_clustersync_mongodb.checkpoints. Nëse një AKTIVE ngec për shkak të një pauze të grumbullimit të mbeturinave, ndarjes së rrjetit, ose një pod-i të vrarë dhe rifilluar para se qiraja të skadonte, qiraja e saj skadon, një standby promovohet, dhe instanca e vjetër mund të zgjohet dhe të përpiqet të shkruajë sikur asgjë të mos kishte ndodhur. Me rrethimin e termit, ajo aktive zombie mbart një term të vjetëruar, objektivi i refuzon shkrimet e saj të pikës së kontrollit, instanca e rrëzuar e vëren, dhe vetë-ul në STANDBY. Gjendja e re AKTIVE nuk korruptohet kurrë.
Me promovimin, AKTIVJA e re rifillon replikimin nga pika e kontrollit e ruajtur, i njëjti mekanizëm rikuperimi nga dështimi që ClusterSync ka përdorur gjithmonë, tani i aktivizuar automatikisht. Kohët janë fikse në këtë lëshim: TTL i qirasë është 10 sekonda, AKTIVJA rinovon çdo 3 sekonda, dhe çdo instancë rreh zemrën çdo 3 sekonda. Në praktikë, një AKTIVE e vrarë fort zëvendësohet brenda afërsisht TTL-së së qirasë. Një kufi për të ditur: disponueshmëria e lartë mbulon fazën e replikimit të rrjedhës së ndryshimeve, por klonimi fillestar nuk është i rifillueshëm. Nëse AKTIVJA vdes në mes të klonimit, një standby prapë promovohet, zbulon klonimin e ndërprerë gjatë rikuperimit, dhe dështon pastër me një arsye të qartë në regjistrat dhe /status: klonimi fillestar i ndërprerë nga kalimi automatik dhe nuk është i rifillueshëm; filloni një ekzekutim të ri për të riklonuar nga e para. Rikuperimi është një /start i thjeshtë në AKTIVEN e re, e cila rifillon sinkronizimin nga e para. Kalimi automatik hyn në fuqi sapo klonimi përfundon dhe replikimi i vazhdueshëm fillon.
Operimi i një vendosjeje HA është projektuar të jetë i qartë dhe jo hamendje. Çdo instancë mban një dokument gjallërie në percona_clustersync_mongodb.members në objektiv, dhe përgjigjet API përfshijnë një zarf grupi në mënyrë që një operator që godet çdo nyje mund të shohë kush është AKTIVE, instancën që arritët, rolin, dhe listën e plotë të anëtarëve me çdo host, port dhe rol të instancës së gjallë. Nëse dërgoni një komandë operacionale si /start, /pause, ose /finalize te një STANDBY, ajo përgjigjet me HTTP 409 dhe gabim not_active, me të njëjtin zarf në trup, në mënyrë që klienti juaj mund të gjejë menjëherë AKTIVEN dhe të riprovojë atje. Zarfi shfaqet vetëm kur vërehet më shumë se një anëtar i gjallë; një instancë e vetme kthen përgjigje identike bajt për bajt me API-në para-HA, kështu që mjetet ekzistuese vazhdojnë të punojnë të pandryshuara. Pikat fundore /metrics dhe pprof shërbehen në çdo rol. Për pastrim, dy komanda të reja direkte pastrojnë gjendjen HA në objektiv ndërsa asnjë server nuk po ekzekutohet: pcsm reset members dhe pcsm reset lease.
Vëzhgueshmëria është e integruar. Çdo instancë eksporton metrika HA në /metrics, në çdo rol: percona_clustersync_mongodb_ha_active është një matës ku 1 do të thotë AKTIVE dhe 0 do të thotë STANDBY; percona_clustersync_mongodb_ha_term është një matës për termin aktual të qirasë; percona_clustersync_mongodb_ha_role_transitions_total është një numërues për ndryshimet e rolit në këtë instancë. Me këto pak metrika mund të ndërtoni një panel që tregon të gjithë historinë HA me një shikim: një afat kohor i gjendjes së ha_active për instancë shërben si lista e vendosjes dhe tregon kush është AKTIVE dhe që kur, ha_term tregon termin aktual të rrethimit, dhe shkalla e ha_role_transitions_total për instancë punon si detektor i luhatjeve, ku 0 do të thotë i qëndrueshëm dhe një numër në rritje do të thotë problem. Projekti ofron pikërisht një JSON të tillë paneli Grafana në depon e tij si fillestar. Një vendosje e shëndetshme me tre instanca tregon një AKTIVE, dy STANDBY, term 1, dhe asnjë tranzicion. Pasi AKTIVJA vritet, instanca në portin 2243 mori kontrollin, termi i qirasë u rrit në 2, dhe numëruesi i tranzicioneve të saj regjistroi promovimin; AKTIVJA e vjetër u ribashkua si STANDBY.
Përmirësimi nga lëshimi i mëparshëm kërkon një hap manual: gjendja e replikimit nga 0.9.0 nuk është e përputhshme me 1.0.0, kështu që operatorët duhet të ekzekutojnë pcsm reset kundrejt objektivit përpara se të fillojnë replikimin me versionin e ri. Pas kësaj, fillimi i më shumë se një instance është aq i thjeshtë sa ekzekutimi i të njëjtës komandë në një host tjetër: pcsm --source "mongodb://src-mongos:27017" --target "mongodb://tgt-mongos:27017". Kontrolloni /status në cilëndo instancë dhe do të shihni një AKTIVE dhe një STANDBY. Vritni AKTIVEN dhe shikoni standby-n të marrë replikimin nga pika e fundit e kontrollit brenda sekondash. Percona fton raporte defektesh, sugjerime veçorish dhe kontribute kodi, dhe tregon te dokumentacioni PCSM për sinkronizimet e para.
Për ekipet që ekzekutojnë çdo punë replikimi të të dhënave me jetëgjatësi, modeli këtu është i transferueshëm. Ruani gjendjen e zgjedhjes së liderit në vetë sistemin e synuar, rrethoni liderët e vjetër me një numër versioni në mënyrë që shkrimet e vjetruara të refuzohen, dhe ruani progresin në një pikë kontrolli në mënyrë që një pasardhës të mund të rifillojë pa rishikuar nga zero. Metrikat e vëzhgueshmërisë për rolin, termin dhe tranzicionet e kthejnë një kalim automatik nga një incident që duhet zbuluar në një ngjarje që mund ta monitoroni. Organizatat që preferojnë të mos e operojnë vetë këtë logjikë kalimi automatik mund të shikojnë shërbime të menaxhuara të bazave të të dhënave si AEU Data, të cilat ekzekutojnë baza të dhënash me disponueshmëri të lartë, kopje rezervë të automatizuara dhe monitorim në mënyrë që një mjet migrimi të ketë një objektiv të besueshëm kundrejt të cilit të bëjë kalim automatik.