innodb_file_format Barracuda


25

Ho un paio di domande per quelli più familiari. La maggior parte delle mie istanze utilizza Antelope nonostante abbia il supporto per Barracuda.

Stavo cercando di giocare con alcuni compressi innodb table. La mia comprensione è che questo è disponibile solo nel formato Barracuda.

  1. Vedo che innodb_file_format è dinamico, quindi posso semplicemente passare senza rimbalzare. Ci sono implicazioni nel fare ciò di cui dovrei essere consapevole. Tutto quello che posso dire è che significa che nuove tabelle o successivamente modificate verranno create con quel formato. È tutto corretto?
  2. Speravo di non dover passare attraverso e convertire tutti i miei tavoli. Kosher ha tabelle antilopi e barracude che coesistono nello stesso tablespace? Anche se funziona ci sono dei gotcha da cercare?

Da quello che ho letto e raccolto dai miei test le risposte sono: Sì. Sì. Non ne sono sicuro.

Aggiornare

Sono in esecuzione con alcune tabelle Dynamic e alcune compresse in vari casi da questo post senza problemi. Inoltre ho trascurato di leggere http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html al momento.

Dopo aver abilitato un dato innodb_file_format, questa modifica si applica solo alle tabelle appena create anziché a quelle esistenti. Se si crea una nuova tabella, il tablespace contenente la tabella viene etichettato con il formato di file "più vecchio" o "più semplice" necessario per le funzionalità della tabella. Ad esempio, se si abilita il formato file Barracuda e si crea una nuova tabella che non è compressa e non utilizza ROW_FORMAT = DYNAMIC, il nuovo tablespace che contiene la tabella viene etichettato come utilizzando il formato file Antelope.

Quindi le tabelle verranno create come antilope anche se si consente Barracuda. Il mixaggio è inevitabile a meno che non si specifichi ogni tabella come dinamica row_format o una tabella compressa.

Non ci sono indicazioni che dovresti fare un dump completo e ricaricare quando introduci la tua prima tabella Barracuda (come è raccomandato quando aggiorni le versioni principali di mysql )

Risposte:


18

Quindi rispondo a questa domanda con quasi 4 anni di ritardo:

  • I formati di file InnoDB sono stati concepiti in un momento in cui InnoDB era indipendente dal server MySQL (ad esempio: MySQL 5.1 poteva eseguire due diverse versioni di InnoDB).

  • Il motivo per cui non si vorrebbe eseguire Barracuda (nel 2012) è che potrebbe ridurre la flessibilità nel downgrade di MySQL (ovvero dopo un aggiornamento fallito, si desidera tornare a una versione che non è in grado di leggere un formato più recente). cioè non dovrebbero esserci ragioni tecniche per cui Antelope è migliore.

  • In MySQL 5.7 l' innodb_file_formatopzione era obsoleta. Poiché MySQL e InnoDB non sono più indipendenti, pertanto InnoDB può utilizzare le regole di aggiornamento di MySQL e la compatibilità con le versioni precedenti. Nessuna impostazione confusa richiesta!

  • In MySQL 5.7, l'impostazione predefinita è passata a Barracuda/DYNAMIC. Poiché tutte le versioni attualmente supportate di MySQL possono leggere questo formato, è sicuro allontanarsi da Antelope e offrire comunque il downgrade.

  • Su un server MySQL 5.7, le tabelle Antelope verranno aggiornate alla Barracuda/DYNAMICricostruzione della tabella successiva (OPTIMIZE TABLE ecc.). Questo a meno che non siano stati creati appositamente con ROW_FORMAT=oldrowformat.

  • In MySQL 8.0, l'opzione innodb_file_formatè stata rimossa.


MySQL 5.7 introduce anche l'opzioneinnodb_default_row_format , che per impostazione predefinita è DYNAMIC. Questo risolve il problema nel tuo aggiornamento.


11
Just give a try!!!

