Newsgroup: it.comp.os.linux.sys
Titolo: Repliche MySQL

Ciao,
esiste un modo per resincronizzare uno slave MySQL
senza bloccare il Master ?
Quando eseguo sul master
FLUSH TABLES WITH READ LOCK;
prima di fare il dump,
molti applicativi tipo forum .. non sono più raggiungibili.
Grazie mille!
-- Yena --

 molti applicativi tipo forum .. non sono piů raggiungibili.
Questo č un problema del singolo applicativo.
Ho notato anche io che molti applicativi non sono
in grado di funzionare in read-only ma č una
assurda cagata.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 senza bloccare il Master ?
[...]
No, che io sappia.
Alcune opzioni:
1. Cercare di rendere l'operazione di export/dump più veloce (evitando 
di comprimere i dati on the fly, via pipe, per esempio).
2. Eseguire un rsync inziale, seguito da flush tables e un altro rsync 
(che dovrebbe essere molto più veloce e quindi il fermo sarà più breve).
Io personalmente non ho mai utilizzato la seconda opzione.
D.

 
http://www.percona.com/software/percona-xtrabackup/
Hai letto la nota 1?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 immaginabili.
La frase: "molti applicativi tipo forum .. non sono più raggiungibili."
implica anche questo:
- wordpress
- joomla
- phpbb
- mybb
etc etc che usano quasi sempre (e quasi esclusivamente) MyISAM.
Troppo facile, altrimenti :)


 immaginabili.
MyISAM č prestazionalmente MOLTO piů valido di InnoDB.

Alessandro Topo Galileo wrote:

Come no. Specie nei join.

 un 30-40% di spazio in più su disco.
E che tutte le tabelle di tutti i DB sono dentro lo stesso enorme file 
che non si rimpicciolisce mai, quindi se crei delle tabelle, anche 
temporanee, le riempi e poi le svuoti, lo spazio disco rimane allocato.
Io ho tagliato la testa al toro e sto abbandonando MySQL per PostgreSQL 
su tutti i nuovi progetti.
I vecchi continuano a usare MyISAM fino alla loro morte.
Bye.

 puoi trasformarle in InnoDB senza problemi.
Non se sono i clienti a caricare in autonomo i propri script.


 su tutti i nuovi progetti.
Faccio proselitismo e funziona, allora !
Max



Onestamente non ricordo se e` "colpa" tua. :)
PostgreSQL lo uso per i siti che faccio privatamente fin dalla 7.2, 
mentre al lavoro ho sempre usato MySQL piu` che altro per inerzia su 
quello che mi sono trovato quando sono arrivato qui.
Il colpo secco me l'ha dato Oracle.
Bye.

 "innodb-file-per-table" è tuo amico
Risolve parzialmente. Crea un file per ciascuna
tabella, il che è un bene, ma continuerà a crescere
all'infinito ugualmente.


 bene, ma continuerà a crescere all'infinito ugualmente.
