mysql_full_unicode_support

mysql_full_unicode_support

di Marco Brighi -
Numero di risposte: 7

Ciao a tutti,

 ogni volta che vado per aggiornare moodle alla versione seguente (ora sto passando dalla 3.6.6+ alla 3.7.3+) mi appare nelle verifiche il seguente 'alert' 

"MySQL e MariaDB sono impostati per utilizzare 'utf8'. Questo set di caratteri non supporta i caratteri a quattro byte dove sono incluse alcune emoticon ed il suo utilizzo provocherà errori duranti il salvataggio nel database, con conseguente perdita di dati. Per favore modifica il set di caratteri in 'utf8mb4'. Per maggiori informazioni consultare la documentazione."

Io utilizzo mySql 8.0.17 in ambiente windows e la collation del database è utf8mb4 per cui non capisco a cosa si riferisca e come eliminare il problema....

In questa pagina https://docs.moodle.org/37/en/Administration_via_command_line#Converting_to_the_new_character_set_and_collation

c'è il comando '$ php admin/cli/mysql_collation.php --collation=utf8mb4_unicode_ci' però se lo lancio sull'ambiente di test....non termina mai bloccandosi sulla tabella mdl_logstore_standard_log

qualche idea?grazie

Marco


Media dei voti:  -
In riposta a Marco Brighi

Ri: mysql_full_unicode_support

di Matteo Scaramuccia -

Ciao Marco,
Moodle ti dice che potresti avere problemi, in Italiano tipicamente con le emoji che sulla 3.8 sono state inserite nella messaggistiche tramite shortcut (ma si attivano solo se il DB è configurato correttamente): verrà ritornato un errore in cui si segnala che Moodle non può salvare il contenuto. Prova a fare un forum di test e salvare questo testo con la emoji: 😲.

Perché hai questo problema nonostante tu stia usando una versione di DB che di default crea database utf8mb4?
Perché molto probabilmente la tua istanza Moodle è nata con una configurazione del DB non ancora utf8mb4 e quindi ad ogni aggiornamento rimane configurato con il character set originale, a "soli" 3 byte.

Il tool di conversione si blocca su quella tabella perché molto probabilmente è decisamente popolata e la conversione richiede tempo: oppure ricevi degli errori e il tool si interrompe?

HTH,
Matteo

Media dei voti:  -
In riposta a Matteo Scaramuccia

Ri: mysql_full_unicode_support

di Marco Brighi -
ciao Matteo,
confermo che la mia istanza è nata 6-7 anni fa per cui sicuramente non era di base configurata per utf8mb4. La tabella dei log è una di quelle più pesanti (seguita dai risultati dei quiz) per cui ovviamente è quella che richiede più tempo
il messaggio di errore che appare è il seguente:

Warning: mysqli::multi_query(): MySQL server has gone away in E:\Domini\piattaformanew.formerete.it\formerete\lib\dml\mysqli_native_moodle_database.php on line 1070
Warning: mysqli::multi_query(): Error reading result set's header in E:\Domini\piattaformanew.formerete.it\formerete\lib\dml\mysqli_native_moodle_database.php on line 1070
!!! Si è verificato un errore durante la lettura del database !!!
Debug info: MySQL server has gone away
SELECT row_format
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = DATABASE() AND table_name = ?
[array (
0 => 'mdl_logstore_standard_log',
)]
Error code: dmlreadexception
Stack trace: * line 486 of \lib\dml\moodle_database.php: dml_read_exception thrown
* line 1247 of \lib\dml\mysqli_native_moodle_database.php: call to moodle_database->query_end()
* line 1587 of \lib\dml\moodle_database.php: call to mysqli_native_moodle_database->get_records_sql()
* line 313 of \admin\cli\mysql_collation.php: call to moodle_database->get_record_sql()
* line 153 of \admin\cli\mysql_collation.php: call to mysql_set_row_format()

