pt-online-schema-change selektiv mund të shkaktojë bllokime në Galera
Një filtër selektiv WHERE në pt-online-schema-change mund të shkaktojë një bllokim në prodhim në një klaster të bazuar në Galera të bazës së të dhënave relacionale me burim të hapur, sipas një postimi të detajuar në blog të publikuar më 28 shtator 2026 nga Corrado Pandiani. Postimi përshkruan një angazhim me klientin me një version të grupuar të kësaj baze të dhënash (shpesh i quajtur klaster Galera) në të cilin një ndryshim rutinë i skemës në internet që kopjonte vetëm rreshtat më të rinj çoi në Kontroll të Rrjedhës së Galera të rëndë, mbingarkesë të madhe dhe një klaster që duhej të rindizej pasi qëndroi i bllokuar për dhjetëra minuta. Shkaku kryesor nuk ishte vetë ndryshimi i skemës, por ndërveprimi midis ndryshimit adaptiv të madhësisë së copave, kopjimit shumë selektiv të rreshtave më të rinj, replikimit të grupuar dhe pikave të kontrollit të InnoDB.
Skenari fillon me një tabelë të madhe që përmban qindra miliona rreshta. Në vend që të rindërtonte të gjithë tabelën, ekipi donte të kopjonte vetëm një nëngrup rreshtash dhe të shtonte një indeks të ri. Komanda dukej kështu: pt-online-schema-change --alter "ADD INDEX idx_status(status)" --where "created_at >= NOW() - INTERVAL 30 DAY" D=test,t=events --execute --force. Me fjalë të thjeshta, pt-online-schema-change (pt-osc) është një mjet që ndryshon strukturën e një tabele ndërsa tabela origjinale vazhdon të shërbejë trafikun, dhe opsioni --where e kufizon punën në rreshtat, data e created_at e të cilëve bie brenda 30 ditëve të fundit. Kjo qasje është e zakonshme kur të dhënat historike mund të injorohen, vetëm regjistrimet aktive kërkojnë modifikim, ose një migrim ndahet në faza për të reduktuar kohën totale.
Normalisht, faza e kopjimit e pt-osc rregullon madhësinë e çdo cope rreshtash për ta mbajtur punën afër një kohe ekzekutimi të konfiguruar, me një parazgjedhje prej 0.5 sekondash. Nëse copat përfundojnë shumë shpejt, mjeti rrit madhësinë e copës tjetër; nëse copat ngadalësohen, ai e zvogëlon madhësinë. Ky ndryshim adaptiv i madhësisë së copave funksionon mirë në tabela me densitet relativisht uniform të rreshtave, sepse çdo copë përmban një përzierje të ngjashme rreshtash për t'u kopjuar dhe rreshtash për t'u anashkaluar. Problemi shfaqet kur shumica e rreshtave të skanuar hidhen poshtë nga një kusht selektiv --where. Në shembull, tabela kishte 1 miliard rreshta: 990 milionë nuk përputheshin me filtrin dhe vetëm 10 milionë përputheshin. Rreshtat përputhës ndodheshin në fund të indeksit të grupuar, sepse vlerat e created_at rriteshin në hap me çelësin primar dhe kufijtë e çelësit primar kombinoheshin me kushtin WHERE. Për një kohë të gjatë, pt-osc skanonte copa ku pothuajse çdo rresht refuzohej, duke e bërë operacionin e kopjimit jashtëzakonisht të shpejtë. Algoritmi adaptiv e interpretoi atë shpejtësi si "copat janë shumë të vogla" dhe vazhdoi të rriste madhësinë e copës. Në kohën kur skanimi arriti rreshtat e parë përputhës, madhësia e copës ishte rritur në mënyrë dramatike, kështu që në vend që të kopjonte disa mijëra rreshta, pt-osc mund të kopjonte papritmas qindra mijëra apo edhe një milion rreshta në një transaksion të vetëm.
Kur ai transaksion i madh godet një klaster Galera, problemi kalon nga një skanim i qetë në një stuhi replikimi. Galera është një teknologji replikimi sinkron që mban disa nyje të bazës së të dhënave identike, dhe ajo replikon çdo copë të kopjuar si një grup shkrimesh, i cili është grupi i ndryshimeve të rreshtave të dërguara në nyjet e tjera. Transaksionet shumë të mëdha prodhojnë grupe shkrimesh shumë të mëdha, faza të gjata certifikimi (procesi ku nyjet kontrollojnë që shkrimet të mos bien ndesh), radhë të shtuara aplikimi, latencë më të madhe replikimi dhe përfundimisht aktivizim të Kontrollit të Rrjedhës. Kontrolli i Rrjedhës është mekanizmi i integruar i Galera për të ndaluar shkrimet në një nyje të shpejtë kur nyjet e tjera mbeten prapa. Sapo fillon, xhiroja e klasterit bie ndjeshëm, commit-et e aplikacionit fillojnë të presin, dhe në raste ekstreme klasteri duket pothuajse i ngrirë derisa çdo nyje të ketë aplikuar plotësisht transaksionin e madh. Postimi vëren se ironikisht algoritmi adaptiv, i projektuar për të optimizuar xhiros, krijon pikërisht modelin e ngarkesës që Galera nuk e pëlqen më shumë.
InnoDB, motori i parazgjedhur i ruajtjes së bazës së të dhënave relacionale me burim të hapur, vuan gjithashtu. Sapo filluan të përpunohen copat e para të mëdha, regjistri i gabimeve i nyjës shkruese tregoi një paralajmërim si "[Warning] [MY-014084] [InnoDB] Threads are unable to reserve space in redo log ... Consider increasing innodb_redo_log_capacity." Regjistri redo është një regjistër ndryshimesh i përdorur për t'u rikuperuar pas një përplasjeje, dhe kur arrin një transaksion shumë i madh, thread-et e shkrimit nuk mund të gjejnë hapësirë të mjaftueshme të lirë sepse konsumatori log_checkpointer po mbetet prapa. Në praktikë kjo e detyron serverin të aktivizojë pikat e kontrollit më shpesh dhe në një shkallë më të madhe, duke shtuar mbingarkesë. Pasi Galera replikoi grupin e shkrimeve në nyjet e tjera, i njëjti lloj mesazhi u shfaq në ato nyje gjatë fazës së aplikimit. Simptomat tipike përfshijnë përqindjen e Kontrollit të Rrjedhës që rritet me shpejtësi, një wsrep_local_recv_queue në rritje (radha e shkrimeve që presin të aplikohen lokalisht), vonesë të lartë replikimi, commit-e të aplikacionit që presin, përdorim më të lartë të CPU-së, rritje të mëdha në kohën e aplikimit të transaksionit dhe pika kontrolli më të shpeshta të InnoDB në të gjitha nyjet. Ndryshimi i skemës mund të përfundojë akoma, por trafiku i prodhimit mund të ndikohet rëndë; në rastin më të keq të përshkruar, klasteri u bllokua dhe duhej të rindizej.
Rregullimi i parë dhe më efektiv i propozuar është të çaktivizoni ndryshimin adaptiv të madhësisë së copave sa herë që përdoret një klauzolë selektive --where. Në vend që të rrisni vazhdimisht madhësitë e copave, mbajini ato fikse gjatë gjithë operacionit duke përfshirë --chunk-time = 0 dhe --max-flow-ctl = 0 në komandë. Vendosja e --chunk-time në zero e ndalon pt-osc që të rregullojë automatikisht madhësinë e copës, kështu që kohët e pyetjeve ndryshojnë por madhësitë e copave të pyetjeve jo. Një alternativë është të specifikoni një vlerë për --chunk-size në mënyrë eksplicite dhe të hiqni --chunk-time. Me algoritmin adaptiv të anashkaluar, ekzekutimi i copës bëhet i parashikueshëm, madhësia e transaksionit mbetet e kufizuar dhe Galera nuk merr kurrë grupe shkrimesh të papritura masive. Ndryshimi i përgjithshëm i skemës mund të zgjasë pak më shumë, por stabiliteti i klasterit përmirësohet në mënyrë dramatike, që zakonisht është kompromisi i preferueshëm në prodhim.
Një parametër tjetër për t'u marrë parasysh është --max-flow-ctl. Me --max-flow-ctl=PCT, pt-osc kontrollon periodikisht wsrep_flow_control_paused, përqindjen e kohës që nyja ka kaluar në pauzë për kontrollin e rrjedhës, dhe automatikisht ndalon kopjimin e rreshtave sa herë që ajo përqindje tejkalon pragun, duke rifilluar sapo klasteri bie përsëri nën të. Vendosja e --max-flow-ctl në zero (ose shumë afër tij, si p.sh. 1) e bën pt-osc të ndalojë kopjimin e rreshtave në shenjën e parë që ndonjë nyje ka hyrë në kontrollin e rrjedhës, në vend që të tolerojë pak kohë pauze para se të tërhiqet. Analiza e quan këtë qëndrimin më të sigurt të mundshëm për një klaster prodhimi, veçanërisht një që tashmë tregon paralajmërime për vonesë të checkpointer-it, sepse çdo presion shtesë shkrimi nga kopjimi i copëzuar i migrimit mund ta shtyjë një nyje tashmë në vështirësi në një bllokim shumë më të madh. Pragu afër zeros e shkëmben shpejtësinë e migrimit me sigurinë, duke e lejuar mjetin t'i referohet kapacitetit në kohë reale të klasterit dhe të avancojë vetëm kur nuk ka vërtet kontestim. Për ngarkesa kritike të prodhimit të ndjeshme ndaj vonesës, një ndryshim skeme më i ngadaltë por i sigurt është më i mirë se një i shpejtë që rrezikon një ngrirje shkrimesh në të gjithë klasterin.
Një levë e lidhur është --chunk-index. Si parazgjedhje, pt-online-schema-change e ndan tabelën në copa duke përdorur çelësin primar ose indeksin unik më të përshtatshëm, prandaj kufijtë e copave në rastin e klientit ndiqnin të njëjtën kolonë monotonike në rritje si created_at dhe prodhonin shtrirjen e gjatë të copave pothuajse bosh. Nëse tabela ka një indeks dytësor, renditja e të cilit nuk është e ndërlidhur me created_at, detyrimi i mjetit të ndajë në copa mbi atë indeks me --chunk-index=idx_name mund t'i shpërndajë rreshtat përputhës dhe jo përputhës në mënyrë më të barabartë nëpër copa, kështu që algoritmi adaptiv nuk sheh kurrë shtrirjen e zgjatur me densitet të ulët që e çon madhësinë e copës në nivele të pasigurta. Megjithatë, postimi paralajmëron se kjo nuk është zëvendësim për --chunk-time=0 dhe --max-flow-ctl, sepse një indeks ndarjeje i zgjedhur keq mund të dëmtojë performancën dhe pak tabela kanë një indeks të përshtatshëm që është edhe mjaft selektiv për t'u ndarë në copa edhe i pandërlidhur me kushtin --where. Në praktikë, --chunk-index është një optimizim dytësor, specifik për tabelën.
Një opsion i tretë është të shmangni plotësisht klauzolën --where dhe ta ndani detyrën në dy faza. Së pari, ekzekutoni pt-archiver për të fshirë rreshtat që nuk nevojiten më, pastaj ekzekutoni pt-online-schema-change për të ndryshuar tabelën. Kjo procedurë me dy hapa shmang çdo rrezik që buron nga shpërndarja jo uniforme e rreshtave përputhës. Postimi përfundon se pt-online-schema-change mbetet një nga mjetet më të mira për migrimet e skemave në internet, por kur përdorni --where për të kopjuar vetëm një nëngrup të vogël rreshtash në një klaster të bazuar në Galera të bazës së të dhënave relacionale me burim të hapur, ndryshimi adaptiv i madhësisë së copave mund të gjenerojë pa dashje transaksione të mëdha që shkaktojnë Kontroll të tepruar të Rrjedhës së Galera dhe bllokojnë përkohësisht klasterin. Mbajtja e madhësive të copave fikse e eliminon atë lak reagimi, duke prodhuar sjellje më të qetë replikimi dhe duke reduktuar rrezikun operacional. Rregullime të tjera janë gjithashtu të disponueshme, dhe mësimi themelor është se ndonjëherë parashikueshmëria është një optimizim më i mirë se agresiviteti. Për ekipet që preferojnë ta jashtëzojnë këtë barrë operacionale, ofruesit e menaxhuar të bazave të të dhënave si AEU Data (aeu-data.com) ofrojnë monitorim, kopje rezervë të automatizuara dhe konfigurim me disponueshmëri të lartë që mund t'i ndihmojnë operatorët të zbulojnë dhe të rikuperohen nga lloji i bllokimit të replikimit të përshkruar këtu.