[Risolto] Faccio ammenda. Upgrade Jammy Jellyfish

[LucaZeta]

Con immotivata sicurezza ho effettuato l'upgrade di un server zeppo di funzioni a Jammy Jellyfish. Mi ero riproposto di attendere almeno fino ad Agosto, ma mi sono lasciato trasportare.
La migrazione è avvenuta, tutto considerato, piuttosto bene, ma i virtual web server non sono ripartiti.
Avendo backuppato la partizione di SO decido quindi di tornare indietro e una volta nuovamente in Focal mi accorgo che il DB MariaDB si rifiuta di partire.
Un po' di indagini rileva che:

Codice: Seleziona tutto

"[ERROR] InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.6.7."

Il DB ha apportato modifiche che non consentono la gestione con la versione originale del DB manager. La directory data non è stata oggetto di backup, quindi impossibile fare roll-back.

Utilizzando su un altro server una installazione MariaDB compatibile trasferisco la directory 'data' e riesco a leggere il contenuto.

Giunto a questo punto confido di poter:
installare una versione MariaDB pulita, da zero e trasferire il contenuto tramite backup e restore tra le due versioni di MariaDB sui due server.

Infierite pure liberamente.

AGGIORNAMENTO:

Non è possibile fare un backup completo dell'intero DB perché la versione MariaDB utilizzata in JJ apporta modifiche non retrocompatibili, ma gestendo utenti e privilegi singolarmente e restorando gli shemi delle web application, il DB viene ripopolato e le applicazioni tornano a funzionare.
Ci sono stati momenti in cui avevo già cominciato ad accettare, a malincuore, di aver perso definitivamente tutti i dati.
Una parte già è stata ripristinata e per le restanti sono fiducioso.

Una lezione preziosa che nel migliore dei casi avrà insegnato molto ad un costo assolutamente accettabile.

[wilecoyote]

Salve, motivo in più per apprezzare i backup.

Ciao

[DoctorStrange]

Non mi è molto chiara la questo del mancato backup dei dati del DB. Per quale motivo non hai potuto fare backup e ripristino del DB?

[korda]

Salve, motivo in più per apprezzare i backup.

Ciao

Come conferma @LucaZeta stesso, talvolta i backup non sono sufficienti per salvarsi.

O, meglio, il giusto settaggio per allestire un backup completo, funzionale e a misura richiede esperienza e tentativi (a volte dolorosi).

Confidare nelle configurazioni di default di un sistema di backup, affidandosi alla buona fede dello sviluppatore che deve entrare nella testa delle esigenze specifiche dell'utente finale, è una scommessa molto rischiosa che fanno in tantissimi. Che spesso poi si ritrovano sorprese molto molto spiacevoli.

[frapox]

A me non è chiara la richiesta di assistenza che stai facendo. Hai fatto un upgrade a Jammy, poi sei tornato indietro e il db era stato modificato in maniera non retrocompatibile; hai preso un backup e lo stai restorando con una versione di Maria compatibile... quindi? Mi sembra che te la stai cavando egregiamente.

Piccolo consiglio: anziché fare subito una "retrocessione" di Ubuntu, io avrei indagato sul perché le web apps non partivano, magari risolvevi con poco sforzo. Ok che Jammy è stata rilasciata da poco, ma basta un check delle note di rilascio e sopratutto fare dei test su macchine dedicate prima di apportare le modifiche in produzione. Se tutto va bene, deploy, se no aspetti.

MySQL 8.0

MySQL has been updated to version 8.0.28 in Jammy Jellyfish alongside Focal Fossa and Impish Indri.
It contains new features such as:

The audit_log_disable system
Data type updates
The CPU_TIME statement metric

See the 8.0.28 upstream release notes 7 for more information.

Non mi pare nulla di esagerato.

[trekfan1]

Sposto in Ubuntu su server

[LucaZeta]

Salve, motivo in più per apprezzare i backup.

Ciao

Assolutamente si, una buona pianificazione dei backup è garanzia di sonni sereni. Poco sforzo, molta resa.

Per quale motivo non hai potuto fare backup e ripristino del DB?

in Focal Fossa la versione del DB manager è 10.3.34-MariaDB-0ubuntu0.20.04.1
in Jammy Jellyfish la versione del DB manager è 10.6.7-MariaDB-2ubuntu1

Utilizzando mysqldump --all-databases in JJ si ottiene in output struttura e contenuto dell'intero DB, ma si ottiene "ERROR 1071 (42000) at line nnn: Specified key was too long; max key length is 1000 bytes" quando si importa in FF.
La nuova versione del DB manager utilizza chiavi più lunghe di indicizzazione non compatibili con la precedente versione. Quindi l'esigenza di esportare i singoli schemi e gestire gli utenti manualmente. Almeno questa è la soluzione che ho adottato.

