MariaDB 12.0: funzionalità, rischi legati all'aggiornamento e strategia di hosting

Classificare correttamente MariaDB 12.0

La denominazione „MariaDB 12“ non indica una versione del prodotto unitaria e sottoposta a manutenzione continua. Per informazioni tecniche specifiche, si rimanda alla serie rolling MariaDB 12.0 inteso. All’interno di questa serie, le versioni indicano diversi livelli di maturità: la 12.0.0 è stata rilasciata il 26 marzo 2025 come anteprima, la 12.0.1 il 5 giugno 2025 come release candidate e la 12.0.2 il 7 agosto 2025 come versione stabile GA.

Le versioni Preview e Release Candidate servono a fini di test e non sono da equiparare a una piattaforma stabile. Il fatto che la versione 12.0.2 sia documentata come Stable o GA, invece, descrive lo stato di maturità proprio di questa versione. Ciò non implica né che ogni installazione debba essere aggiornata immediatamente, né che le versioni successive possiedano automaticamente le stesse caratteristiche, gli stessi pacchetti o gli stessi limiti operativi.

Anche i rami successivi, come il 12.1, il 12.2 o il 12.3, devono essere considerati separatamente. Le funzioni, le correzioni di errori o i valori predefiniti modificati di tali serie non costituiscono una prova di MariaDB 12.0. Lo stesso vale per i rami di sviluppo: un annuncio o una documentazione relativi a tali rami non sostituiscono alcuna dichiarazione relativa allo stato pubblicato di un server della community.

Prima di un rollout, la piattaforma richiede quindi una nuova verifica dello stato effettivo dei pacchetti previsti. In particolare, occorre verificare la serie di server disponibile, la compatibilità tra pacchetti client e pacchetti aggiuntivi, il supporto da parte della versione del sistema operativo in uso e l’attuale classificazione della release. I contenuti del repository e i pacchetti di distribuzione possono differire dalla denominazione generale del prodotto.

Differenze tra Rolling Release e LTS

Per le piattaforme di hosting non è rilevante solo il numero di versione, ma anche il codice sottostante Modello di rilascio. MariaDB distingue le versioni "Innovation" dalle versioni LTS. Le versioni "Innovation" introducono nuove funzionalità a intervalli brevi e, una volta raggiunta la fase GA, seguono di norma il percorso verso la serie "Rolling" successiva. Le versioni LTS, invece, secondo il produttore, vengono supportate per tre anni a partire dalla fase GA.

Una versione GA stabile risponde quindi solo alla domanda se quella versione specifica sia stata rilasciata come stabile. Non fornisce una risposta generale su per quanto tempo saranno disponibili le correzioni di sicurezza, se un distributore continuerà a fornire i pacchetti o se una base clienti esistente possa rimanere su quella serie senza dover effettuare la migrazione. Questi aspetti dipendono dal contratto, dalla distribuzione e dalla panoramica attuale delle versioni.

Una serie di innovazioni può essere opportuna quando una piattaforma desidera implementare tempestivamente una funzionalità chiaramente necessaria e può testare in modo isolato le applicazioni, i connettori e i processi operativi interessati. A tal fine, i team devono pianificare di proseguire tempestivamente lungo il percorso di aggiornamento previsto. Soprattutto nel caso di offerte multi-tenant, ciò comporta un aumento del carico di lavoro in termini di approvazioni, comunicazione e procedure di ripiego.

A Punteggio obiettivo LTS È più adatto a piattaforme standardizzate con molte applicazioni classiche, quando le finestre di manutenzione pianificabili e una versione software stabile nel lungo periodo sono più importanti delle singole nuove funzionalità. Questo non è un divieto nei confronti delle versioni innovative: ciò che conta è se i vantaggi di una funzionalità giustificano i test aggiuntivi e il prevedibile passaggio alla serie successiva.

La scelta dovrebbe quindi tenere conto almeno delle esigenze funzionali, dello stato attuale dei pacchetti e del supporto, della compatibilità delle applicazioni testata, della possibilità di ripristino e del carico di lavoro del personale. Per una nuova installazione non è sufficiente considerare „MariaDB 12“ come la versione più recente. La piattaforma opera una scelta consapevole tra l’utilizzo di funzionalità a breve termine e uno stato del database standardizzato a lungo termine.