mysql> select version();
+------------+
| version()  |
+------------+
| 5.5.21-log |
+------------+
1 row in set (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
| innodb_file_per_table    | ON       |
+--------------------------+----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Antelope  |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format_max = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Barracuda |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

I had observed a single line logged in Error Log file :

[root@dhcppc0 Desktop]# tail -1 /usr/local/mysql/data/dhcppc0.err
120402 11:26:52 [Info] InnoDB: the file format in the system tablespace is
now set to Barracuda.

After switching to barracuda file format, I could also access my Database
and tables without any error :

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| opentaps1          |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

mysql> use opentaps1;
Database changed
mysql> select count(*) from product;
+----------+
| count(*) |
+----------+
|     3244 |
+----------+
1 row in set (0.42 sec)

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status: 
=====================================
120402 11:36:29 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 18446744073709534037 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 12 1_second, 12 sleeps, 1 10_second, 2 background,
2 flush
srv_master_thread log flush and writes: 12
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 5, signal count 5
Mutex spin waits 2, rounds 60, OS waits 2
RW-shared spins 3, rounds 90, OS waits 3
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter F01
Purge done for trx's n:o < 0 undo n:o < 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION F00, not started
MySQL thread id 1, OS thread handle 0x7f38309f9710, query id 28 localhost
root
show engine innodb status
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer
thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
554 OS file reads, 7 OS file writes, 7 OS fsyncs
-0.01 reads/s, 16384 avg bytes/read, -0.00 writes/s, -0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276707, node heap has 15 buffer(s)
-0.15 hash searches/s, -0.12 non-hash searches/s
---
LOG
---
Log sequence number 221536390
Log flushed up to   221536390
Last checkpoint at  221536390
0 pending log writes, 0 pending chkp writes
10 log i/o's done, -0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 3476070
Buffer pool size   8192
Free buffers       7635
Database pages     542
Old database pages 220
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
-0.00 youngs/s, -0.00 non-youngs/s
Pages read 542, created 0, written 1
-0.01 reads/s, -0.00 creates/s, -0.00 writes/s
Buffer pool hit rate 980 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead -0.00/s, evicted without access -0.00/s, Random read ahead
-0.00/s
LRU len: 542, unzip_LRU len: 0
I/O sum[0]:cur[238], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 2937, id 139879303665424, state: waiting for server
activity
Number of rows inserted 0, updated 0, deleted 0, read 3244
-0.00 inserts/s, -0.00 updates/s, -0.00 deletes/s, -0.18 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)

9

Se vuoi davvero giocare con InnoDB usando il formato Barracuda, dovresti mysqldump tutto in qualcosa come /root/MySQLData.sql. Ciò rende il formato del file di dati indipendente.

Utilizzare un'altra istanza MySQL con un nuovo ibdata1 e innodb_file_per_table (opzionale, la mia preferenza personale). Cambia il formato del file con ibdata1 vuoto. Quindi, ricaricare /root/MySQLData.sql e giocare con i dati.

Ho sentito lievi storie horror su PostgreSQL che ha dovuto modificare le impostazioni per far funzionare un database 8.2.4 con i binari 9.0.1. La stessa storia potrebbe applicarsi se provassimo a far risiedere entrambi i formati di file nello stesso tablespace di sistema (ibdata1) e / o .ibdfile se siamo a conoscenza di tali impostazioni.

Per quanto riguarda essere kosher ...

  • Nessuno dovrebbe conservare carne e latticini nello stesso frigorifero
  • Nessuno dovrebbe mettere un toro e un asino sotto lo stesso giogo (Deuteronomio 22:10)
  • Nessuno dovrebbe conservare Antelopee Barracudaall'interno della stessa ibdata1

AGGIORNAMENTO 2013-07-05 14:26 EDT

Ho appena risposto a questa domanda in ServerFault: impostazione della compressione MySQL INNODB KEY_BLOCK_SIZE . Questo mi ha fatto tornare indietro per qualsiasi domanda a cui ho risposto nel DBA StackExchange aveva discusso il Barracudaformato e ho trovato questo mio vecchio post. Metterò le stesse informazioni qui ...

Secondo la documentazione MySQL sulla compressione InnoDB per Barracuda

Compressione e pool di buffer InnoDB

