Nuestro equipo especializado pasados varios días de investigación y recopilación de de información, encontramos la respuesta, deseamos que te sea de gran utilidad para tu plan.
Solución:
Entonces respondo esta pregunta casi 4 años tarde:
-
Los formatos de archivo InnoDB se concibieron en un momento en que InnoDB era independiente del servidor MySQL (por ejemplo: MySQL 5.1 podí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 en la degradación de 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 el
innodb_file_formatLa opció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 que se requiere. ¡No se requiere una configuración confusa! -
En MySQL 5.7, el valor predeterminado cambió a
Barracuda/DYNAMIC. Dado que todas las versiones de MySQL admitidas actualmente pueden leer este formato, es seguro alejarse de Antelope y aún ofrecer degradación. -
En un servidor MySQL 5.7, las tablas de Antelope se actualizarán a
Barracuda/DYNAMICen la siguiente reconstrucción de la tabla (OPTIMIZAR TABLA, etc.). Eso es a menos que hayan sido creados específicamente conROW_FORMAT=oldrowformat. -
En MySQL 8.0, la opción
innodb_file_formates removido.
MySQL 5.7 también presenta la opción innodb_default_row_format, cuyo valor predeterminado es DYNAMIC. Esto aborda el punto en su actualización.
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 :
[[email protected] 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 statusG
*************************** 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)
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.
Use otra instancia de MySQL con un ibdata1 e innodb_file_per_table nuevos (opcional, mi preferencia personal). Cambie el formato de archivo con ibdata1 vacío. Luego, vuelva a cargar /root/MySQLData.sql y juegue con los datos.
He escuchado leves historias de terror sobre PostgreSQL que tiene que modificar la configuración para que una base de datos 8.2.4 funcione con los binarios 9.0.1. La misma historia podría aplicarse si intentáramos que ambos formatos de archivo residan en el mismo espacio de tabla del sistema (ibdata1) y / o .ibd archivo si tenemos conocimiento de dicha configuración.
En cuanto a ser kosher ...
- Nadie debe almacenar carne y lácteos en el mismo refrigerador.
- Nadie debe poner un toro y un asno bajo el mismo yugo (Deuteronomio 22:10)
- Nadie debería almacenar
AntelopeyBarracudadentro del mismo ibdata1
ACTUALIZACIÓN 2013-07-05 14:26 EDT
Acabo de responder esta pregunta en ServerFault: Configuración de la compresión de MySQL INNODB KEY_BLOCK_SIZE. Esto me hizo mirar hacia atrás para cualquier pregunta que respondí en el DBA StackExchange había discutido el Barracuda formato 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 InnoDB para Barracuda
Compresión y la agrupación de búfer InnoDB
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 de una página, InnoDB lee la página comprimida desde el disco si aún no está en el grupo de búfer, luego descomprime la página a su forma 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úfer contiene tanto la forma comprimida como sin comprimir 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úfer una página sin comprimir, mientras deja la página comprimida en la memoria. O, si no se ha accedido a una página por un tiempo, la forma comprimida de la página se puede escribir en el disco, para liberar espacio para otros datos. Por lo tanto, en un momento dado, el grupo de búfer puede contener tanto la forma comprimida como sin comprimir de la página, o solo la forma comprimida de la página, o ninguna de las dos.
InnoDB realiza un seguimiento de las páginas que se deben mantener en la memoria y las que se deben desalojar utilizando una lista de uso menos reciente (LRU), de modo que los datos "activos" o de acceso frecuente tienden a permanecer en la memoria. Cuando se accede a tablas comprimidas, InnoDB utiliza un algoritmo LRU adaptativo para lograr un equilibrio adecuado de páginas comprimidas y sin comprimir en la memoria. Este algoritmo adaptativo es sensible a si el sistema se está ejecutando en una forma de E / S o de CPU. El objetivo es evitar gastar demasiado tiempo de procesamiento descomprimiendo páginas cuando la CPU está ocupada y evitar hacer un exceso de E / S cuando la CPU tiene ciclos libres que se pueden usar para descomprimir páginas comprimidas (que pueden estar ya en la memoria). Cuando el sistema está vinculado a E / S, el algoritmo prefiere desalojar la copia sin comprimir de una página en lugar de ambas copias, para dejar más espacio para que otras páginas del disco se conviertan en residentes de la memoria. Cuando el sistema está vinculado a la CPU, InnoDB prefiere desalojar tanto la página comprimida como la sin comprimir, de modo que se pueda utilizar más memoria para las páginas "activas" y reducir la necesidad de descomprimir los datos en la memoria sólo en forma comprimida.
Tenga en cuenta que InnoDB Buffer Pool tiene que cargar páginas de datos y páginas de índice leídas para cumplir con las 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úfer, la página de datos comprimidos y sin comprimir.
Si esta duplicación de contenido de datos está ocurriendo en el Buffer Pool, necesita aumentar innodb_buffer_pool_size por 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úfer 8G
- Ejecutaste compresión con
key_block_size=88es50.00%de1650.00%de8Ges4G- aumentar
innodb_buffer_pool_sizepara12G(8G+4G)
- Ejecutaste compresión con
key_block_size=44es25.00%de1625.00%de8Ges2G- aumentar
innodb_buffer_pool_sizepara10G(8G+2G)
- Ejecutaste compresión con
key_block_size=22es12.50%de1612.50%de8Ges1G- aumentar
innodb_buffer_pool_sizepara9G(8G+1G)
- Ejecutaste compresión con
key_block_size=11es06.25%de1606.25%de8Ges0.5G(512M)- aumentar
innodb_buffer_pool_sizepara8704M(8G(8192M) +512M)
MORALEJA DE LA HISTORIA : El grupo de búfer de InnoDB solo necesita un respiro adicional cuando se manejan datos comprimidos y páginas de índice.
Aquí puedes ver las reseñas y valoraciones de los usuarios
Si tienes algún titubeo o capacidad de arreglar nuestro escrito te proponemos dejar una nota y con placer lo analizaremos.