Valutare le nuove funzionalità tenendo conto dei loro limiti

MariaDB 12.0 integra Suggerimenti dell'ottimizzatore per influenzare in modo più mirato i piani di esecuzione, ad esempio per l’ordine dei join, l’ottimizzazione degli intervalli o determinati algoritmi di join. Le estensioni riguardano inoltre le componenti dell’indice ordinate in ordine decrescente nei casi di Loose Index Scan e Index Condition Pushdown. Per l’hosting, si tratta soprattutto di uno strumento diagnostico per singole query problematiche, non di un sostituto di indici adeguati, condizioni di join corrette e statistiche delle tabelle aggiornate.

Un suggerimento può limitare un piano indesiderato, ma può rivelarsi controproducente in seguito all'aumento dei dati o a variazioni delle statistiche. Deve quindi essere inserito in un'analisi riproducibile dell'applicazione in questione e non come impostazione globale nei server di database. Per i database tipici dei CMS e degli shop online, la semplice disponibilità di tali suggerimenti non costituisce un motivo convincente per effettuare un aggiornamento a MariaDB.

Durante l’audit, il plugin di audit nella versione 12.0 registra anche l’host e la porta delle connessioni in entrata, nonché la versione TLS utilizzata. Per gli accessi effettuati tramite proxy, NAT o bilanciatori di carico, ciò può migliorare l’attribuzione forense. Il vantaggio, tuttavia, si concretizza solo grazie a una raccolta centralizzata dei log protetta da accessi non autorizzati e a regole di conservazione prestabilite; i dati di log aggiuntivi devono rientrare nella pianificazione relativa alla capacità e alla protezione dei dati.

Per la crittografia, è disponibile il supporto SHA-2 in file_key_management.so e ssl_passphrase Moduli pronti. Gli ambienti di replica dispongono ora di opzioni per le tabelle temporanee e di una variabile per la gestione degli eventi relativi al proprio ID server. Inoltre, la versione 12.0 introduce, tra le altre cose, SYS_REFCURSOR, un limite di cursori per sessione e funzioni GIS quali la convalida, la semplificazione e la conversione Geohash. Ciascuno di questi strumenti è utile solo per applicazioni e topologie specifiche.

MariaDB Server, MaxScale e Galera rimangono componenti distinti: MaxScale ha versioni e configurazioni proprie, mentre le modifiche relative a Galera riguardano esclusivamente i cluster. Allo stesso modo, la compatibilità con MySQL non implica l’intercambiabilità senza una verifica preventiva. MariaDB utilizza un proprio modello GTID e, ad esempio, non supporta quello di MySQL SET PERSIST. Le nuove funzionalità GIS possono essere utili per le applicazioni di geodati basate su MySQL 8, ma nella maggior parte dei casi non costituiscono un motivo valido per effettuare l'aggiornamento dei normali database web.

Confronto tra stato di rilascio e funzionalità

Per il funzionamento della piattaforma è determinante lo stato specifico all’interno della serie. MariaDB 12.0.0 era una versione di anteprima, la 12.0.1 una release candidate e solo la 12.0.2 è documentata come stabile o GA. Questi stati indicano diversi livelli di maturità; non forniscono alcuna indicazione sull’idoneità della serie per una determinata implementazione di hosting, un sistema operativo o un contratto di assistenza.

Le nuove funzionalità sono utili soprattutto quando risolvono un problema operativo concreto. Suggerimenti dell'ottimizzatore possono, ad esempio, limitare un piano di esecuzione indesiderato per una singola query complessa. Non sostituiscono né indici adeguati, né condizioni di join corrette, né statistiche aggiornate e non dovrebbero essere utilizzate come impostazione predefinita globale per le applicazioni dei clienti.

