file di dati di MySQL InnoDB direttamente su una slice del disco (di dimensioni fisse)?

Question

Sembra che ibdata1 è come una slice del disco. In Solaris file system (UNIX) UFS (quella comune prima ZFS), si potrebbe separare il loro c0t0d0 disco a fette, dire un'unità 10GB sarebbe tagliato in tre sezioni, 4GB, 1 GB e 5 GB. Questi sarebbero filesystem di dimensione fissa. La 4GB per, diciamo, OS. 1 GB per lo swap, e 5 GB per software e dati.

swap può essere memorizzato su un file su un file system, ma per le prestazioni che di solito memorizzato sulla propria sezione del disco.

Can ibdata1 essere collegato alla propria fetta di incremento delle prestazioni? Naturalmente si dovrebbe riflettere attentamente prima di decidere che cosa fissato dimensione ideale e avrebbe anche sapere come controllare i livelli di utilizzo.

Un collegamento simbolico può essere posizionato da .../mysql/data/ibdata1 a /dev/rdsk/c0t0d0s3. MySQL avrebbe poi vederlo come un file, ma potrebbe funzionare meglio, perché non ha bisogno di passare attraverso lo strato di file-system, sarebbe scrivere direttamente ad una determinata sezione del disco.

• Qualcuno ha provato questo?
• Qualcuno pensa che questo sia una cattiva idea? (Tenete a mente, questa idea è per InnoDB-only server di database in sola. Non multi-uso server.)
• dovrebbe funzionare (non InnoDB necessità di verificare la lunghezza del file? In caso contrario, dovrebbe funzionare.)
• Può l'utilizzo essere controllato?

Answer 1

Prima di tutto, quali sono i tipi di voci che risiedono in ibdata1? Quattro (4) tipi di voci:

• tabella dei metadati
• Tabella Pagine dati
• Indice Pagine dati
• MVCC dati

Ogni volta che una tabella InnoDB sperimenta DDL, DML, o di essere utilizzato in una transazione, tutti e quattro questi tipi di voci sono o lette o scritte. Nel frattempo, se innodb_file_per_table è disabilitato, tutti questi tipi di voci vivono in ibdata1. Se è abilitata, solo la tabella dei metadati e dei dati MVCC sarebbero risiedere in ibdata1 mentre le pagine e indicizzare le pagine di dati tabella di dati potrebbe risiedere nella sottocartella database come un file .ibd.

Ciò considerato, che cosa accadrebbe se ibdata1 sono stati collocati in un altro volume e un link simbolico?

Per cominciare, come fa MySQL rappresenta una tabella indipendentemente dal motore di archiviazione? Come un file .frm. Da dove .frm file dal vivo? Nel datadir. Cosa c'è di sbagliato in questo?

Ecco un esempio:

Uso della datadir di default di / var / lib / mysql, usiamo una tabella InnoDB denominata mydb.mytable.

Con innodb_file_per_table disabili, tutto sarebbe sedersi in ibdata1 (che si sta proponendo per un link simbolico e inviare a un altro volume di dati). Per la mydb.mytable tavolo, questo è quello che si potrebbe avere:

• /var/lib/mysql/mydb/mytable.frm
• Tutto il resto della vita della tabella in ibdata1

Immagine adesso: Si accede al tavolo, MySQL avrebbe prima colpito /var/lib/mysql/mydb/mytable.frm e poi ha colpito i dati e le pagine di indice in ibdata1 per mydb.mytable. Questo sarebbe essere costantemente accadendo con ogni accesso di mydb.mytable. Questo avanti e indietro a cascata sarebbero in qualche modo rendere le cose un po 'più lento e non si possono ottenere le prestazioni che ti aspettavi spostando ibdata1 a qualche altro volume di dati. Infatti, l'effetto a cascata ora sarebbe un fattore del numero di tabelle InnoDB moltiplicato per due (2).

Immaginate di avere innodb_file_per_table abilitato. Ora si dovrebbe avere una configurazione leggermente diversa:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• Dati MVCC e tabella dei metadati sarebbe risiedere in ibdata1

Questa cascata sarebbe un po 'peggio, perché la cascata per l'accesso tavolo sarebbe ora avvenire tra tre file invece di due.

Ecco un altro scenario alcuni hanno pensato: Invece di muovere l'ibdata1 ad un volume diverso, come su consentendo innodb_file_per_table e spostare i file .ibd ai volumi uno o più dati diversi? L'effetto a cascata ora sarebbe un fattore del numero di tabelle InnoDB moltiplicato per tre (3). Percona ha espressi molto buone ragioni per non fare questo che troverete utili .