the open-source database 26.7 nis calendar versioning
the open-source database 26.7 shënon një ndryshim të rëndësishëm për ekipet që operojnë në production database relacionale të përdorur nga shumë aplikacione web: database ka kaluar nga linja e njohur e numërimit 8.x dhe 9.x në një skemë release të bazuar në kalendar. Percona raporton se vendor dërgoi Innovation release të ri si 26.7.0 dhe jo si 9.8, duke përdorur një model Year.Month.Patch që e bën datën e release të dukshme në vetë numrin e versionit.
Ndryshimi pason disa faza të mëparshme në versioning të database server. Versioni 8.0, i përdorur nga 2018 deri në 2026, ndoqi një model tradicional single-track ku funksionalitetet e reja dhe bug fixes mbërrinin në të njëjtën linjë 8.0. Në mesin e vitit 2023, vendor prezantoi një model dual-track me Innovation releases dhe Long Term Stable releases. Një Innovation release është dega që lëviz më shpejt për funksionalitete dhe ndryshime të reja, ndërsa një LTS release është dega më e qëndrueshme e synuar për përdorim më të gjatë në production. Percona e përshkruan ciklin e mbështetjes LTS si 5 vjet Premier Support të ndjekura nga 3 vjet Extended Support, me një LTS të ri tipikisht rreth çdo 2 vjet.
Sipas atij modeli, Innovation releases 8.1, 8.2 dhe 8.3 mbërritën midis 2023 dhe 2024, duke çuar te LTS release i parë, 8.4, në prill 2024. Numërimi Innovation më pas kaloi në serinë 9.x, me versionet 9.0 deri 9.6 të publikuara midis 2024 dhe 2026. LTS release i dytë, 9.7, mbërriti në prill 2026, sërish me periudhën 5-vjeçare Premier Support të ndjekur nga 3 vjet Extended Support.
Skema e re e numërimit shkruhet si YY.M.P. Në 26.7.0, 26 qëndron për 2026, 7 qëndron për korrik dhe 0 është numri i patch, që do të thotë një përditësim më i vogël korrigjues brenda atij release. Percona thotë se cikli tremujor Innovation release vazhdon nën formatin e ri. Ajo jep 26.10.0 si Innovation release të radhës paraprak për tetor 2026 dhe thotë se LTS release i radhës nën skemën e re pritet në prill 2028 si 28.4.0.
Për database administrators, vlera kryesore është qartësia në planifikim. Një version si 26.7.0 tregon menjëherë kur është dërguar release, ndërsa etiketa si 8.4 ose 9.7 nuk e mbartin atë informacion kohor në vetvete. Percona gjithashtu deklaron se ndryshimi nuk prek LTS releases ekzistuese 8.4 dhe 9.7. Ato degë vazhdojnë të marrin përditësime normale tremujore mirëmbajtjeje, përfshirë bug fixes dhe security patches, ndërsa funksionalitetet e reja Innovation kalojnë në serinë me numërim kalendarik.
Upgrade path është i rëndësishëm. Percona thotë se database server 9.7.x LTS është pika e vetme hyrëse në lineage të parë me calendar versioning, 26.7.0. Në praktikë, një sistem duhet fillimisht të bëjë upgrade në 9.7 LTS përpara se të kalojë në 26.7.0. Versioni 8.4.x LTS ose versionet më të hershme nuk mund të kalojnë drejtpërdrejt në lineage të ri. Një upgrade single-hop nga 9.7.x LTS në 26.7.0, ose në releases të mëvonshme në të njëjtin lineage si 26.10.0, 27.1.0 ose 27.4.0, mbetet i vlefshëm deri te LTS i radhës, 28.4.0. Percona jep si shembull path 8.4.x LTS në 9.7.x LTS në 26.7.0 dhe vëren se versionet më të vjetra end-of-life si 5.7 ose 8.0 duhet fillimisht të kalojnë në 8.4 LTS përpara se të ndjekin atë rrugë.
the open-source database 26.7 gjithashtu shton një Change Stream Applier, një komponent replication që ndryshon mënyrën si replica servers aplikojnë ndryshimet e database. Replication do të thotë kopjimi i ndryshimeve të të dhënave nga një database server në një tjetër, që një sistem standby ose dytësor të qëndrojë i sinkronizuar me primary. Multi-threaded Applier i mëparshëm përdorte një coordinator për të lexuar transactions në mënyrë sekuenciale nga relay files, pastaj ua dorëzonte ato worker threads për ekzekutim paralel. Ai model mund të humbasë efikasitet kur një worker është idle ndërsa pret të bëjë commit sepse një transaction më i hershëm ose i varur duhet të përfundojë më parë.
Change Stream Applier ndan aplikimin e një transaction nga commit i saj në rendin e kërkuar. Nëse një worker ka përfunduar aplikimin e një transaction por duhet të presë përpara se të bëjë commit, ai mund të kalojë te një transaction tjetër dependency-ready. Percona rendit tre settings të replication të lidhura me këtë ndryshim: setting i versionit të applier, ku 1 do të thotë Multi-threaded Applier më i vjetër dhe 2 do të thotë Change Stream Applier; setting i numrit të applier workers, që cakton numrin e workers për replication channel; dhe setting i kufirit të memories së applier event, që cakton kufijtë e memories për channel për cached binary log events. Një binary log është një record i ndryshimeve të database i përdorur për recovery dhe replication.
Percona gjithashtu vëren dy përmirësime operative. Change Stream Applier workers mund të lexojnë transaction events nga relay log në të njëjtën kohë dhe të lirojnë event memory pasi events janë konsumuar. Relay log files mund të shënohen për purging të njëkohshëm pasi të gjitha transactions janë aplikuar me sukses dhe nuk mbetet asgjë për t’u lexuar nga ato files. Për të përdorur funksionalitetin, Percona thotë se kërkohet row-based replication, me binary logging të vendosur në row mode, dhe Global Transaction Identifier enforcement duhet të jetë aktiv. Një Global Transaction Identifier është një etiketë unike për një database transaction që i ndihmon servers të gjurmojnë çfarë është përpunuar tashmë.
Një tjetër ndryshim i dukshëm është që Thread Pool Plugin bëhet i disponueshëm në Community releases. Database server tradicionalisht ka përdorur një model one-thread-per-connection, që do të thotë se çdo client connection krijon server thread-in e vet. Kjo mund të bëhet e kushtueshme kur një aplikacion hap shumë simultaneous connections, veçanërisht nëse shumë prej tyre janë idle ose sleeping ndërsa presin punë. Një thread pool trajton shumë client connections përmes një numri më të vogël dhe të kontrolluar worker threads, duke reduktuar nevojën për të krijuar një thread të veçantë për çdo connection. Percona thotë se kjo është e dobishme kur aplikacionet krijojnë numra shumë të lartë concurrent database connections dhe rritja e maximum connection setting do të shkaktonte krijim të tepruar threads dhe përdorim të tepruar burimesh.
Percona përshkruan aktivizimin e plugin duke ngarkuar thread pool shared module në configuration të database server, duke rifilluar database service dhe duke verifikuar që thread pool plugin është aktiv përmes pamjes së plugin information të server. Ajo gjithashtu rendit thread pool configuration variables si thread pool size, query threads per group, maximum unused threads dhe stall limit settings. Monitoring është i disponueshëm përmes Performance Schema tables për connections, thread group state, thread group statistics dhe thread state, plus status variables për thread pool query threads. Performance Schema është seti i integruar i tables i database server për të vëzhguar aktivitetin e server.
the open-source database 26.7 gjithashtu ndryshon undo log truncation në InnoDB, storage engine që menaxhon si ruhen dhe rikuperohen të dhënat brenda database server. Një undo log regjistron versionet e mëparshme të të dhënave të ndryshuara që transactions të mund të rolled back dhe consistent reads të mund të shërbehen. Më parë, InnoDB përdorte një undo truncation log file të veçantë për të gjurmuar undo tablespace truncation, përfshirë gjatë recovery.