I campi di audit aggiuntivi possono registrare l'host, la porta e la versione TLS utilizzata di una connessione in entrata. L'opzione chiave ssl_passphrase Le funzionalità avanzate del GIS o del cursore, invece, non giustificano un cambio di versione generalizzato. Il loro vantaggio si manifesta solo nelle applicazioni la cui architettura, il cui modello di dati e i cui requisiti di sicurezza richiedono effettivamente tali funzionalità.

Prepararsi in modo controllato all'aggiornamento di MariaDB

Un aggiornamento di MariaDB nell’hosting gestito o condiviso inizia con un inventario: è necessario conoscere le istanze, i database, i connettori, i plugin, i file di configurazione, i percorsi di replica e le applicazioni interessate. Segue quindi un ambiente di staging che riproduce i dati di produzione e la configurazione solo nel rispetto dei requisiti di sicurezza consentiti. In questo modo è possibile individuare eventuali problemi di avvio e anomalie SQL prima che siano interessati più clienti.

Prima di ogni implementazione limitata è necessario eseguire un backup completo e definire una procedura di ripristino documentata. Non è sufficiente che i file di backup siano presenti: i responsabili devono verificare se da essi sia possibile ripristinare uno stato dei dati coerente e utilizzabile dalle applicazioni. Successivamente, controllano gli accessi, le operazioni di scrittura, i processi in background e i percorsi tipici degli utenti come Regressione dell'applicazione. La procedura concreta dipende dal metodo di sicurezza utilizzato e dall'architettura della piattaforma.

Un piano di ripristino definisce chi decide quali stati dei dati sono rilevanti e in che modo le applicazioni tornano allo stato coerente precedente in caso di interruzione. Si tratta di una prassi operativa standard, non di una caratteristica specifica di una determinata versione di MariaDB. La replica, il monitoraggio e il failover devono quindi essere verificati nella rispettiva topologia di staging, anziché dedurne il funzionamento da un aggiornamento riuscito di una singola istanza.

MariaDB 12.0 elimina le variabili di sistema big_tables, large_page_size e storage_engine. Le voci esistenti devono quindi essere inserite in my.cnf e in tutti i frammenti di configurazione coinvolti, per poi essere valutati in base allo stato di destinazione. La pulizia deve avvenire prima dell'aggiornamento del pacchetto; in caso di large_page_size occorre inoltre distinguere tra la variabile MariaDB rimossa e una configurazione HugePages del sistema operativo indipendente da essa.

Anche la pianificazione dei pacchetti merita una fase a sé stante: un repository può contenere diverse versioni di MariaDB e i pacchetti correlati (server, client, shared e common) dovrebbero avere la stessa versione. La versione del sistema operativo e le fonti dei pacchetti sono parte integrante del rilascio. Per le dipendenze a livello di host, l’articolo su novità rilevanti per i server di hosting con kernel Linux 6.x ulteriore contesto; tuttavia, non sostituisce il controllo di staging specifico del database.

Configurare in modo sicuro i casi particolari

In caso di query di reporting instabili, la diagnosi dovrebbe iniziare con l’analisi dei piani di esecuzione, degli indici, delle condizioni di join e delle statistiche delle tabelle. Solo quando un piano indesiderato è stato individuato in modo riproducibile, un hint dell’ottimizzatore può costituire una limitazione mirata. Il suggerimento fa parte della query in questione e deve essere incluso in una verifica documentata, poiché la crescita dei dati o le statistiche modificate potrebbero alterarne l'efficacia in un secondo momento.

Per effettuare un'analisi dello stato attuale senza rischi, è opportuno utilizzare query di lettura. Eseguile con un account che disponga solo dei diritti di accesso necessari a tale scopo; esse non modificano né i dati né i diritti né la configurazione del server. I risultati indicano il server di database effettivamente connesso e aiutano a verificare le ipotesi riportate nella documentazione di implementazione.

SELECT VERSION();
SHOW VARIABLES LIKE 'max_open_cursors';
SHOW VARIABLES LIKE 'create_tmp_table_binlog_formats';

In un'architettura proxy, SET SESSION AUTHORIZATION Non si tratta di una funzionalità di comfort, bensì di un intervento sul modello di sicurezza. Il cambio di sessione richiede il privilegio SET USER e non è disponibile all'interno di transazioni, prepared statement o stored procedure.

