innodb_file_format Barracuda

25

Tengo un par de preguntas para los más familiares. La mayoría de mis instancias han estado ejecutando Antelope a pesar de tener soporte para Barracuda.

Estaba buscando jugar con algunas compresas innodb mesas. Tengo entendido que esto solo está disponible en el formato Barracuda.

  1. Veo que innodb_file_format es dinámico, así que puedo cambiar sin un rebote. ¿Hay alguna implicación de hacer esto que debería tener en cuenta? Todo lo que puedo decir es que eso significa que se crearán tablas nuevas o posteriormente alteradas con ese formato. ¿Es todo esto correcto?
  2. Esperaba no tener que pasar y convertir todas mis tablas. ¿Es kosher tener tablas de antílopes y barracudas coexistiendo en el mismo espacio de tabla? Incluso si funciona, ¿hay algo que tener en cuenta?

Por lo que leí y deduje de mis exámenes, las respuestas son: Sí. Sí. No estoy seguro.

Actualizar

He estado ejecutando w / algunas tablas dinámicas y algunas comprimidas en varias instancias desde esta publicación sin problemas. Además, olvidé leer http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html en ese momento.

Después de habilitar un innodb_file_format dado, este cambio se aplica solo a las tablas recién creadas en lugar de las existentes. Si crea una nueva tabla, el espacio de tabla que contiene la tabla se etiqueta con el formato de archivo "más antiguo" o "más simple" que se requiere para las características de la tabla. Por ejemplo, si habilita el formato de archivo Barracuda y crea una nueva tabla que no está comprimida y no utiliza ROW_FORMAT = DYNAMIC, el nuevo espacio de tabla que contiene la tabla se etiqueta como formato de archivo Antelope.

Por lo tanto, las tablas se crearán como Antelope incluso si permite Barracuda. La mezcla es inevitable a menos que especifique cada tabla como row_format dynamic o una tabla comprimida.

No hay indicios de que deba realizar un volcado y una recarga completos al presentar su primera tabla Barracuda (como se recomienda al actualizar las versiones principales de mysql )

atxdba
fuente

Respuestas:

18

Entonces estoy respondiendo esta pregunta casi 4 años tarde:

  • Los formatos de archivo de InnoDB fueron concebidos en un momento en que InnoDB era independiente del servidor MySQL (por ejemplo: MySQL 5.1 podría ejecutar dos versiones diferentes de InnoDB).

  • La razón por la que no querría ejecutar Barracuda (en 2012) es que podría reducir la flexibilidad para degradar MySQL (es decir, después de una actualización fallida, desea volver a una versión que no puede leer un formato más nuevo). es decir, no debería haber razones técnicas por las que Antelope sea mejor.

  • En MySQL 5.7, la innodb_file_formatopción estaba en desuso. Dado que MySQL e InnoDB ya no son independientes, InnoDB puede usar las reglas de actualizaciones de MySQL y la compatibilidad con versiones anteriores. ¡No se requiere una configuración confusa!

  • En MySQL 5.7, el valor predeterminado cambió a Barracuda/DYNAMIC. Dado que todas las versiones compatibles de MySQL pueden leer este formato, es seguro alejarse de Antelope y seguir ofreciendo una versión anterior.

  • En un servidor MySQL 5.7, las tablas de Antelope se actualizarán Barracuda/DYNAMICen la próxima reconstrucción de la tabla (OPTIMIZE TABLE, etc.). Eso es a menos que se hayan creado específicamente con ROW_FORMAT=oldrowformat.

  • En MySQL 8.0, la opción innodb_file_formatse elimina.


MySQL 5.7 también presenta la opcióninnodb_default_row_format , que por defecto es DYNAMIC. Esto aborda el punto en su actualización.

Morgan Tocker
fuente
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)
Gopinath
fuente
9

Si realmente quieres jugar con InnoDB usando el formato Barracuda, debes mysqldump todo a algo como /root/MySQLData.sql. Eso hace que el formato del archivo de datos sea independiente.

Utilice otra instancia de MySQL con una nueva ibdata1 e innodb_file_per_table (opcional, mi preferencia personal). Cambie el formato del archivo con ibdata1 vacío. Luego, vuelva a cargar /root/MySQLData.sql y juegue con los datos.

He escuchado pequeñas historias de horror sobre PostgreSQL que tiene que modificar la configuración para obtener una base de datos 8.2.4 para trabajar con los binarios 9.0.1. La misma historia podría aplicarse si intentamos hacer que ambos formatos de archivo residan en el mismo espacio de tabla del sistema (ibdata1) y / o .ibdarchivo si conocemos dicha configuración.

En cuanto a ser kosher ...

  • Nadie debe almacenar carne y lácteos en el mismo refrigerador.
  • Nadie debería poner un toro y un asno bajo el mismo yugo (Deuteronomio 22:10)
  • Nadie debe almacenar Antelopey Barracudadentro de la misma ibdata1