In una tabella InnoDB compressa, ogni pagina compressa (sia 1K, 2K, 4K o 8K) corrisponde a una pagina non compressa di 16K byte. Per accedere ai dati in una pagina, InnoDB legge la pagina compressa dal disco se non si trova già nel pool di buffer, quindi decomprime la pagina nella sua forma originale di 16 KB. Questa sezione descrive come InnoDB gestisce il pool di buffer rispetto alle pagine delle tabelle compresse.

Per ridurre al minimo l'I / O e ridurre la necessità di decomprimere una pagina, a volte il pool di buffer contiene sia la forma compressa che non compressa di una pagina del database. Per fare spazio ad altre pagine del database richieste, InnoDB può "eliminare" dal pool di buffer una pagina non compressa, lasciando in memoria la pagina compressa. Oppure, se non si accede a una pagina da un po 'di tempo, la forma compressa della pagina può essere scritta su disco, per liberare spazio per altri dati. Pertanto, in qualsiasi momento, il pool di buffer può contenere sia la forma compressa che non compressa della pagina, oppure solo la forma compressa della pagina, o nessuna delle due.

InnoDB tiene traccia di quali pagine tenere in memoria e quali sfrattare utilizzando un elenco LRU (usato meno di recente), in modo che i dati "caldi" o con accesso frequente tendano a rimanere in memoria. Quando si accede alle tabelle compresse, InnoDB utilizza un algoritmo LRU adattativo per ottenere un adeguato equilibrio di pagine compresse e non compresse in memoria. Questo algoritmo adattivo è sensibile al fatto che il sistema funzioni in modo I / O o CPU. L'obiettivo è quello di evitare di perdere troppo tempo di elaborazione per decomprimere le pagine quando la CPU è occupata e di evitare un eccesso di I / O quando la CPU ha cicli di riserva che possono essere utilizzati per pagine compresse non compresse (che potrebbero già essere in memoria). Quando il sistema è associato a I / O, l'algoritmo preferisce sfrattare la copia non compressa di una pagina piuttosto che entrambe le copie, per fare più spazio affinché altre pagine del disco diventino residenti in memoria. Quando il sistema è associato alla CPU, InnoDB preferisce eliminare sia la pagina compressa che la pagina non compressa, in modo che sia possibile utilizzare più memoria per le pagine "calde" e ridurre la necessità di decomprimere i dati in memoria solo in forma compressa.

Si noti che il pool di buffer InnoDB deve caricare pagine di dati e pagine indice lette per soddisfare le query. Quando si legge una tabella e i suoi indici per la prima volta, la pagina compressa deve essere non compressa a 16 KB. Ciò significa che avrai il doppio del contenuto di dati nel pool di buffer, nella pagina di dati compressi e non compressi.

Se questa duplicazione del contenuto dei dati viene eseguita nel pool di buffer, è necessario aumentare innodb_buffer_pool_size di un piccolo fattore lineare del nuovo tasso di compressione. Ecco come:

SCENARIO

  • Hai un DB Server con un pool di buffer 8G
  • Hai eseguito la compressione con key_block_size=8
    • 8è 50.00%di16
    • 50.00%di 8Gè4G
    • aumentare innodb_buffer_pool_sizea 12G( 8G+ 4G)
  • Hai eseguito la compressione con key_block_size=4
    • 4è 25.00%di16
    • 25.00%di 8Gè2G
    • aumentare innodb_buffer_pool_sizea 10G( 8G+ 2G)
  • Hai eseguito la compressione con key_block_size=2
    • 2è 12.50%di16
    • 12.50%di 8Gè1G
    • aumentare innodb_buffer_pool_sizea 9G( 8G+ 1G)
  • Hai eseguito la compressione con key_block_size=1
    • 1è 06.25%di16
    • 06.25%di 8Gis 0.5G( 512M)
    • aumentare innodb_buffer_pool_sizea 8704M( 8G( 8192M) + 512M)

MORALE DELLA STORIA : il pool di buffer InnoDB ha solo bisogno di ulteriore spazio di respirazione quando si gestiscono dati compressi e pagine indice.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.