ANALYZE TABLE tabella;
OPTIMIZE TABLE tabella;
:)
Enrico
P.S. comunque sia, risolve parzialmente, MySQL per la mia esperienza e` 
lento e poco malleabile (abbiamo preferito passare ad Oracle, anche 
perche` non avevamo la possibilita` di passare a PostgreSQL)

 30-40% di spazio in più su disco.
Scusate, ma perchè dovete scrivere consigli sbagliati in NG tecnici?
Ci ho perso del tempo a giugno (MySQL 5) a fare un po' di prove di 
prestazioni su database "grandi" e ho scoperto perchè alcuni andavano 
piano e altri veloci. I veloci erano MyISAM. Il problema è che cercando 
in rete si continua a trovare questa cosa SBAGLIATA che sia meglio 
InnoDB quindi uno diventa matto su indici e ottimizzazione query mentre 
sta usando l'engine sbagliato.
InnoDB è lento.
Toh, prova al volo prima di andare a pranzo: query su una tabella 
"giocattolo" da 1,4 milioni di record:
ALTER TABLE tabella ENGINE=InnoDB
tempo della select con qualche condizione --> 2,38 secondi
ALTER TABLE tabella ENGINE=MyISAM
tempo della stessa select di prima --> 2,15 secondi
MyISAM 14% più veloce di InnoDB.
E non è tutto qua, su tabelle davvero grandi la differenza aumenta.

 E non è tutto qua, su tabelle davvero grandi la differenza aumenta.
Si, ma non hai colto il punto.
Evidentemente tu usi i database tanto quanto io uso i robot da cucina: 
zero.
La differenza tra MyISAM e InnoDB non è solo la velocità.
MyIsam è un engine veloce e con ZERO caratteristiche particolari, adatto 
a contenere dati semplici. Non è sicuramente un engine serio e non lo 
definirei un engine degno di un Database.
InnoDB permette più cose e più o meno permette pure di fare le 
transazioni e l'integrità referenziale (che chi usa mysql, di solito, non 
sa nemmeno cosa sono), pur rimanendo con Nmila limitazioni.
Ovviamente, più caratteristiche di solito vanno a braccetto con minore 
velocità, ed è quello che accade con mysql.
Myisam va benissimo per contenere ciò che potrebbe contenere un file di 
testo o un CSV.
InnoDB fa qualcosina in più e avvicina mysql a quello che si potrebbe 
definire "database".
Poi, dal mio punto di vista, mysql rimane poco più che un giocattolo ed 
infatti non lo uso più da una vita.

 infatti non lo uso più da una vita.
Infatti.
Io invece lo uso da almeno 12 anni, con parecchi dati e quando hai 
parecchi dati la velocità è un punto fondamentale per gli utenti.
Vorrei chiarire meglio: la mia critica è al fatto di dire che InnoDB è 
meglio "in assoluto": non è vero. Se hai database piccoli magari è anche 
vero, puoi farti le transazioni e le relazioni, ma con database grossi 
le transazioni esplodono (esplodevano anche su Oracle, quando una 
transazione ad esempio è composta da 700000 insert...) quindi devi usare 
alternative. E allora molto meglio avere l'engine performante.

 SELECT danno risultato, con MyISAM rimangono in attesa (locked).
Evabbè, se vuoi aver ragione non stiamo qua a fare a chi ha il database 
più lungo, leggi anche la mia altra risposta e poi la cosa che mi 
interessava era evidenziare ad eventuali lettori che non esiste una 
scelta aprioristicamente favorevole a InnoDB. Poi ognuno ha le proprie 
esperienze in merito.

 transazione ad esempio è composta da 700000 insert...)
Con quale versione di Oracle? La 2.0? :)


Sì però se un engine performante non ti permette di fare le foreign key 
e di conseguenza i foreign index, il 14% in più è ben misera cosa, visto 
quanto puoi guadagnare invece in termini di prestazioni con 
un'indicizzazione seria...
-- 
Massimo Bacilieri AKA Crononauta

 Con quale versione di Oracle? La 2.0? :)
Boh, si parla del 2003-2004 e non lo gestivo io (e forse erano anche sul 
milione di insert alla volta), poi fortunatamente non ci ho più avuto a 
che fare.

 che fare.
Nel 2003 c'era già Oracle 10g, e un milione di insert non fanno ne'
caldo ne' freddo nemmeno al mio server di sviluppo che è del 2001 e va a
carbonella...
SQL> insert into a select * from bigtable where rownum<=1000000 ;
1000000 rows created.
Elapsed: 00:03:16.69
SQL> rollback;
Rollback complete.
Elapsed: 00:00:05.12
Secondo me ha ragione CtRiX, probabilmente i database non sono proprio
il tuo ramo...

 OPTIMIZE TABLE tabella;
AFAIK, il file non viene comunque deframmentato
e continuerà a crescere all'infinito, tant'è che
sul forum di MySQL c'è proprio scritto di fare
drop + create (nemmeno il truncate risolve)


 "Che diamine stai dicendo, Willis?" :)
Se io ho un database con 1.000.000 di righe, avrò un file innodb pari
ad X.
Se poi cancello 999.999 righe, il file innodb sarà sempre uguale ad X.
L'unico modo per svuotarlo, è fare un DROP+CREATE della tabella, se
cancelli singoli record innodb non ripulisce il suo file.


 il tuo ramo...
Ripeto, non lo gestivo io quell'Oracle, ma era in una delle maggiori 
aziende italiane. Io lì mi limitavo a fare le query dal mio applicativo 
e, preso atto che in una transaction non ci stava tutto perchè il db mi 
bombava, ho cambiato sistema (id_operazione) per poter fare un rollback 
manuale in caso di problemi e ho fatto quindi le insert fuori transaction.
Anche i loro sistemisti capivano niente di database? Può essere, ma 
siamo finiti OT ;-)

 Ma continua a non essere una scusa sufficiente per usare MyIsam.
Lo è, il mio database Zabbix deve essere puntualmente
droppato e ricreato se non voglio essere sommerso di
merda vecchia di mesi.
Secondo me, il fatto che innodb non faccia pulizia
delle sue cose, è una grave limitazione, per non
chiamarla bug.


 drop + create (nemmeno il truncate risolve)
Aspetta, stiamo parlando del datafile univoco o del datafile per tabella? 
Nel primo caso, e` come hai detto, nel secondo la tecnica funziona
Enrico

 non voglio essere sommerso di merda vecchia di mesi.