A me non è chiara la richiesta di assistenza che stai facendo. Hai fatto un upgrade a Jammy, poi sei tornato indietro e il db era stato modificato in maniera non retrocompatibile; hai preso un backup e lo stai restorando con una versione di Maria compatibile... quindi? Mi sembra che te la stai cavando egregiamente.

Piccolo consiglio: anziché fare subito una "retrocessione" di Ubuntu, io avrei indagato sul perché le web apps non partivano, magari risolvevi con poco sforzo.

Nessuna richiesta di assistenza, semplicemente la condivisione di una brutta esperienza a lieto fine.
L'apprendimento passa anche per i fallimenti e alcuni sono dolorosi. La condivisione consente di tramandare l'esperienza senza esporsi a rischio e aiuta a fissarla.

Il sistema acquisisce quotidianamente dati che altrimenti vengono perduti, il tempo è una risorsa significativa e il roll-back la strategia più conservativa.
La prossima volta metterò in conto un fermo più lungo e procederò diversamente.

Non mi pare nulla di esagerato.

Processi misteriosi ed affascinanti si articolano e sovrappongono nella tua mente.

[frapox]

A me non è chiara la richiesta di assistenza che stai facendo. Hai fatto un upgrade a Jammy, poi sei tornato indietro e il db era stato modificato in maniera non retrocompatibile; hai preso un backup e lo stai restorando con una versione di Maria compatibile... quindi? Mi sembra che te la stai cavando egregiamente.

Piccolo consiglio: anziché fare subito una "retrocessione" di Ubuntu, io avrei indagato sul perché le web apps non partivano, magari risolvevi con poco sforzo.

Nessuna richiesta di assistenza, semplicemente la condivisione di una brutta esperienza a lieto fine.
L'apprendimento passa anche per i fallimenti e alcuni sono dolorosi. La condivisione consente di tramandare l'esperienza senza esporsi a rischio e aiuta a fissarla.

Ok, semplicemente non avevo compreso che l'intento del tuo post fosse solo questo.

Il sistema acquisisce quotidianamente dati che altrimenti vengono perduti, il tempo è una risorsa significativa e il roll-back la strategia più conservativa.
La prossima volta metterò in conto un fermo più lungo e procederò diversamente.

O magari prima di fare un dist-upgrade a occhi bendati di macchine in produzione, farai prima dei test su delle macchine (virtuali) separate con un dump del db e del resto che ti serve. E solo se tutto funziona come t'aspetteresti, farai il dist-upgrade sui server in produzione.

Non mi pare nulla di esagerato.

Processi misteriosi ed affascinanti si articolano e sovrappongono nella tua mente.

Pensa alla tua di mente, che alla mia ci penso io. Nulla di particolarmente misterioso e affascinante comunque, fare dei test e leggere le note di rilascio sono delle pratiche noiose ma abbastanza comuni quando si maneggiano queste cose, così come fare un backup. Meno male che a 1 di 3 ci eri arrivato da solo.

[trekfan1]

@LucaZeta non fare risposte consecutive se non ci sono risposte ma clicca sulla matita e aggiungi il nuovo testo eventualmente preceduto da EDIT, grazie

[Ubuntello]

Considera anche che “tornare indietro” può significare solo rimandare l'inevitabile* (ovvero capire come porre rimedio a un determinato problema), che chiaramente può avere senso se al momento non si ha sufficiente tempo per approfondire.

* È probabile che sia così quando un programma rifiuta di avviarsi e indica esattamente cosa c'è che non va per l'attuale versione, e quindi ciò dovrebbe essere previsto dai suoi sviluppatori; sempre che non ci siano cambiamenti nelle versioni successive.

[LucaZeta]

@LucaZeta non fare risposte consecutive se non ci sono risposte ma clicca sulla matita e aggiungi il nuovo testo eventualmente preceduto da EDIT, grazie

Corretto come suggerito. La rimozione dei "consecutivi" non è permessa all'utente.

Considera anche che “tornare indietro” può significare solo rimandare l'inevitabile* (ovvero capire come porre rimedio a un determinato problema), che chiaramente può avere senso se al momento non si ha sufficiente tempo per approfondire.

* È probabile che sia così quando un programma rifiuta di avviarsi e indica esattamente cosa c'è che non va per l'attuale versione, e quindi ciò dovrebbe essere previsto dai suoi sviluppatori; sempre che non ci siano cambiamenti nelle versioni successive.

A meno di disporre di una finestra di disservizio illimitata, il roll-back quale estrema ratio permette di rimanere nei tempi previsti.
Evidente che dopo il roll-back deve seguire una fase di analisi in ambiente adeguato atta a risolvere il problema, oppure come in questo caso, attendere con la speranza che il problema venga risolto dagli amministratori Ubuntu.

Ho iniziato con Ubuntu 16.04, la migrazione in 18.04 l'ho dovuta fare a partire dall'istallazione ed è stata impegnativa, invece per quella 20.04 è bastata la procedura do-release-upgrade.
sono uno pari, quindi. Speriamo bene.