Le versioni compatibili di MaxScale possono utilizzare le credenziali di servizio per la connessione al backend e successivamente passare all’identità del client. A tal fine sono necessari un server backend MariaDB 12 o versione successiva e il privilegio SET USER necessario per l'account di servizio. Tuttavia, questa funzionalità non deriva automaticamente dal solo backend MariaDB 12.0: prima dell'implementazione è necessario verificare la combinazione specifica tra MariaDB Server, versione di MaxScale e configurazione.

L'impostazione MaxScale use_service_credentials Determina, nelle versioni che lo supportano, se MaxScale debba prima effettuare l’accesso al backend utilizzando le credenziali memorizzate nel servizio e poi passare all’identità del client. L’account di servizio non deve ricevere diritti amministrativi aggiuntivi oltre a quelli tecnicamente necessari. L’audit e una procedura di spegnimento di emergenza documentata devono essere compatibili con il modello di connessione e di pooling.

Le topologie di replica e Galera richiedono un percorso di test dedicato per il failover, il rejoin e il ripristino. Le opzioni relative alle tabelle temporanee o alla gestione degli ID server identici non devono essere modificate senza una comprensione approfondita del formato del binlog, dell’ID server e del percorso di ritorno. Inoltre, un’ottimizzazione Galera non costituisce una garanzia generale di prestazioni per i cluster, poiché il profilo di carico e la latenza di rete rimangono fattori determinanti.

Chiunque valuti tabelle interne, strutture temporanee o motori di archiviazione nel proprio ambiente dovrebbe considerare il ruolo del rispettivo motore separatamente dalla migrazione delle versioni. L'articolo su Motore di archiviazione MariaDB Aria nell'hosting classifica tali aspetti operativi. Per la decisione relativa all’aggiornamento, tuttavia, rimane determinante il fatto che l’applicazione concreta e i relativi processi operativi funzionino in modo riproducibile nella versione di destinazione.

Garantire il cambio di sessione e l'audit

SET SESSION AUTHORIZATION è un elemento fondamentale per architetture di connessione progettate in modo consapevole, non solo uno strumento per semplificare l'amministrazione. Il comando consente a un account autorizzato di agire, all'interno della sessione corrente, assumendo l'identità di un altro utente. Il prerequisito è il privilegio SET USER. In questo modo, la responsabilità relativa alla registrazione e alla verifica dell'identità viene in parte trasferita dai singoli account dei clienti a una componente controllata della piattaforma.

Questo modello può essere utile per un proxy, ma MariaDB Server e MaxScale rimangono prodotti distinti con un proprio sistema di versioning. Solo le versioni di MaxScale che supportano l’utilizzo delle credenziali di servizio con successivo cambio di identità possono fornire questa funzionalità. Un backend MariaDB 12.0 non estende automaticamente questa funzionalità a un ramo MaxScale più vecchio o configurato in modo diverso.

In una combinazione supportata, il proxy effettua l'accesso al server MariaDB con l'account di servizio e successivamente passa all'identità utente richiesta. L'impostazione use_service_credentials richiede un server backend MariaDB 12 o versione successiva, nonché SET USER per l'account di servizio. Prima dell'implementazione è quindi necessario verificare congiuntamente le versioni concrete di MariaDB e MaxScale utilizzate, la configurazione e il metodo di autenticazione previsto.

L'account di servizio è dovuto alla possibilità di Il cambio di identità è un fattore critico per la sicurezza. Il privilegio SET USER non gli conferisce automaticamente diritti amministrativi globali a piacere; inoltre, gli devono essere concesse solo le autorizzazioni tecnicamente necessarie. In caso di cambio di sessione, è possibile aggirare, tra le altre cose, il blocco dell’account, la scadenza della password, l’autenticazione e il controllo REQUIRE-SSL dell’account di destinazione. Il cambio non è inoltre disponibile all’interno di transazioni, prepared statement o stored procedure.