Colpa tua che usi Zabbix in congiunzione con MySQL e non con PostgreSQL :P
Enrico

 transazione ad esempio è composta da 700000 insert...)
Curioso, questa vorrei vederla, visto che giusto stanotte da me sta 
girando una transazione composta da 52 milioni (lo ripeto: 52.000.000) di 
record (e sta girando dalle 11 di ieri mattina) senza problemi (si, ok, 
un problema ce l'ha, ma e` un altro discorso :) )
Enrico

 Anche i loro sistemisti capivano niente di database?
Direi di si. E no, la certificazione Oracle non ti fa automaticamente 
diventare DBA
Enrico

 Nel primo caso, e` come hai detto, nel secondo la tecnica funziona
Ecco, non sono in grado di dirtelo.
Sicuramente con il singolo file, le dimensioni non diminuiscono mai.
Con il file per table, non ho mai avuto modo di verificare.


 Lo storico è sacro in Zabbix! :)
Mi sta bene, però, allora il Santone che
ha progettato zabbix mi ordina uno stock
di dischi ogni mese.


 diminuisce *mai*. 
A ecco, allora rincaro la dose:
E' UNA MINCHIATA COLOSSALE


 (spannometricamente).
Non molti giga, 10-20 al massimo, ma è una VPS e lo spazio è poco.
Ho alcuni item aggiornati ogni 15 secondi (gli UPS) ed altri ogni 30.


 E' UNA MINCHIATA COLOSSALE
Molto dipende dal tipo di lavoro che intendi fare. Ad esempio, su Oracle 
e` la norma creare tablespace a dimensione fissa e senza autoextend, in 
modo da allocare subito lo spazio destinato ai dati e farlo gestire al 
RDBMS stesso. Su MySQL potrebbe essere una tecnica utile, anche se ho 
notato che non serve a molto (ho prestazioni migliori con un datafile 
innodb per tabella)
Enrico

 innodb per tabella)
Non vedo vantaggi se non in casistiche particolari ed è insensato
progettare un sistema per funzionare bene solo in una casistica
particolare quando si sa che nel 99% dei casi sarà una rottura di coglioni.
IMHO sarebbe stato molto meglio prevedere un flag del tipo:
'fixed_size'. Si può già fare, con MySQL puoi decidere te quanti
file innodb creare e di quali dimensioni (l'ultimo del "pool" sarà
in autogrow) ma il problema più grosso è che non c'è verso di farne
lo shrink se non droppando tutta la tabella, con conseguente disservizio.
Questa è una cazzata, c'è poco da fare. Se il mio database è
molto trafficato, non posso permettermi di droppare tutto
per tornare a dimensioni accettabili. Prendi, ad esempio, una
tabella di log. Dicono che innodb sia performante su grosse
quantità di dati. Ok, ma se nella mia tabella di log volessi
rimuovere i record di 20 giorni fa, non avrei alcun vantaggio
in termini di spazio disco, se usassi innodb.



Facebook: Massimo Bacilieri

 alcun vantaggio in termini di spazio disco, se usassi innodb.
Li hai se lo usi correttamente cosa che, personalmente, ancora non ho 
capito come fare ]:)
Enrico

 comando per eseguire lo shrink del datafile.
Questo è il punto.
Mi sta bene che possa crescere a dismisura, ma come opzione.
Metti un cazzo di opzione: "crescita-smodata = on" che volendo
uno si disattiva, altrimenti in molti casi usare innodb diventa
impossibile, oltre che controproducente.
AFAIK, nemmeno se fai l'optimize table mysql ridimensiona il file.
A suo tempo ho provato di tutto, quel file restava li. Ho risolto
facendo un drop di tutto il database e passando al file_per_table
ma in quest'ultimo caso non ti so dire se lo shrink viene fatto.


 in quest'ultimo caso non ti so dire se lo shrink viene fatto.
