the open-source database 26.7 avvia il calendar versioning
the open-source database 26.7 segna un cambiamento significativo per i team che gestiscono in produzione il relational database usato da molte applicazioni web: il database è passato dalla familiare linea di numerazione 8.x e 9.x a uno schema di release basato sul calendario. Percona riferisce che il vendor ha distribuito la nuova Innovation release come 26.7.0 anziché 9.8, usando uno schema Year.Month.Patch che rende visibile la data di release nel numero di versione stesso.
Il cambiamento segue diverse fasi precedenti nel versioning del database server. La versione 8.0, usata dal 2018 al 2026, seguiva un modello tradizionale a singolo percorso in cui nuove funzionalità e bug fix arrivavano nella stessa linea 8.0. A metà 2023, il vendor ha introdotto un modello a doppio percorso con Innovation releases e Long Term Stable releases. Una Innovation release è il branch a evoluzione più rapida per nuove funzionalità e cambiamenti, mentre una LTS release è il branch più stabile pensato per un uso in produzione più lungo. Percona descrive il ciclo di supporto LTS come 5 anni di Premier Support seguiti da 3 anni di Extended Support, con una nuova LTS tipica circa ogni 2 anni.
In base a quel modello, le Innovation releases 8.1, 8.2 e 8.3 sono arrivate tra il 2023 e il 2024, portando alla prima LTS release, 8.4, nell'aprile 2024. La numerazione Innovation è poi passata alla serie 9.x, con versioni dalla 9.0 alla 9.6 rilasciate tra il 2024 e il 2026. La seconda LTS release, 9.7, è arrivata nell'aprile 2026, di nuovo con il periodo di 5 anni di Premier Support seguito da 3 anni di Extended Support.
Il nuovo schema di numerazione è scritto come YY.M.P. In 26.7.0, 26 indica il 2026, 7 indica luglio e 0 è il numero di patch, cioè un aggiornamento correttivo più piccolo all'interno di quella release. Percona afferma che il ciclo trimestrale delle Innovation release continua con il nuovo formato. Indica 26.10.0 come prossima Innovation release provvisoria per ottobre 2026 e afferma che la prossima LTS release con il nuovo schema è attesa nell'aprile 2028 come 28.4.0.
Per i database administrator, il valore principale è la chiarezza nella pianificazione. Una versione come 26.7.0 mostra immediatamente quando la release è stata distribuita, mentre etichette come 8.4 o 9.7 non portano in sé quell'informazione temporale. Percona dichiara inoltre che il cambiamento non incide sulle LTS release esistenti 8.4 e 9.7. Quei branch continuano a ricevere i normali aggiornamenti trimestrali di manutenzione, inclusi bug fix e security patches, mentre le nuove funzionalità Innovation passano nella serie con numerazione calendar-based.
L'upgrade path è importante. Percona afferma che il database server 9.7.x LTS è l'unico entry point nella prima lineage con calendar versioning, 26.7.0. In pratica, un sistema deve prima essere aggiornato a 9.7 LTS prima di passare a 26.7.0. La versione 8.4.x LTS o versioni precedenti non possono saltare direttamente nella nuova lineage. Un upgrade single-hop da 9.7.x LTS a 26.7.0, o a release successive nella stessa lineage come 26.10.0, 27.1.0 o 27.4.0, rimane valido fino alla prossima LTS, 28.4.0. Percona fornisce il percorso di esempio 8.4.x LTS to 9.7.x LTS to 26.7.0 e osserva che le versioni end-of-life più vecchie, come 5.7 o 8.0, devono prima passare a 8.4 LTS prima di seguire quella rotta.
the open-source database 26.7 aggiunge anche un Change Stream Applier, un componente di replication che cambia il modo in cui i server replica applicano le modifiche al database. Replication significa copiare modifiche ai dati da un database server a un altro, così che un sistema standby o secondario possa restare allineato al primario. Il precedente Multi-threaded Applier usava un coordinator per leggere le transactions in sequenza dai relay files, poi passarle ai worker threads per l'esecuzione parallela. Quel modello può perdere efficienza quando un worker è inattivo mentre attende di eseguire il commit perché una transaction precedente o dipendente deve prima terminare.
Il Change Stream Applier separa l'applicazione di una transaction dal suo commit nell'ordine richiesto. Se un worker ha finito di applicare una transaction ma deve aspettare prima del commit, può passare invece a un'altra transaction dependency-ready. Percona elenca tre impostazioni di replication collegate a questo cambiamento: l'impostazione della versione dell'applier, dove 1 indica il più vecchio Multi-threaded Applier e 2 indica il Change Stream Applier; l'impostazione del numero di worker dell'applier, che imposta il numero di worker per replication channel; e l'impostazione del limite di memoria degli eventi dell'applier, che imposta limiti di memoria per-channel per gli eventi binary log in cache. Un binary log è un record delle modifiche al database usato per recovery e replication.
Percona segnala anche due miglioramenti operativi. I worker del Change Stream Applier possono leggere gli eventi di transaction dal relay log contemporaneamente e rilasciare memoria degli eventi dopo che gli eventi sono stati consumati. I relay log files possono essere contrassegnati per concurrent purging una volta che tutte le transactions sono state applicate correttamente e non resta più nulla da leggere da quei file. Per usare la funzionalità, Percona afferma che è richiesta row-based replication, con binary logging impostato in row mode, e che l'enforcement del Global Transaction Identifier deve essere attivo. Un Global Transaction Identifier è un'etichetta univoca per una database transaction che aiuta i server a tenere traccia di ciò che è già stato elaborato.
Un altro cambiamento degno di nota è che il Thread Pool Plugin diventa disponibile nelle Community releases. Il database server ha tradizionalmente usato un modello one-thread-per-connection, cioè ogni client connection crea il proprio server thread. Questo può diventare costoso quando un'applicazione apre molte connections simultanee, soprattutto se molte sono idle o sleeping in attesa di lavoro. Un thread pool gestisce molte client connections tramite un numero più piccolo e controllato di worker threads, riducendo la necessità di creare un thread separato per ogni connection. Percona afferma che questo è utile quando le applicazioni creano numeri molto elevati di database connections concorrenti e aumentare l'impostazione massima delle connections causerebbe una creazione eccessiva di thread e uso eccessivo di risorse.
Percona descrive l'abilitazione del plugin caricando il thread pool shared module nella configurazione del database server, riavviando il database service e verificando che il thread pool plugin sia attivo tramite la vista delle informazioni sui plugin del server. Elenca inoltre variabili di configurazione del thread pool come thread pool size, query threads per group, maximum unused threads e stall limit settings. Il monitoring è disponibile tramite le tabelle Performance Schema per connections, thread group state, thread group statistics e thread state, oltre a status variables per i thread pool query threads. Performance Schema è l'insieme integrato di tabelle del database server per osservare l'attività del server.
the open-source database 26.7 cambia anche la truncation dell'undo log in InnoDB, lo storage engine che gestisce il modo in cui i dati vengono archiviati e recuperati all'interno del database server. Un undo log registra versioni precedenti dei dati modificati così che le transactions possano essere rolled back e possano essere servite consistent reads. In precedenza, InnoDB usava un file separato di undo truncation log per tenere traccia della truncation dell'undo tablespace, anche durante la recovery.