ACTUALIZACIÓN 2013-07-05 14:26 EDT

Acabo de responder esta pregunta en ServerFault: Configuración de la compresión INNODB de MySQL KEY_BLOCK_SIZE . Esto me hizo mirar hacia atrás para cualquier pregunta que respondí en el DBA StackExchange había discutido el Barracudaformato y encontré esta vieja publicación mía. Colocaré la misma información aquí ...

De acuerdo con la documentación de MySQL sobre la compresión de InnoDB para Barracuda

Compresión y el InnoDB Buffer Pool

En una tabla InnoDB comprimida, cada página comprimida (ya sea 1K, 2K, 4K u 8K) corresponde a una página sin comprimir de 16K bytes. Para acceder a los datos en una página, InnoDB lee la página comprimida del disco si aún no está en el grupo de búferes, luego descomprime la página a su formato original de 16K bytes. Esta sección describe cómo InnoDB administra el grupo de búferes con respecto a las páginas de tablas comprimidas.

Para minimizar la E / S y reducir la necesidad de descomprimir una página, a veces el grupo de búferes contiene la forma comprimida y no comprimida de una página de base de datos. Para hacer espacio para otras páginas de base de datos requeridas, InnoDB puede "desalojar" del grupo de búferes una página sin comprimir, mientras deja la página comprimida en la memoria. O, si no se ha accedido a una página durante un tiempo, la forma comprimida de la página puede escribirse en el disco, para liberar espacio para otros datos. Por lo tanto, en cualquier momento dado, la agrupación de almacenamiento intermedio puede contener las formas comprimidas y no comprimidas de la página, o solo la forma comprimida de la página, o ninguna.

InnoDB realiza un seguimiento de qué páginas mantener en la memoria y cuáles desalojar utilizando una lista de las menos utilizadas recientemente (LRU), de modo que los datos "activos" o de acceso frecuente tienden a permanecer en la memoria. Cuando se accede a las tablas comprimidas, InnoDB usa un algoritmo adaptativo de LRU para lograr un equilibrio apropiado de páginas comprimidas y sin comprimir en la memoria. Este algoritmo adaptativo es sensible a si el sistema se ejecuta de manera vinculada a E / S o CPU. El objetivo es evitar pasar demasiado tiempo de procesamiento descomprimiendo páginas cuando la CPU está ocupada, y evitar el exceso de E / S cuando la CPU tiene ciclos de reserva que se pueden usar para descomprimir páginas comprimidas (que ya pueden estar en la memoria). Cuando el sistema está vinculado a E / S, el algoritmo prefiere expulsar la copia sin comprimir de una página en lugar de ambas copias, para hacer más espacio para que otras páginas del disco se conviertan en residentes de memoria. Cuando el sistema está vinculado a la CPU, InnoDB prefiere desalojar tanto la página comprimida como la no comprimida, de modo que se pueda usar más memoria para páginas "activas" y reducir la necesidad de descomprimir datos en la memoria solo en forma comprimida.

Tenga en cuenta que el InnoDB Buffer Pool tiene que cargar páginas de datos y páginas de índice leídas para completar consultas. Al leer una tabla y sus índices por primera vez, la página comprimida debe descomprimirse a 16K. Eso significa que tendrá el doble de contenido de datos en el grupo de búferes, la página de datos comprimidos y sin comprimir.

Si esta duplicación de contenido de datos está ocurriendo en el Grupo de búferes , debe aumentar innodb_buffer_pool_size en un pequeño factor lineal de la nueva tasa de compresión. Aquí es cómo:

GUIÓN

  • Tiene un servidor de base de datos con un grupo de búferes 8G
  • Corriste la compresión con key_block_size=8
    • 8es 50.00%de16
    • 50.00%de 8Ges4G
    • subir innodb_buffer_pool_sizea 12G( 8G+ 4G)
  • Corriste la compresión con key_block_size=4
    • 4es 25.00%de16
    • 25.00%de 8Ges2G
    • subir innodb_buffer_pool_sizea 10G( 8G+ 2G)
  • Corriste la compresión con key_block_size=2
    • 2es 12.50%de16
    • 12.50%de 8Ges1G
    • subir innodb_buffer_pool_sizea 9G( 8G+ 1G)
  • Corriste la compresión con key_block_size=1
    • 1es 06.25%de16
    • 06.25%de 8Ges 0.5G( 512M)
    • subir innodb_buffer_pool_sizea 8704M( 8G( 8192M) + 512M)

MORAL DE LA HISTORIA : El InnoDB Buffer Pool solo necesita espacio adicional para respirar cuando maneja datos comprimidos y páginas de índice.

RolandoMySQLDBA
fuente