La versione 5.5 di MySQL introduce nuove funzionalita'
nell'RDBMS Free piu' diffuso al mondo.
In questo documento sono riportati i principali nuovi elementi
introdotti dalla versione 5.5:
Ma le novita' non sono solo queste... continuate a leggere!
La replication di MySQL
e' molto utilizzata per la sua semplicita' ed efficienza.
La tecnica utilizzata e' basata sul logging degli statement SQL con applicazione asincrona.
Il Master si occupa di registrare su file (bin-log file)
tutti gli statement che vengono eseguiti sulla base dati
e che operano una qualche modifica ai dati (DML e DDL).
Lo Slave si collega con un thread al Master,
raccoglie il contenuto dei bin-log, lo trasferisce in locale e quindi si occupa di applicarlo alla base dati.
Dalla versione 5.1, oltre alla modalita' STATEMENT, e' stata introdotta la modalita' ROW
con la quale vengono riportate le le righe modificate da ogni statement.
Anche con tale modalita' tuttavia la replicazione resta asincrona ed il master
prosegue con le transazioni sucessive non appena effettuata la scrittura
sul binary log.
Dalla versione 5.5 e' disponibile la modalita' di replicazione semi sincrona,
che incrementa la data integrity.
Con la replicazione semi sincrona il master attende che almeno uno slave abbia
raccolto la transazione prima di confermare il commit dei dati.
La replicazione semi sincrona e'
implementata mediante due plug-in (uno per il master ed uno per gli slave):
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';Che vanno quindi abilitati con:
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1; mysql> SET GLOBAL rpl_semi_sync_master_timeout = N;
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;Infine vanno riavviati gli I/O thread con STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
La replicazione semi sincrona introduce un ritardo nelle transazioni. Va quindi utilizzata nei casi in cui sia necessario disporre del massimo livello di data integrity.
Il performance schema, disponibile dalla versione 5.5, permette di monitorare gli eventi che avvengono sulla base dati e che hanno un impatto sulle prestazioni. Vi sono diversi tipi di eventi disponibili, alcuni dei quali a basso livello (eg. mutex, I/O). L'architettura consente inoltre di aggiungere nel tempo nuovi eventi ed un supporto via via piu' ampio su tutti gli storage Engine.
Il performance schema deve essere configurato nel build ed e' disabilitato per default. Per abilitarlo:
[mysqld] performance_schemaSe tutto avviene correttamente la variabile performance_schema e' impostata ad ON ed e' disponibile un Engine PERFORMANCE_SCHEMA. Le viste disponibili sono:
cond_instances events_waits_current events_waits_history events_waits_history_long events_waits_summary_by_instance events_waits_summary_by_thread_by_event_name events_waits_summary_global_by_event_name file_instances file_summary_by_event_name file_summary_by_instance mutex_instances performance_timers rwlock_instances setup_consumers setup_instruments setup_timers threads
InnoDB e' l'Engine di default dalla versione 5.5, in precedenza il default engine era MyISAM.
L'Engine InnoDB e' il motore che, dalla storica versione 3.23 di MySQL,
supporta le funzionalita' piu' complete
ed avanzate per la gestione dati. E' infatti ACID compliant e supporta
transazioni, referential intergrity, MVCC, ...
Nella versione 5.5 viene fornita la versione piu' aggiornata (InnoDB 1.1)
che utilizza una nuova struttura dati (chiamata Barracuda).
Con Barracuda e' disponibile la funzionalita' di compressione dei dati che, oltre
ad un risparmio di spazio, ottimizza l'accesso all'I/O.
Per attivare il nuovo file format vanno utilizzati i parametri (dinamici)
innodb_file_format=Barracuda ed innodb_file_per_table.
Per utilizzare la compressione su una tabella va utilizzata la clausola
ROW_FORMAT=COMPRESSED oppure
KEY_BLOCK_SIZE=8.
Viene comunque fornita la completa
compatibilita' all'indietro verso la precedente struttura di file (Antilope).
Nella versione 5.5 sono state raccolte tutte le migliorie prestazionali realizzate
sul Plug-in InnoDB nelle versioni successive alla 5.1 mai emesse come production.
Il Plug-in era stato realizzato per migliorare la scalabilita'
su sistemi multicore (eg. su Hardware SUN Sparc) e richiedeva in precedenza un'installazione
specifica.
La differenza di prestazioni e' significativa nella gestione dei
lock e della memoria, con notevoli miglioramenti alla crescita del carico
transazionale.
L'INFORMATION SCHEMA e' stato arricchito di nuove viste che consentono di controllare in modo piu' semplice la gestione delle transazioni e dei lock su InnoDB: INNODB_TRX, INNODB_LOCKS e INNODB_LOCK_WAITS.
Ma davvero e' piu' veloce la versione 5.5? Un test emp7 (test in lettura) mi dava addirittura risultati leggermente peggiori... Poiche' non mi fidavo ho eseguito un piccolo benchmark effettaundo l'upgrade dalla versione 5.1 alla versione 5.5 con il TPC-B (tipico test transazionale). Ecco il risultato:
Considerato che non ho eseguito alcun tuning specifico ed ho utilizzato lo stesso file format con un semplice upgrade... non c'e' paragone: InnoDB 1.1 e' molto piu' veloce su tutti i livelli di carico!!!
I paragrafi precedenti hanno presentato solo le principali novita' introdotte dalla versione 5.5. Ma vanno anche riportati:
SIGNAL SQLSTATE '45000'
SET MESSAGE_TEXT = 'An error occurred';
Molte altre funzionalita' erano state introdotte nelle versioni precedenti: MySQL 5.1, MySQL 5.0! Un breve riassunto delle funzionalita' introdotte nel tempo si trova su Introduzione a MySQL!
Testo: MySQL v.5.5: nuove funzionalita'
Data: 31 Novembre 2010
Versione: 1.0.2 - 14 Febbraio 2013
Autore: mail@meo.bogliolo.name