Per l’hosting multi-cliente ciò significa che gli account dei clienti rimangono logicamente separati e che il ciclo di cambio consentito viene documentato e limitato. Inoltre, la piattaforma deve disporre di una procedura di disattivazione di emergenza, ad esempio tramite il blocco dell’account di servizio o la rimozione del percorso di connessione interessato, secondo una procedura prestabilita in caso di incidenti. La misura più adeguata deve essere valutata tenendo conto del pooling delle connessioni, delle sessioni in corso e delle ripercussioni sugli altri clienti.

Il plugin Audit in MariaDB 12.0 aggiunge alle connessioni in entrata l’host, la porta e la versione TLS utilizzata. Queste informazioni aiutano a classificare meglio gli accessi provenienti da dietro NAT, bilanciatori di carico o proxy. Tuttavia, non sostituiscono un'identificazione affidabile qualora un sistema a monte modifichi le informazioni sulla fonte o trasmetta al server del database solo il proprio indirizzo.

Entra in vigore Verifica innanzitutto attraverso un processo operativo: i log dovrebbero essere raccolti a livello centrale, protetti da modifiche non autorizzate e gestiti in base a un periodo di conservazione prestabilito. I diritti di accesso per la consultazione e l’esportazione devono essere separati, così come le responsabilità relative alla segnalazione degli allarmi e alle indagini. Senza effettuare misurazioni, non è possibile dedurre dalla versione se dati di log aggiuntivi influenzino in modo significativo la capacità o le prestazioni di una piattaforma specifica.

In caso di incidente di sicurezza, gli amministratori dovrebbero essere in grado di ricostruire quale identità sia stata impostata dal proxy, tramite quale accesso sia stata avviata la sessione e quali dati di audit siano disponibili al riguardo. I controlli regolari e documentati relativi alla disattivazione e alla disponibilità dei log sono più importanti di una registrazione il più possibile esaustiva. In particolare, un log di audit non deve sostituirsi a un modello di autorizzazioni, alla crittografia del trasporto o a una gestione sicura delle chiavi segrete.

Monitorare il funzionamento dopo l'aggiornamento

Dopo un aggiornamento di MariaDB, ha inizio una fase di monitoraggio; non viene eseguita alcuna ottimizzazione automatica. Innanzitutto occorre distinguere se il Avvio del server si verifica un errore, un'applicazione non riesce più a stabilire una connessione o un percorso di replica non corrisponde. Questi scenari di errore hanno cause diverse e richiedono soluzioni specifiche, anziché essere risolti con modifiche generiche alla configurazione.

Gli errori di avvio vengono individuati sulla base del log degli errori del server e di un inventario con controllo delle versioni dei file di configurazione effettivamente caricati. In MariaDB 12.0, ad esempio, big_tables e storage_engine rimosso. Tali voci non devono essere riportate senza modifiche in my.cnf o nei frammenti di configurazione integrati; il riferimento alla variabile documentato e il messaggio di avvio indicano quale impostazione è concretamente interessata.

Per quanto riguarda i connettori e i plugin, è necessario registrare insieme i pacchetti installati, le versioni dei moduli caricati e i messaggi di errore dell’applicazione. La sola selezione di un repository non garantisce un'installazione compatibile: nel caso di una versione specifica del server, i pacchetti server, client, condivisi e comuni devono essere pianificati con la stessa versione. I nomi e gli stati disponibili dipendono dal repository e dal sistema operativo utilizzati.

Il modo migliore per analizzare gli errori dell'applicazione è utilizzare un caso SQL riproducibile e il più semplice possibile, insieme ai relativi log del client o del connettore. È possibile effettuare un'analisi preliminare con SELECT VERSION(); Iniziare. Il risultato identifica il server di database che ha risposto, ma non dimostra né la compatibilità di un ORM né il corretto funzionamento di una configurazione dell'applicazione.

Per quanto riguarda la replica, nel fascicolo diagnostico devono essere inclusi lo stato di replica documentato, il formato del binlog, gli ID dei server e gli eventi relativi al failover e al rejoin. Le tabelle temporanee, la topologia e le modifiche alle opzioni di replica devono essere verificate separatamente. Un test di scrittura locale riuscito non è sufficiente a dimostrare la coerenza e il comportamento previsto su tutte le istanze coinvolte.

