Përfundon mbështetja për grupimin e bazës së të dhënave me kod të hapur, duke imponuar zgjedhje për mirëmbajtjen
Grupimi Galera i bazës së të dhënave relacionale me kod të hapur ka arritur në fund të rrugëtimit të tij aktual të zhvillimit dhe mirëmbajtjes, sipas Percona, duke e vendosur mbështetjen gjatë incidenteve dhe korrigjimet e ardhshme në qendër të një vendimi operacional për ekipet e bazave të të dhënave. Në një artikull të datës 8 tetor 2026, Valeria Bogatyreva raporton se ofruesi i bazës së të dhënave, i cili bleu Codership në maj 2025, caktoi 30 shtatorin 2026 si afatin e përfundimit të mbështetjes për të gjitha versionet aktuale të grupimit Galera të asaj baze të dhënash. Sipas kësaj politike, përfundojnë zhvillimi, mirëmbajtja dhe publikimet binare, pra paketat e softuerit të gatshme për instalim.
Një grupim është një grup serverësh të bazës së të dhënave, të quajtur nyje, që punojnë së bashku. Galera ofron replikimin, mekanizmin që i mban të bashkërenduara të dhënat e tyre. Vetë afati nuk e ndryshon mënyrën si funksionon një grupim i instaluar: më 1 tetor ai duhet të sillet si një ditë më parë. Ajo që ndryshon është rruga për t'ia kaluar problemin ekspertëve dhe për të marrë më pas një korrigjim të mundshëm të softuerit. Ky dallim ka rëndësi, sepse një bazë të dhënash mund të vazhdojë të funksionojë edhe kur nuk ekzistojnë më marrëveshjet e nevojshme për ta rikthyer në punë pas defektit të ardhshëm të vështirë.
Diagnostikimi, jo vetëm replikimi, mund të përcaktojë kohëzgjatjen e një ndërprerjeje. Bogatyreva citon incidente që i atribuohen ekipit të Codership, ku kërkesat grumbulloheshin pa gabime të dobishme në regjistrat e aktivitetit, pra shënimet që softueri lë për veprimtarinë e tij. Një ndërprerje zgjati njëzet minuta dhe përfundoi vetëm pasi dikush zgjodhi një nyje për ta ndalur. Një rast tjetër lidhej me kontrollin e rrjedhës, mekanizmin që ngadalëson punën hyrëse kur anëtarët e grupimit nuk arrijnë të mbajnë ritmin: veprimet e shkrimit tejkalonin afatin e pritjes, ndërsa numëruesi i mesazheve të dërguara të kontrollit të rrjedhës, që numëron këto mesazhe, mbetej në 0. Prandaj sinjali i pritshëm nuk e zbuloi ngecjen.
Percona argumenton se këto defekte shpesh e kanë origjinën jashtë replikimit të bashkësive të shkrimeve të Galera, i cili shpërndan ndryshimet e bëra nga transaksionet e bazës së të dhënave. Shembujt përfshijnë flashcache, një komponent për ruajtjen e përkohshme të të dhënave në sistemin e ruajtjes; një rresht konfigurimi të opsioneve të ofruesit të replikimit, vlera e të cilit ishte mbishkruar; DNS, shërbimin që gjen adresat nga emrat, që e lidhte emrin me ndërfaqen e gabuar të rrjetit; dhe një mur mbrojtës që lejonte komunikimin vetëm në një drejtim. Në një rast tjetër, një ekip që po hetonte rinisje të përsëritura në Kubernetes, softuer për bashkërendimin e kontejnerëve të aplikacioneve, u detyrua të lexonte kodin burimor të operatorit të tij, automatizimit që administron bazën e të dhënave. Këta shembuj shpjegojnë pse koha mesatare e rikthimit në punë, pra koha e nevojshme për të rivendosur shërbimin, mund të varet më shumë nga gjetja e shkakut sesa nga ndreqja e tij.
Rruga e migrimit që rekomandohet në kuadër të ofertës së ofruesit për baza të dhënash për ndërmarrje është grupimi Galera i bazës së tij alternative të të dhënave. Kjo nuk është thjesht një marrëveshje tjetër mbështetjeje për të njëjtën bazë të dhënash. Siç vëren Percona, baza alternative e të dhënave ka tabela të ndryshme të sistemit, të cilat ruajnë informacion të brendshëm të bazës së të dhënave, dhe një fjalor të dhënash thelbësisht të ndryshëm, pra katalogun që përshkruan objektet e bazës së të dhënave. Shënimet e migrimit të bazës alternative të të dhënave kërkojnë gjithashtu rikrijimin sistematik të privilegjeve të përdoruesve, pra lejeve që kontrollojnë qasjen. Për organizatat që duan të qëndrojnë te baza origjinale e të dhënave, këto dallime e bëjnë zgjedhjen një vendim arkitekturor, jo një rinovim kontrate.
Percona paraqet dy alternativa, të dyja mundësi tregtare nga një furnizues që ka interes në këtë vendim. Oferta e saj për mbështetjen e bazës së të dhënave mbulon një grupim ekzistues Galera të bazës origjinale të të dhënave pa migrim, zëvendësim platforme ose rindërtim privilegjesh. Percona reklamon inxhinierë të nivelit të lartë për bazën origjinale të të dhënave, të disponueshëm 24x7x365 përmes ekipeve që punojnë në zona të ndryshme kohore, duke ofruar si vlerësim fillestar të incidenteve, ashtu edhe këshillim. Ky këshillim mbulon optimizimin e ndërfaqes së replikimit, pra rregullimin e ndërfaqes ndërmjet bazës origjinale të të dhënave dhe Galera; strategjinë DDL, pra planifikimin e ndryshimeve në strukturën e bazës së të dhënave; shpërndarjen e shkrimeve; dhe projektimin e kuorumit, pra përcaktimin se si një numër i mjaftueshëm nyjesh bien dakord që grupimi mund të vazhdojë të funksionojë. Niveli i saj Premium reklamon përgjigje fillestare të parashikuara në kontratë brenda vetëm 15 minutash për incidente të nivelit 1 të rëndësisë. Një angazhim për përgjigjen fillestare nuk është garanci për kohën e riparimit.
Mundësia tjetër është shpërndarja e mirëmbajtur e Percona për grupime, e cila kombinon shpërndarjen e Percona të serverit origjinal të bazës së të dhënave me degëzimin e vet të bibliotekës Galera, një version i mirëmbajtur veçmas dhe i disponueshëm në një depo publike. Percona e përshkruan atë si të përputhshme me edicionin e komunitetit të bazës origjinale të të dhënave dhe thotë se skemat e bazës së të dhënave, pra përkufizimet e tabelave dhe marrëdhënieve të tyre, tabelat e sistemit dhe llogaritë e përdoruesve kalojnë pa ndryshime. Ajo thotë gjithashtu se sjellja e ndërfaqes së replikimit, mjetet, lidhësit dhe ekosistemi më i gjerë mbeten të njohur. Një udhëzues publik migrimi me dhjetë hapa mund të ndiqet në mënyrë të pavarur. Këto janë pretendime të Percona për përputhshmërinë, jo prova se çdo instalim mund të zhvendoset pa verifikim.
Argumenti i Percona në favor të shpërndarjes së saj të mirëmbajtur për grupime mbështetet në mirëmbajtjen e vazhdueshme të shtresës së grupimit. Ajo identifikon punën për transferimin rritës të gjendjes (IST), i cili dërgon ndryshimet që një nyje në rikuperim ka humbur, dhe transferimin e një kopjeje të plotë të gjendjes (SST), i cili dërgon një kopje të plotë të të dhënave. Fusha të tjera përfshijnë përjashtimin e nyjeve, pra heqjen e një anëtari nga grupimi; kontrollin e rrjedhës; dhe DDL ndërkohë që kryhen njëkohësisht veprime shkrimi. Kompania u referohet shënimeve publike tremujore të publikimeve me identifikues çështjesh Jira, referencat që përdoren për të gjurmuar korrigjime të veçanta. Burimi i ofruar përfshin një imazh të tabelës së publikimeve, por nuk e bën të lexueshme përmbajtjen e tij, ndaj nga ai tekst nuk mund të përcaktohen korrigjime ose identifikues të veçantë.
Sipas Percona, ky ritëm publikimesh shtrihet që nga viti 2012 në versionet 5.5, 5.6, 5.7, 8.0 dhe tani 8.4, ndërsa dega 8.0 vazhdon të marrë publikime paralelisht me të. Kompania thotë se gati 4 000 instanca në sisteme pritëse të shpërndarjes së saj të mirëmbajtur për grupime raportuan telemetri, pra informacion përdorimi të dërguar automatikisht, jashtë Kubernetes gjatë 90 ditëve të mëparshme. Veçmas, ajo raporton se Operator i shpërndarjes së mirëmbajtur për grupime funksionon në mijëra instalime të tjera Kubernetes. Këto janë shifra të raportuara nga furnizuesi, jo një numërim i pavarur i përdoruesve ose një matje e besueshmërisë. Percona përmend gjithashtu punën e fundit për inspektimin e memories së përkohshme të replikimit, pra shqyrtimin e memories së Galera për ndryshimet e replikuara, dhe replikimin ndërmjet vendndodhjeve në Operator, i cili bashkërendon kopjet në vendndodhje të ndryshme.
Për klientët që përdorin shërbimin e saj të migrimit, Percona përshkruan një mjedis testimi të sistemit të synuar dhe një krahasim të sjelljes së ndërfaqes së replikimit me grupimin ekzistues. Qëllimi është të vëzhgohet se si zëvendësimi përballon të njëjtat defekte përpara se të merret vendimi përfundimtar. Shërbimi përfshin gjithashtu një plan të dokumentuar rikthimi, një kalim të planifikuar me mbështetje jashtë orarit të punës dhe një auditim të gjendjes disa javë pas fillimit të përdorimit në prodhim. Këto janë kritere të dobishme vlerësimi për çdo propozim migrimi: përputhshmëria duhet kontrolluar kundrejt ngarkesës reale të punës dhe sjelljes gjatë defekteve, me një mënyrë të përcaktuar rikthimi nëse zhvendosja dështon.
Bazat e menaxhuara të të dhënave dhe monitorimi i AEU Data janë të rëndësishme për këtë sfidë operacionale, megjithëse klientët duhet të verifikojnë marrëveshjet e mbështetjes dhe mirëmbajtjes për softuerin e tyre të veçantë të grupimit. Mësimi më i gjerë është që të ndahen dy pyetje: kush do të ndihmojë në diagnostikimin e ndërprerjes së ardhshme dhe kush do të mirëmbajë kodin që ka nevojë për korrigjim? Mbështetja për një grupim ekzistues Galera të bazës origjinale të të dhënave mund të japë kohë për të vepruar; migrimi drejt një shpërndarjeje të mirëmbajtur adreson boshllëkun në mirëmbajtjen e softuerit. Asnjëra nuk i bën ndërprerjet të pamundura, por lënia pa përgjigje e të dyja pyetjeve e kthen një diagnostikim të vështirë në një ekspozim afatgjatë ndaj rrezikut operacional.