Parametrat kryesorë që shpejtojnë Percona ClusterSync për MongoDB
Percona ka publikuar një udhëzues të detajuar për rregullimin e Percona ClusterSync për MongoDB (PCSM), një mjet sinkronizimi që kopjon të dhëna nga një klaster burim MongoDB në një klaster të synuar. Postimi në blog, i shkruar nga Ivan Groenewold dhe Adnan Supic dhe i publikuar më 1 tetor 2026, shpjegon se cilët parametra kanë rëndësi për dy fazat e procesit të sinkronizimit dhe sugjeron vlera fillestare për testim. PCSM fillimisht krijon një pikënisje të qëndrueshme duke klonuar koleksionet dhe indekset ekzistuese, ndërsa në të njëjtën kohë kap ndryshimet e burimit përmes rrjedhave të ndryshimeve të MongoDB, një furnizim në kohë reale i operacioneve të bazës së të dhënave. Pasi kopjimi fillestar të përfundojë, PCSM aplikon ato ndryshime të kapura derisa objektivi të arrijë burimin. Ndryshimet më të fundit arkitekturore prezantojnë disa parametra të rinj për të përmirësuar shpejtësinë e klonimit fillestar dhe xhiron e replikimit të vazhdueshëm.
Autorët këshillojnë rregullimin gradual dhe vëzhgimin e CPU-së, diskut, përdorimit të rrjetit, numrit të lidhjeve dhe vonesës së replikimit të burimit dhe objektivit pas çdo ndryshimi. Ata rekomandojnë përdorimin e Percona Monitoring and Management (PMM), një mjet monitorimi, për të identifikuar pengesat, dhe të mbajnë nën vëzhgim të njëjtat metrika për hostin që ekzekuton PCSM. Kjo qasje e matur parandalon që një ndryshim rregullimi të ngopë ruajtjen ose lidhjet.
Faza fillestare e klonimit ndikohet kryesisht nga paralelizmi i koleksioneve, punëtorët e leximit dhe futjes, madhësia e segmentit dhe madhësia e grupit të leximit. Këto vlera konfigurohen kur fillon procesi PCSM. Paralelizmi i koleksioneve kontrollohet nga clone-num-parallel-collections, i cili parazgjedhjet në 2, një cilësim konservativ që kufizon sa koleksione klonohen në të njëjtën kohë. Percona rekomandon rritjen e tij kur burimi ka shumë koleksione dhe kur si burimi ashtu edhe objektivi kanë kapacitet të lirë CPU dhe disku. Një pikënisje e arsyeshme është 4 koleksione paralele për bërthamë CPU, pastaj testoni vlera më të larta për sa kohë që objektivi nuk është i ngopur. Paralelizmi i tepërt do të rrisë kontestin e diskut dhe përdorimin e lidhjeve.
Faza e klonimit gjithashtu përdor clone-num-read-workers dhe clone-num-insert-workers. Parazgjedhja për punëtorët e leximit është max(NumCPU/4, 1), dhe parazgjedhja për punëtorët e futjes është NumCPU shumëzuar me 2. Punëtorët e leximit marrin dokumente nga burimi, ndërsa punëtorët e futjes shkruajnë grupe në objektiv. Rritni punëtorët e leximit kur leximet e burimit kufizojnë xhiron. Rritni punëtorët e futjes kur objektivi ka kapacitet të disponueshëm shkrimi dhe radhët e futjes po grumbullohen. Për shkak se indekset e objektivit mirëmbahen gjatë futjeve të klonimit, punëtorët shtesë të futjes mund të rrisin kontestin e shkrimit. Autorët paralajmërojnë kundër rritjes agresive të të dyjave në të njëjtën kohë. Nëse CPU ose vonesa e diskut të objektivit rritet pa një fitim përkatës të xhiros, zvogëloni konkurencën e futjes. PCSM gjithashtu ekspozon metrika të thellësisë së radhës në PMM për replikim të vazhdueshëm, duke përfshirë percona_clustersync_mongodb_repl_event_queue_size, percona_clustersync_mongodb_repl_worker_event_queue_size dhe percona_clustersync_mongodb_repl_worker_bulk_queue_size.
Replikimi i vazhdueshëm ndikohet kryesisht nga numri i punëtorëve, madhësia e grupit të rrjedhës së ndryshimeve, madhësitë e radhëve, madhësia e grupit, intervali i shpëlarjes dhe mënyra e shkrimit me shumicë. Numri i punëtorëve të replikimit vendoset me repl-num-workers, i cili parazgjedhjet në numrin e CPU-ve. Udhëzuesi sugjeron rritjen e kësaj kur radhët e punëtorëve rriten dhe objektivi ende ka CPU, ruajtje dhe lidhje të disponueshme; një vlerë e dobishme testimi është dyfishi i numrit të CPU-ve. Megjithatë, më shumë punëtorë nuk do të përmirësojnë xhiron për ngarkesa me kontest të lartë, si operacionet që synojnë të njëjtin grup dokumentesh, sepse ngjarjet për të njëjtin dokument mbeten të përpunuara në rregull nga një punëtor i vetëm në një kohë.
Madhësia e grupit të rrjedhës së ndryshimeve kontrollohet nga repl-change-stream-batch-size, me një parazgjedhje prej 10,000 ngjarjesh. Vlerat më të mëdha zvogëlojnë udhëtimet e rrumbullakëta në rrjedhën e ndryshimeve gjatë ngarkesave të qëndrueshme. Autorët sugjerojnë eksperimentimin me 20,000 ose 50,000 ngjarje, por paralajmërojnë se grupet më të mëdha përdorin më shumë memorie dhe mund të rrisin vonesën e shpërthimit.
Dy parametra radhe, repl-event-queue-size dhe repl-worker-queue-size, të dyja parazgjedhjet në 5,000 ngjarje. Ato thithin shpërthime të përkohshme midis leximit të rrjedhës së ndryshimeve, rrugëzimit të ngjarjeve dhe shkrimeve të objektivit. Testoni vlera si 10,000 ose 25,000 kur radhët mbushen shkurtimisht gjatë ndalesave të shkrimit. Radhët më të mëdha nuk përmirësojnë xhiron e qëndrueshme nëse objektivi është përgjithmonë më i ngadalshëm se burimi, dhe radha e punëtorit ndahet për punëtor, kështu që ndikimi i saj në memorie rritet me repl-num-workers.
Madhësia e shkrimit me shumicë dhe intervali i shpëlarjes vendosen me repl-bulk-ops-size dhe repl-worker-flush-interval. Madhësia e parazgjedhur e grupit është 5,000 operacione dhe intervali i parazgjedhur i shpëlarjes është 1 sekondë. Për xhiro më të lartë, Percona rekomandon testimin e repl-bulk-ops-size=10000 dhe repl-worker-flush-interval=2s. Grupet më të mëdha zvogëlojnë mbingarkesën e komandave të MongoDB por mund të rrisin vonesën e replikimit. Për vonesë më të ulët, përdorni një interval më të shkurtër shpëlarjeje, si 100ms deri në 500ms. Grupet aktuale ende kufizohen nga madhësia e mesazhit të telit të MongoDB, kështu që dokumentet e mëdha mund të arrijnë kufirin e bajtit para numrit të konfiguruar të operacioneve.
Radha asinkrone e grupit vendoset me repl-worker-bulk-queue-size, e cila parazgjedhjet në 3 dhe kontrollon sa grupe të përfunduara mund të presin pas një shkrimi në fluturim. Autorët sugjerojnë testimin e 5 ose 10 kur shkrimet e objektivit janë më të ngadalta se përpunimi i ngjarjeve. Rritja e kësaj vlere i mban punëtorët të zënë por gjithashtu rrit përdorimin e memories dhe mund të lejojë që vonesa e replikimit të rritet kur objektivi nuk mund të mbajë ritmin.
Një tjetër çelës është use-collection-bulk-write, i cili është false si parazgjedhje. Si parazgjedhje një shkrim i vetëm me shumicë mund të përmbajë operacione për shumë baza të dhënash dhe koleksione. Vendosja e tij në true grupon operacionet sipas hapësirës së emrave, dhe mund të përmirësojë ngarkesat e shpërndara në shumë koleksione. PCSM mund të zgjedhë automatikisht shkrime në nivel koleksioni për versionet e objektivit pa mbështetje për shkrime me shumicë në nivel klienti.
PCSM mbështet opsionin e URI-së së MongoDB maxPoolSize. Nëse hiqet, parazgjedhja e drejtuesit është 100 lidhje për klient. Udhëzuesi jep një shembull URI prej mongodb://target-host/?maxPoolSize=300. Madhësia e grupit të lidhjeve bëhet e rëndësishme kur rriten punëtorët e klonimit ose replikimit. Filloni me një vlerë të moderuar eksplicite dhe rriteni atë vetëm kur punëtorët presin për lidhje. Shmangni grupet e pakufizuara përveçse nëse ka një arsye specifike për të hequr kufirin.
Kompresimi mund të rregullohet veçmas për lidhjet e burimit dhe objektivit me source-client-compressors dhe target-client-compressors. Preferenca e parazgjedhur është snappy, zstd, zlib. PCSM përputhet me rendin në të cilin MongoDB negocion kompresorët si parazgjedhje. Zakonisht snappy përdoret sepse ka mbingarkesën më të ulët, por kompresimi i tij nuk është aq i mirë sa zstd ose zlib. Ekipet që optimizojnë për përdorimin më të vogël të mundshëm të gjerësisë së brezit të rrjetit mund të provojnë kompresorët e tjerë.
Rrjedha e rekomanduar e punës së rregullimit është të vendosni një bazë me cilësimet e parazgjedhura, të vendosni një maxPoolSize të përshtatshme në URI-të e burimit dhe objektivit, të gjeni paralelizmin ideal të klonimit të koleksioneve, të rregulloni punëtorët e leximit dhe futjes së klonimit në mënyrë të pavarur, dhe së fundi të rregulloni numrin e punëtorëve të replikimit. Në fund, konfigurimi më i shpejtë është ai që e mban PCSM dhe MongoDB të zënë pa ngopur ruajtjen, CPU-në, memorien ose lidhjet në as burim as objektiv.
Për organizatat që ekzekutojnë MongoDB ose depo të ngjashme të dhënash, një ofrues i menaxhuar i cloud dhe infrastrukturës së të dhënave si AEU Data mund të trajtojë monitorimin themelor, kopjet rezervë dhe planifikimin e kapacitetit, në mënyrë që ekipet të përqendrohen në aplikimin e ndryshimeve të tilla të rregullimit në mënyrë të sigurt.