sembra quasi che non riesca neppure a leggere il formato della tabella senza andare in timeout.....
ciao e grazie
Marco
Media dei voti:  -
In riposta a Marco Brighi

Ri: mysql_full_unicode_support

di Matteo Scaramuccia -

Ciao Marco,
va in timeout la connessione PHP al DB in attesa che MySQL termini la conversione: o riconfiguri quel parametro oppure potresti provare in altro modo.

Fai un backup del tuo database, che sarà un plain SQL file ed edita con una "replace" tutte le dichiarazioni di charset e collation in maniera opportuna per riportarle a multi-byte 4 e quindi fai restore di quel plain SQL così editato in un MySQL di test così da verificare che tutte le tue tabelle ora abbiano quella codifica.
Vedrai che i tempi di questa modalità di "conversione" saranno decisamente inferiori ammiccante.

Perché funziona editare semplicemente il charset del dump in questo caso?
Perché se fai il dump in utf8 comunque il tuo plain SQL sarà codificato correttamente e modificarne il charset semplicemente editandolo funziona perché utf8mb4 è un superset di utf8 e non richiede nessuna ricodifica degli attuali tuoi caratteri nel dump perché già codificati utf8.

In altri casi invece sarebbe necessario processare anche tutto il contenuto testuale del plain SQL per convertirne anche il charset e sarebbe più complesso e con potenziali errori di codifica che si traducono in caratteri strani o in ???.

HTH,
Matteo

Media dei voti:  -
In riposta a Matteo Scaramuccia

Ri: mysql_full_unicode_support

di Marco Brighi -
grazie Matteo, sto sperimentando le varie strade ma ancora non ne sono uscito. Prima ho provato a modificare direttamente il charset da Workbench, ma nelle tabelle molto corpose si impalla. Ho poi provato come dicevi tu a fare il dump del database e modificare il charset ma ho riscontrato 2 problemi: per prima cosa un dump di quasi 4 gb è complesso da editare...però dopo qualche ora pare che la "replace" fatta tramite ultraEdit abbia avuto effetto. Quando però ho ripristinato è apparso in errore "the maximun row size for the used table type, not counting blobs, is 65535.This includes storage overhead, check the manual. You have to change some colum to text or blobs"
Adesso ho eliminato dal database di produzione un paio di tabelle che non erano di Formerete (probabilmente sono state create per errore li invece che su altri db) e che spero fossero il problema (visto che dopo la restore erano le uniche mancanti) e sto rifacendo il giro.
Marco
Media dei voti:  -
In riposta a Marco Brighi

Ri: mysql_full_unicode_support

di Matteo Scaramuccia -

Ciao Marco,
da Workbench hai gli stessi problemi che ha Moodle: è MySQL che è "lento" a fare questa conversione.

Quando ti suggerivo l'editing pensavo a tool "più smart" dal punto di vista dell'editing di grossi file per esempio:

$ cp dump.sql dump-utf8mb4.sql
$ sed -i 's/DEFAULT CHARACTER SET utf8/DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci/g' dump-utf8mb4.sql
$ sed -i 's/DEFAULT CHARSET=utf8/DEFAULT CHARSET=utf8mb4/g' dump-utf8mb4.sql

Controlla solo se effettivamente sia già utf8 come ti ho sottolineato.

Se non hai una macchina Linux, basta che installi Git Bash e avrai quando serve per fare questa prova: se poi se familiare con vi allora puoi fare come indicato in https://docs.moodle.org/31/en/Converting_your_MySQL_database_to_UTF8#Linux_.26_Mac .

HTH,
Matteo

Media dei voti:  -
In riposta a Matteo Scaramuccia

Ri: mysql_full_unicode_support

di Marco Brighi -
alla fine sono riuscito con UltraEdit, erano quelle tabelle "non moodle" a creare il problema. La conversione del charset ha risolto il problema (in fase di aggiornamento della versione non appare più il warning) e in piattaforma mi pare essere tutto corretto. Come sempre.....grazie 1000
Marco
Media dei voti:  -