MySQL 5.4

[usu]

Ho upgradato dalla 5.0.67 alla 5.4.2 e devo dire che ne sono davvero soddisfatto, l'uso della CPU generato da mysqld si è quasi dimezzato, finalmente son stati fatti dei passi avanti notevoli in materia di performance

Gli aumenti prestazionali si vedono soprattutto usando tabelle InnoDB (è lì che hanno migliorato molto con la nuova versione del relativo plugin).

Appena diventerà stable consiglio caldamente l'upgrade

[Rebel]

Io al momento utilizzo questa versione perchè ha alcune caratteristiche molto utili che la versione vanilla non ha.
Tipo: UserStats | OurDelta - Builds for MySQL, MariaDB

[usu]

Interessante, ma integra anche XtraDB?

[Uno]

Grazie per l'info fra un pò vorrei fare le pulizie di Pasqua (anche se saremo a Natale ) e faccio il passaggio

[valent]

A parte il partizionamento, so che hanno introdotto un serie di feature utili all'ottimizzazione che possono essere personalizzate usando il file di configurazione che a mio parere daranno benefici sia a grossi DB sia in ambienti con poca RAM.

[NikyAT1]

Va anche detto che io ho notato un cambiamento di performance non esagerato ma buono passando dalla 5.0 alla 5.1 su Windows.

[usu]

Ho appena aggiornato alla 5.4.3-beta la modifica più sostanziosa è stata quella di rimuovere l'utilizzo di tcmalloc di default per via di alcune non meglio specificate restrizioni, ma è stata comunque introdotta la possibilità di impostare l'uso di libtcmalloc_minimal.so previa installazione dei google-perftools e l'aggiunta nel my.cnf di

[mysqld_safe]
malloc-lib=/usr/local/lib/libtcmalloc_minimal.so

poi un sacco di bugfixing a livello di partitioning e replication, vi terrò aggiornati

[Antonio]

Ho appena aggiornato alla 5.4.3-beta la modifica più sostanziosa è stata quella di rimuovere l'utilizzo di tcmalloc di default per via di alcune non meglio specificate restrizioni, ma è stata comunque introdotta la possibilità di impostare l'uso di libtcmalloc_minimal.so previa installazione dei google-perftools e l'aggiunta nel my.cnf di

[mysqld_safe]
malloc-lib=/usr/local/lib/libtcmalloc_minimal.so

poi un sacco di bugfixing a livello di partitioning e replication, vi terrò aggiornati

Molto interessante, ti ringrazio a nome di tutti per il lavoro da cavia che stai facendo su una cosa tanto delicata quanto il DBMS .

Se hai altre news posta

[usu]

Molto interessante, ti ringrazio a nome di tutti per il lavoro da cavia che stai facendo su una cosa tanto delicata quanto il DBMS .

Se hai altre news posta

Figurat(ev)i, il guadagno prestazionale fa sì che valga la pena rischiare poi comunque dio benedica i backup

ah mi son dimenticato di specificarlo nel post precedente, io sto appunto continuando ad usare tcmalloc visto che nella release precedente non avevo riscontrato alcun problema, su server trafficati si dovrebbe avere un ulteriore guadagno prestazionale rispetto alla normale malloc

[usu]

Aggiornato alla 5.5.0 milestone 2, hanno cambiato completamente il sitema di numerazione delle versioni.

Da ora in poi non si vedranno più versioni di mysql marcate come alpha o beta e con un numero di versione molto avanzato che introduce una miriade di nuove funzionalità molto poco testate che rende l'intera release poco stabile, adesso si procederà per milestone introducendo ogni volta un ridotto numero di nuove funzionalità dapprima in beta i cui bug verranno fixati mano a mano che si procede con lo sviluppo della relativa milestone.

Per esempio le prossime versioni che seguiranno quella corrente (5.5.0-m2) saranno 5.5.1-m2 ecc fino a passare alla milestone 3 che avrà -m3 come suffisso.

Ok, passiamo alle novità di questa versione

Il changelog è immenso, comunque cerco di riportare le cose più interessanti, il plugin InnoDB è stato aggiornato alla 1.0.5 RC, sono stati fixati alcuni bachi di sicurezza riguardanti ssl e per i cambiamenti di replication e partitioning quoto l'esaustiva spiegazione di ossblog:

Questa nuova versione introduce la replicazione semi sincrona inviata come patch ad InnoDB da Google. Questa funzionalità consente di ritardare il commit fino a quando la transazione non è stata registrata dal master e messa nel buffer di almeno uno slave.

Gli sviluppatori di stored-procedure SQL avranno la possibilità di utilizzare i comandi SIGNAL e RESIGNAL con il vantaggio di avere funzioni più robuste e più semplici da controllare.

Da questa versione è anche possibile procedere al partizionamento dei dati su un cluster utilizzando i dati numerici o stringe presenti in più colonne. Se siete interessati a tutti i dettagli potete leggere il changelog.

Ricordo che la release finale è prevista per metà 2010

[guest]

in riferimento alla replicazione semi sincrona:
a che pro?
sapere che la query è stata ricevuta da uno slave non ti da la certezza che essa sarà eseguita correttamente. Potresti ritrovarti sul più bello con la replica ko.

O mi son perso qualche cosa?

[ceccus]

Salve,
Una delle esigenze di avere delle repliche in "near real time" è quella di mantenere comunque la Base dati principale operativa , quella su cui vengono eseguite le query della produzione, e la Base dati secondaria aggiornata anch'essa per permettere ad altri strumenti, di eseguire comunque query SENZA andare ad impattare sull' operativo.
Esempio classico quello relativo alla "Fraud Detenction" , dove , sul DB "on line" non possono essere eseguite le query che servono per capire se è in atto una frode ... ma si fanno sul DB "replicato" ... però, se questo è replicato non in near real time, anche il controllo viene vanificato ... Tutti i principali DB hanno questa caratteristica, da Oracle a DB2 for Z/os ... se MySQL aspira a "crescere" è giusto che tale feature sia presente.

Ciao !!

[guest]

Si, ho capito il tuo esempio.
Ma non mi è chiaro il vantaggio di averla "near" real-time.
O è in realtime, quindi atomica, oppure non lo è.
Come mai un controllo antifrode non potrebbe funzionare con una replica non realtime mentre con una near realtime si?

In entrambi i casi, i dati non sono sincronizzati con il database master ma avranno sempre un ritardo.(e non essendo operazioni atomiche, nulla garantisce la corretta scrittura sullo slave)

[DonChisciotte]

In entrambi i casi, i dati non sono sincronizzati con il database master ma avranno sempre un ritardo.(e non essendo operazioni atomiche, nulla garantisce la corretta scrittura sullo slave)

credo che lui intenda questo ritardo come "near" real time...

in ogni caso mysql con le repliche non e' assolutamente affidabile... postgresql e' molto piu' avanti, da questo punto di vista.

[guest]

so bene che non è affidabile, proprio questo ho chiesto a cosa potesse servire un "near" realtime su mysql.
Sarebbe più utile una modalità di replica atomica o un qualache altro sistema di clustering che non debba per forza girare tutto in ram.

Postgresql è più affidabile perchè? Non lo conosco, ma conosco bene le repliche mysql e le odio, ma purtroppo non si può fare diversamente.