I log di sistema e di audit, l’inventario delle configurazioni, le richieste relative alle versioni e i test riproducibili sulle query costituiscono nel loro insieme un catena di errori tracciabile. Inoltre, facilita la decisione sull’opportunità di attivare un piano di ripristino. Un numero di versione più elevato non comporta né un determinato effetto sulle prestazioni né un’ottimizzazione universale; le modifiche ai parametri di memoria, dell’ottimizzatore o di replica richiedono un’ipotesi concreta e un effetto verificabile.

Decidere strategicamente il punteggio finale

L'obiettivo appropriato dipende dal compito della piattaforma e dal modello operativo, non dalla denominazione generica “MariaDB 12”. Per i database classici di CMS, negozi online e applicazioni web, la sicurezza degli aggiornamenti, una chiara separazione dei clienti e un percorso di ripristino affidabile hanno solitamente la priorità rispetto alle singole nuove funzionalità SQL. Le nuove funzioni o routine GIS non costituiscono un motivo autonomo per la migrazione se le applicazioni non le utilizzano.

Le applicazioni di reporting complesse possono trarre vantaggio dai suggerimenti dell’Optimizer quando un’analisi individua chiaramente un piano di esecuzione indesiderato. In precedenza è necessario verificare gli indici, le condizioni di join, la distribuzione dei dati e le statistiche. Un suggerimento costituisce un vincolo mirato a una decisione relativa al piano di esecuzione e può diventare inadeguato a seguito di un aumento del volume dei dati o di modifiche alle statistiche; pertanto, deve essere incluso nella documentazione dell’applicazione insieme alla query, alla motivazione e ai criteri di revoca.

Gli ambienti proxy e cluster richiedono un percorso di test dedicato. Nel caso di un proxy, ciò riguarda in particolare il modello di autorizzazione dell'account di servizio, i cambi di sessione e la tracciabilità. Per la replica o Galera, ciò include il failover, il rejoin, il ripristino e il comportamento delle tabelle temporanee. Il corretto aggiornamento di una singola istanza non garantisce che questi processi funzionino correttamente nell’intera topologia.

Il sito Strategia di lancio deve valutare separatamente le versioni "Innovation" e le LTS. MariaDB descrive le versioni "Innovation" come versioni rolling, che di norma dopo il GA non vengono aggiornate in modo continuativo con versioni patch; il percorso previsto conduce alla serie rolling successiva. Le versioni LTS, invece, vengono mantenute per tre anni a partire dal rilascio GA. Ciò non comporta alcun impegno generale in merito al supporto tramite pacchetti o contratti per un ambiente di hosting specifico.

Prima di prendere una decisione, è quindi necessario valutare nel loro insieme la disponibilità di pacchetti e supporto della distribuzione, la compatibilità verificata delle applicazioni, un ripristino comprovato, il modello di sicurezza e i costi operativi correnti. MariaDB e MySQL, nonostante i numerosi modelli SQL in comune, non sono intercambiabili: MariaDB utilizza un proprio modello GTID e, ad esempio, non supporta quello di MySQL SET PERSIST. È quindi necessario verificare le ipotesi relative alla migrazione provenienti da un ambiente MySQL.

Per la serie 12.0, la versione 12.0.2 è documentata come versione stabile GA, mentre la 12.0.0 era una preview e la 12.0.1 una release candidate. Questa classificazione descrive lo stato di maturità dell’epoca, ma non sostituisce una decisione di rilascio attuale. Immediatamente prima del lancio o della pubblicazione, gli operatori devono verificare nuovamente la versione del pacchetto offerta, il supporto del sistema operativo e l’attuale classificazione della release confrontandoli con le informazioni fornite dal produttore.

È quindi determinante lo stato della piattaforma, verificato concretamente, con le sue dipendenze e le sue regole operative. Un rollout controllato è giustificato se la compatibilità, il rollback e le responsabilità sono stati preparati in modo documentabile. In assenza di questi presupposti, il nome MariaDB 12 non costituisce un argomento valido per assumersi rischi nell’hosting condiviso o in un ambiente di database business-critical.