Database operator open source aggiunge un failover più sicuro e PITR criptato
Un Database operator per il database relazionale open source utilizzato da molte applicazioni web ha aggiunto il tuning basato sulle risorse, il recupero delle transazioni durante il failover asincrono e la point-in-time recovery criptata. Il 29 ottobre 2026 Percona ha rilasciato la versione 1.3.0 del proprio Operator open source per il database server. Un Kubernetes operator è un software che automatizza il deployment e il funzionamento di un'applicazione all'interno di Kubernetes. Percona afferma che questo operator funziona su qualsiasi distribuzione Kubernetes conforme agli standard della Cloud Native Computing Foundation.
Due modifiche ai valori predefiniti richiedono attenzione prima di un upgrade. La Leader election, il processo che seleziona un controller affinché prenda le decisioni quando sono in esecuzione più copie, ora viene abilitata automaticamente. Un deployment di sviluppo o debugging con un solo controller può ripristinare il comportamento precedente impostando PSO_LEADER_ELECTION_ENABLED su false nel Deployment dell'operator. La release consente inoltre agli amministratori di configurare le impostazioni della leader election tramite le variabili di ambiente PSO_LEADER_ELECTION_*.
La modifica più rilevante per l'upgrade riguarda i cluster asincroni. L'asynchronous replication conferma una transazione sottoposta a commit prima che un database secondario l'abbia necessariamente ricevuta. La versione 1.3.0 richiede che i backup siano abilitati per questi cluster e, in loro assenza, rifiuta di eseguire il reconcile, cioè di allineare il sistema distribuito alla configurazione dichiarata. In alternativa, gli amministratori possono impostare spec.unsafeFlags.asyncFailoverWithPossibleDataLoss su true. Ciò ripristina la promozione rapida senza tentare di recuperare le transazioni rimaste soltanto sul primary guasto. I cluster che utilizzano Group Replication non sono interessati.
L'automatic tuning viene configurato nella sezione automatic-configuration della custom resource del cluster, il documento Kubernetes che descrive lo stato desiderato del database. Per abilitarlo sono necessari limiti sia per la CPU sia per la memoria, poiché tali limiti costituiscono la base per calcolare le impostazioni del database server. Gli amministratori selezionano mostlyReads, someWrites, equalReadsWrites oppure heavyWrites come loadType e indicano una versione del database server nel formato X.Y.Z. L'esempio di Percona assegna 8 GiB di memoria, quattro CPU, il workload someWrites e la versione 8.4.0 del database server. L'operator dimensiona quindi il buffer pool, la principale cache dei dati in memoria del database server, e le relative impostazioni. Le ricalcola quando cambiano le risorse o il tipo di workload.
Le impostazioni che il database server consente di modificare durante l'esecuzione vengono applicate con SET GLOBAL, evitando un restart. Le impostazioni statiche ne richiedono comunque uno, quindi l'operator riavvia i pod in sequenza. Un pod è un'unità Kubernetes contenente uno o più container strettamente correlati. Questa distinzione è importante dal punto di vista operativo: l'automatic tuning riduce il configuration drift dopo le modifiche alle risorse, ma non rende dinamicamente regolabile ogni impostazione del database.
Il nuovo processo di failover affronta una specifica debolezza dell'asynchronous replication. Se un primary si guasta dopo aver accettato delle transazioni ma prima che una replica legga i corrispondenti binary logs, che registrano in sequenza le modifiche al database, una normale promozione può perdere tali transazioni. La versione 1.3.0 estende il sidecar xtrabackup su ogni pod del database server. Un sidecar è un container di supporto che viene eseguito accanto al database. Il suo endpoint POST /failover/stream sulla porta 6450 può fornire i binary logs come tar stream.
Durante il failover, lo strumento verifica innanzitutto se il primary guasto si è ripristinato. In caso contrario, arresta la replication, esegue il flush dei relay logs conservati dalla replica e legge Source_Log_File e Read_Source_Log_Pos per individuare la sezione mancante. Recupera i binary logs assenti dal sidecar del primary guasto, li tronca all'ultima transazione completa e li unisce all'ultimo relay log chiuso. L'SQL thread, che applica le modifiche replicate al database locale, rimane quindi in esecuzione finché tutte le transazioni recuperate non sono state elaborate. Solo a quel punto l'orchestrator promuove la replica selezionata.
Questa protezione ha un limite importante. Il processo del database server del vecchio primary può non essere in esecuzione, ma il relativo pod e il sidecar devono rimanere raggiungibili. Per impostazione predefinita, lo strumento di failover ha un'ora di tempo dal primo tentativo per raggiungere la source e applicare il lavoro mancante. Il timer non viene azzerato a ogni nuovo tentativo. Alla scadenza, la policy Abort lascia il cluster senza promozione, mentre ForceWithPossibleDataLoss procede nonostante la possibile lacuna. Il requisito relativo al backup serve a garantire la presenza del sidecar di supporto, ma i team dovrebbero comunque verificare se i propri scenari di guasto lo lasciano accessibile.
La release cripta inoltre i binary logs inviati all'object storage per la point-in-time recovery (PITR), che ripristina un backup e quindi riapplica le modifiche registrate fino a un momento selezionato. Utilizza l'envelope encryption: ogni file riceve la propria data encryption key (DEK), che viene protetta da una key encryption key (KEK). L'operator legge la KEK da un Kubernetes Secret anziché collocare il materiale master su ogni pod del database server. AES-256-CTR è il symmetric cipher predefinito. La configurazione della cifratura specifica il cipher e kekId, mentre keyringSecret identifica il Secret e il relativo file keyring, la cui chiave predefinita è keyring.json.
Durante il ripristino, lo strumento PITR legge i metadata del file, individua la KEK indicata, apre la chiave del singolo file e trasmette in streaming gli eventi decriptati attraverso l'utility di replay dei binary logs nel database ripristinato. Un keyring mancante o una KEK assente provoca un errore esplicito prima che venga prodotto un recupero parziale. L'esempio di Percona combina backup e PITR abilitati con un bucket S3, un Secret per le credenziali, un endpoint, una region, AES-256-CTR, la voce KEK alpha e un Secret keyring separato per il binlog-server.
Altre modifiche spostano nella specifica del cluster un maggior numero di operazioni di routine. Gli account applicativi possono essere dichiarati in spec.users insieme a database, host consentiti, grants, riferimenti facoltativi a Secret contenenti password e delega dei grants. Lo storage dei backup può considerare attendibile una certificate authority personalizzata per MinIO privato o altri endpoint compatibili con S3. TLS, la cifratura utilizzata per le connessioni di rete, può utilizzare un cert-manager ClusterIssuer con scope a livello di cluster. La rotazione dei certificati unisce le authority vecchie e nuove, ricarica i leaf certificates senza riavviare il database server e rimuove la vecchia authority dopo la conferma della propagazione.
Ora è possibile assegnare deadline ai backup, in modo che un job eccessivamente lungo segnali un errore invece di rimanere bloccato. I log dell'operator persistono dopo i restart del controller, i report sul replication lag mostrano di quanto sono in ritardo le repliche e DigitalOcean Kubernetes è ufficialmente supportato. La versione 9.7 del database server entra nella matrice delle versioni supportate. La release include inoltre cluster asincroni con un numero pari di componenti, bootstrap da backup, rejoin di ClusterSet e uno switch del replication type contrassegnato come tech preview, ossia disponibile per la valutazione anziché considerato una funzionalità di produzione completa.