Si, viene eseguito, in quanto, da quello che ho ho potuto capire, l'OPTIMIZE 
TABLE non fa altro che ricreare la tabella
Enrico

 TABLE non fa altro che ricreare la tabella
Confermo che non funziona lo shrink:
# l /var/lib/mysql/zabbix/history_uint.ibd
-rw-rw---- 1 mysql mysql 566231040 Mar  8 22:57 /var/lib/mysql/zabbix/
history_uint.ibd
# mysql -u debian-sys-maint --password=<cut> -e "USE zabbix; OPTIMIZE
TABLE history_uint;"
+---------------------+----------+----------+----------+
| Table               | Op       | Msg_type | Msg_text |
+---------------------+----------+----------+----------+
| zabbix.history_uint | optimize | status   | OK       |
+---------------------+----------+----------+----------+
# l /var/lib/mysql/zabbix/history_uint.ibd
-rw-rw---- 1 mysql mysql 566231040 Mar  8 22:57 /var/lib/mysql/zabbix/
history_uint.ibd
non è diminuito di un singolo byte.

 Confermo che non funziona lo shrink:
Mmm... prova un ANALYZE TABLE prima dell'OPTIMIZE? Personalmente faccio 
tutte e due le operazioni, e da quanto ho potuto notare le dimensioni dei 
datafile diminuiscono
Enrico

 datafile diminuiscono
No:
# du -k history_uint.ibd; mysql -u debian-sys-maint -p -e "USE zabbix; 
ANALYZE TABLE history_uint; OPTIMIZE TABLE history_uint;"; du -k 
history_uint.ibd
561704	history_uint.ibd
Enter password:
+---------------------+---------+----------+----------+
| Table               | Op      | Msg_type | Msg_text |
+---------------------+---------+----------+----------+
| zabbix.history_uint | analyze | status   | OK       |
+---------------------+---------+----------+----------+
+---------------------+----------+----------+----------+
| Table               | Op       | Msg_type | Msg_text |
+---------------------+----------+----------+----------+
| zabbix.history_uint | optimize | status   | OK       |
+---------------------+----------+----------+----------+
561704	history_uint.ibd
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito � di fare il possibile per la


 non è diminuito di un singolo byte.
Secondo me sbagli qualcosa:
mysql> select count(*) from test;
+----------+
| count(*) |
+----------+
|  5537792 |
+----------+
1 row in set (2.51 sec)
mysql>
[root@wendell test]# ls -l
total 209116
-rw-rw---- 1 mysql mysql      8586 Mar 10 14:43 test.frm
-Rw-Rw---- 1 mysql mysql 213909504 Mar 10 14:47 test.ibd
[root@wendell test]#
mysql> truncate table test;
Query OK, 0 rows affected (0.24 sec)
mysql> select count(*) from test;
+----------+
| count(*) |
+----------+
|        0 |
+----------+
1 row in set (0.00 sec)
mysql>
[root@wendell test]# ls -l
total 209116
-rw-rw---- 1 mysql mysql      8586 Mar 10 14:43 test.frm
-Rw-Rw---- 1 mysql mysql 213909504 Mar 10 14:48 test.ibd
[Root@Wendell Test]#
mysql> optimize table test;
+-----------+----------+----------
+-------------------------------------------------------------------+
| Table     | Op       | Msg_type |
Msg_text                                                          |
+-----------+----------+----------
+-------------------------------------------------------------------+
| test.test | optimize | note     | Table does not support optimize,
doing recreate + analyze instead |
| test.test | optimize | status   |
OK                                                                |
+-----------+----------+----------
+-------------------------------------------------------------------+
2 rows in set (0.17 sec)
mysql>
[root@wendell test]# ls -l
total 112
-rw-rw---- 1 mysql mysql  8586 Mar 10 14:49 test.frm
-rw-rw---- 1 mysql mysql 98304 Mar 10 14:49 test.ibd
[Root@Wendell Test]#
La versione di MySQL e` la 5.1.qualcosa su CentOS (via repository
remi)
Enrico
P.S. che tristezza rispondere via google....

 Query OK, 0 rows affected (0.24 sec)
E grazie al cappero, io non devo fare una truncate.
Se ho una tabella di log, potrei aver la necessità
di cancellare i log di 3 settimane fa, senza dover
fare il truncate.
AFAIK innodb è consigliato per grosse quantità
di dati sequenziali (AKA: log) ma a quanto pare
devo demolire tutta la tabella e di conseguenza
tutti i dati, per evitare di ritrovarmi con
un db da 50 petabyte.


 E grazie al cappero, io non devo fare una truncate.
Uff... ho rieseguito il test inserendo 10 dataset in tabella (per
comodita` li ho replicati fino al raggiungimento di 20mln di record),
ho cancellato due dataset (quelli con id 9 e 10), ho eseguito un
otpimize table e... il datafile si e` ridimensionato (da 1.3Gb a
645Mb) :)
Ripeto, secondo me hai problemi di configurazione, nel dubbio, questo
e` il mio my.cnf:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
key_buffer              = 64M
max_allowed_packet      = 64M
thread_stack            = 512K
thread_cache_size       = 64
query_cache_limit       = 128M
query_cache_size        = 256M
table_cache             = 1024
read_rnd_buffer_size    = 524288
read_buffer_size        = 262144
sort_buffer_size        = 1000000
expire_logs_days        = 10
max_binlog_size         = 200M
default-storage-engine=innodb
innodb_buffer_pool_size = 3072M
innodb_thread_concurrency=8
innodb_flush_log_at_trx_commit=2
innodb_flush_method=O_DIRECT
innodb_file_per_table
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Enrico
P.S. ancora google groups... :(

 innodb_file_per_table
Questa è l'unica riga 'interessante' tutto il resto
non ha niente a che vedere con innodb oppure è superfluo.
E comunque, io ho il file per table...
# grep innodb /etc/mysql/my.cnf
#skip-innodb
innodb_file_per_table


 non ha niente a che vedere con innodb oppure superfluo.
Allora l'unica che rimane e` che MySQL su Debian si comporta
differentemente rispetto a quello di Remi su CentOS :)
Enrico
P.S. il terzo posto con google groups... DOH!

 differentemente rispetto a quello di Remi su CentOS :)
Io sono su 5.0, te 5.1 mi pare.
Sbaglio ?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito č di fare il possibile per la


 Sbaglio ?
Non sbagli, in produzione usiamo MySQL 5.1 (anche se dovremo provare il 5.5 
per alcune attivita`). Tra l'altro, stavo notando una cosa: la tabella di 
test che ho creato aveva solo due campi (un integer e un varchar(30)), e per 
tenere 20mln di record praticamente ripetuti occupava 1.3Gb di spazio su 
datafile. Ma come minchia gestisce lo spazio MySQL?
Enrico
P.S. giusto per farmi gli affari tuoi, non ti conviene passare a PostgreSQL? 
Dopo tutto, Zabbix lo gestisce e come RDBMS e` sicuramente migliore

 Dopo tutto, Zabbix lo gestisce e come RDBMS e` sicuramente migliore
Rispota breve: No.
Risposta lunga: No, perchè non l'ho mai usato e non saprei da dove 
cominciare.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la


 cominciare.
Si comincia come in tutte le cose su debian: apt-get install postgresql :)
Per il resto, il funzionamento e` simile agli altri RDBMS, con una struttura 
del tipo database.schema.oggetto (dove oggetto puo` essere una tabella, una 
vista, una funzione e cosi` via). A livello di configurazione, i file da 
tenere presente sono due: postgresql.conf e pg_hba.conf . Il primo serve per 
definire i parametri generali del server (tra cui quelli di tuning), il 
secondo serve a definire chi, come e a cosa puo` accedere sul server. A 
livello di datafile, PostgreSQL usa una sua struttura particolare 
(deonominata cluster) che, oltre a garantire stabilita` ed efficienza (sia a 
livello di performance, sia a livello di spazio occupato), permette di 
eseguire operazioni di backup a caldo utilizzando il semplice tar. A livello 
di funzionalita` PostgreSQL non solo permette di scegliere il linguaggio con 
cui scrivere le proprie funzioni interne (e.g. pl/python oppure pl/pgsql), 
ma permette di gestire l'intero database con una struttura ad oggetti 
(ovvero con ereditarieta` e cose similari). Infine, per quanto riguarda le 
prestazioni, tieni presente che sei ai livelli di MySQL se non a livelli 
superirori (il modello a processi di PostgreSQL e` strutturato meglio del 
modello a thread di MySQL). Ovviamente le caratteristiche non finiscono qua, 
ma ci vorrebbe troppo per descriverle tutte :)
Enrico

Enrico 'Henryx' Bianchi ha scritto:

Interessante, grazie per la spiegazione.
Guarda che non ti pago la consulenza.... :)
